Writing Team Charters

Before starting a project you write a proposal. Before starting a company you write a business plan. And before starting a team you write a charter: What problems does the team exist to solve? What is its mission, and how will it measure success? Most importantly, how should team members approach their work together? Concisely answering these questions gives the team purpose and accelerates the process of norming on expectations and values.

Every once in a while you’ll run into a team working cohesively without a charter. Many are! The natural tendency in any group is towards cooperation, and team members sharing organizational, cultural, and experiential ties tend to stumble their way to implicit social contracts eventually. Leaving this process to chance has its downsides, however, with limited allowances for both creative thinking and the team’s openness to experience. Much better—and no harder—to create the charter intentionally.

What belongs in a charter?

Regardless of the team, three things go into every charter.

  • a mission statement the team exists to achieve. In a single sentence, the mission statement should summarize what the team does, for whom, and how.

  • principles for conduct and decision-making. These are a handful of guidelines to help team members make appropriate choices when faced with otherwise vague or contradictory guidance.

  • key performance indicators (KPIs) for tracking the team’s status and health. KPIs should be quantifiable and focused only on the most important measures for the team.

Depending on the team, it may be tempting to expand on additional details—objectives, responsibilities, and budget, to name a few—but for long-lived development teams, these are better left to the documents guiding specific projects and initiatives. A flexible, lightweight charter will offer guidance across all of the team’s work together without requiring an afternoon of reading. That’s what we’re out to write.

Team charter mistakes

Before sitting down to write a charter it’s worth calling out at least two ways it can go very wrong.

First, decreeing a charter doesn’t work. Creating it is a participatory process that draws from the values of the entire team. Without them, it’s another meaningless proclamation to be ignored (if not actively subverted) in the team’s daily work.

Second, keep it simple. A charter shouldn’t be airtight legalese. Clear writing and minimal prescription will greatly increase the odds that the charter gets used.

Creating the charter

Writing a team charter is about forcing important conversations. Somebody–who could be a manager, could a team member, and never somebody from outside the team–needs to lead the team through at least four steps.

  1. Brainstorm. Get ideas for each part of the charter down, and don’t worry whether or not they’re “right.” This is a generative exercise. The cleanup will come.

  2. Gather feedback. Team members will emphasize the features of the charter that are most important to them, and chances are their values aren’t all aligned. Constructive criticism is strongly encouraged; as one example, playing several rounds of How Will We Game This Metric? helped our team at Koan get ahead of Goodhart’s Law and craft more meaningful KPIs.

  3. Synthesize. This process is up to the lead author, but won’t end in a vacuum: once a draft emerges from the rubble of brainstorming and feedback, further (likely asynchronous) feedback from the team will only help improve it and build collective investment.

  4. Tighten it up. Once the draft has general agreement, put in the time to wordsmith, revise, and cut, cut, cut. Knowing the charter by heart (and trust me, everyone should) will be much easier with pithy, memorable headlines and the details pared down to their essence. Don’t get discouraged if this takes longer than it feels like it possibly should. Many, many revisions went into getting the Koan dev team charter right–but we eventually did, and the effort was well worth it.

The fifth step is ongoing: to make it all real. The team’s work should support its identified mission. KPIs should be tracked and reported on. And principles should be lived daily.

Revising the charter

Which is not to say the charter won’t evolve. Teams change. Every change in personnel should trigger at least a cursory review of the team’s charter, as should any significant changes to the operating environment. At the very least, revising the charter at least annually will help ensure its continued applicability.

If the team’s work deviates from the charter, take the hint and reassess. Does the charter still apply? If not, can it be updated to reflect reality? Or is the team better off dispersing in support of other ends?

Set expectations. Stay accountable. It’s what great teams do–and having a great charter will help.

Opengraph image by Patrick Tomasso via Unsplash