Check out a free preview of the full Enterprise Engineering Management 102 course

The "Team Charter" Lesson is part of the full, Enterprise Engineering Management 102 course featured in this preview video. Here's what you'd learn in this lesson:

Ryan discusses the importance of creating a team charter or vision statement, and how a team charter helps bring clarity and alignment to the team's mission and goals, and helps stakeholders and partners understand the team's purpose. Ryan then guides the audience through an exercise to brainstorm and create their own team charter, emphasizing the importance of clarity, conciseness, and collaboration within the team. After the exercise, the Ryan facilitates a discussion where participants share their thoughts and experiences with creating a team charter.


Transcript from the "Team Charter" Lesson

>> All right, going back to the vision, I often think about it is maybe as a team charter. It's a team charter is really trying to help tell you about what your team does, and I think this is a great exercise to do with a team and think about why you exist.

It brings a clarity on the team's mission and goals, and this clarity helps the team, but it also helps partners and stakeholders, maybe leadership, to just understand why that team exists. When it gets that alignment, I oftentimes think about there's ownership of different things that are getting passed around in a company and being like, Jem's team should own this.

Because his charter says this or his charter says this, they probably shouldn't own that. And so, it helps bring clarity and alignment for people across the business. It also has team accountability, this one's a really good, your team has a better sense of what they should focus on.

And even when requests come to them, they're kinda saying, that doesn't quite fit our charter, maybe another team should do this. Or they can raise that flag versus just opting to do the work, cuz you wanna make sure that you're taking on the right things. So I like to think about the exercise, breaking it down from a high level.

There's a good book called The Advantage, these questions aren't exactly pulled from The Advantage book, but it talks a lot about that and saying like, focusing really high level on, who are our customers? What do we own as a team, what are we responsible for, what don't we do?

That's an important one, right, we don't do or own the UI, we only leverage the API and own that. And so when a request comes to us to do something on the UI, that's not us, and it's very clear and people know that. Why does our team exist?

I mean, it could be just to bring joy to customers, it could be to make money, I don't know, but you want to have a good clarity statement around why you exist as a team. And then how do you operate, what are things that you want to do as a team?

How's the culture within your team, what makes you successful? And then, yeah, how are you successful, how do you know you're doing the right things? So, we're gonna run through an exercise where we will actually go through and start to brainstorm a team charter. What I want you all to do is think about your team that you're on now, maybe an existing team, maybe just some made up team.

And think about answering those questions about why you exist, how do you operate, and this is a great exercise I've done with my team in smaller breakout groups. And what's really cool to do it that way is you kind of bring it all back together and it can be in bullet points and going through that way.

Ideally at the end of the, kind of the end state that you have, it's very clear, concise, like one to two sentence for each of those questions. But by doing the small breakout groups with the team, you get to kinda see different perspectives. And oftentimes a lot of commonality, sometimes completely different things that come up, but it's been really helpful.

I know at first when I started doing this, I was like, I don't know if this is that helpful, but I've done it a few times now to know that it is bringing a lot of clarity for the team. So, I will show you the exercise here, which is available as a Google Doc, it outlines the questions and really like I said, it can be bullet form.

Focus and think about as a team, what you do as a team, and think about that, and we will circle back after that. Welcome back from doing the exercise of creating your team charter. So hopefully you all found that useful, I'm curious for the audience what are some of the things that you thought about, what was something that was maybe difficult to think about for your team?

>> So, I have two teams right now, and I started by trying to think of the smaller team that I have. And I think what this was very illuminating for me for is I've lacked a lot of the clarity on team charter and team goals and objectives for that team.

We have kind of a duality of projects with a platform that currently supports the majority of our business and a future looking platform merging with our parent company in Bangkok. And the smaller team is responsible for a kind of nebulous goal of figuring out how we get onto that platform in Bangkok [COUGH] and so with a small team, with kind of a very big scope like that, it's been very difficult to find that kind of team charter.

And so this was helpful for me in finding a framing device for perhaps having a conversation with my directors to figure out how can we reign that in, how can we find something achievable and useful to the company that's within our means.
>> I like that, and I definitely even recommend hearing from the team to, like, yeah, like what did they think of that too?

