Team Charters are a trap.
I’m cleaning out old lingering drafts. This one’s on why I dislike Team Charters.
Recently an email came in asking about writing team charters. I’ve worked at a number of companies that asked teams to write charters, and I think it’s an interesting project. That said, it’s not a project I’d generally prioritize. If you pushed me on this topic, I’d probably suggest you write an engineering strategy document from the perspective of your team. A few thoughts on what team charters try to solve, and then why I think they’re generally not very useful.
What team charters try to solve:
- Building team alignment around their mission
- Building team alignment around their approach to accomplishing that mission
- Helping folks on other teams to understand your team’s mission
These are all valuable problems to solve, but I find charters pretty ineffective:
- Teams want to involve their members in writing their team charters, turning them into a bottoms up initiative
- Team members generally write charters based on solving the bottoms-up initiative they’ve identified, rather than accurately reflecting their organization and leadership’s view of what the team needs to do. Said differently, teams often select the mission they want rather than the mission they have
- For example, teams doing a lot of maintenance work will often omit that work from their charter, even though their leadership and organization expect them to do it. Then team members might say that leadership isn’t respecting their charter, and get upset
- If you approach this from a top-down perspective, you get the right content, but generally wouldn’t call it a team charter and it would skip the consensus-building aspect where charters generally go wrong
The reality is that teams must work within the scope that their leadership wants, and exercises that encourage them to forget that are harmful to the team rather than empowering. Empowering bottoms up mission-setting in an organization that practices top-down resource allocation is a trap.