And I think sometimes taking a step back could be an interest even, this is a good exercise that something even if you have a team that exists already, which oftentimes you are like, even as a new manager coming in, like the teams might already existed for years, right?

And so I think sometimes just taking that step back can really help and hopefully bring that clarity too, any other thoughts?
>> I work at a 20 person startup, so the question of what don't we do it's kind of hard to answer given that we have one engineering team.

But for that one it's kind of thinking through what do our stakeholders do and how do we kind of interact with them of what do they do that helps us deliver software at the end of the day. So, we have a data science team so kind of working with them, and then, since we're in a regulated space too, we work with a lot of regulatory and quality and we have to produce deliverables for those.

But we don't end up packaging those up at the end of the day and sending those things out to the FDA and things like that. So, kind of even just making it clear of what those different boundaries are to kind of answer that one since the team itself does do everything else for the product.

>> I love that, so you're just responsible for everything, yeah. But, yeah, I hope that what I heard there too it's almost like maybe even prioritizing, it's like thinking about, well, here's, maybe it's not what we don't do. There's probably a couple, but it's even like, how do we think about the priorities, and maybe there are certain ones that for the regulatory things, you're like, we can't miss that, right?

It's like that for the team to have that clarity, but yeah, that's an interesting one, yeah, when you're like, we just kind of do everything.
>> I have the exact same problem with writing the, and I feel with that it's almost, cuz we operate as two large teams, I feel like we almost need to break down the team into smaller teams and actually give ownership to things.

So that there is more of that, or it's less nebulous. These people own this part of the platform, cuz yeah, I was really struggling with the what don't we do, it's like we again do everything.
>> [LAUGH]
>> Right, yeah, and I like that, too, as it could be just certain people on the team might be the like you own this.

And so it's like you might not be responsible for the 100 other things that's someone else's part and so even having some of that clarity. That can sometimes get in my mind a little bit too deep in some ways, maybe it's I think more for speaking to partners but maybe that is good, is like they can even have, I go to Joe for this and I go to Sally for this, right, it does bring them that clarity and that might change and evolve over time, Mark.

>> Online someone said, Natalie said, I'm realizing from the charter exercise that my last team could have probably clarified our OKRs and vision. We were an acquisition team that were thrown into a lot broader concerns because of this.
>> Yep, I have been there many times and even when I said I think at first when I thought of doing this team charter, I was like, that's kind of useless.

Like I'll admit, and it doesn't, it feels like that even when I first like think about it but once you start bringing that clarity out, it really helps. I've been on teams where you struggle to have that identity or you're trying to do too many things and you don't deliver what you should be delivering, and so I think that is a really good callout, Mark.

>> For OKRs, is it more setting realistic OKRs or more on the influential side of getting your OKRs prioritized?
>> That's a really good question, I think it's like you want them to be somewhat realistic and you wanna be thoughtful on that, but it's also okay not to meet them either, right?

There's definitely been times where, right now with like, being in productivity engineering at Netflix is a lot of it is relying on customer satisfaction. Our customers are engineers at Netflix, and so we're running surveys where I might say, last year our satisfaction for this product was 85%. Maybe my OKR is something I wanna maintain that or I wanna grow it to 90%.

And it might drop, that's not bad, I mean, that was a bit aspirational and we didn't deliver on that, that's not a bad thing. Cuz it also allows you to go, what happened, what what was wrong? So I think about it not way, but there again, don't measure everything, please don't do that cuz that's just the wrong thing, Jem.

>> If I was hitting 100% of my OKRs, I'm doing something wrong, I'm not trying hard enough or making it really, really easy. So I'd say they should be aspirational to some degree, but you don't wanna hit like 30% of your OKRs, then you're not you're not measuring properly or something's off but.

>> Yeah, maybe it's like 80%, yeah, so you wanna be realistic, but you also don't wanna low ball it either. It's like, yeah, we're gonna slip in customer satisfaction, and so that's cool, we can just sit back and that's fine. It's like, no, you wanna strive for something and improve that, that's a good call out.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now