Software teams own features, projects, and services—everyone knows that. But caught up in what we’re doing, it’s easy to lose sight of why we’re doing it. Digging into the details might turn up some clues:
- Why does our team exist? To maintain Service X
- Why does Service X need to run? Because it’s a tier-two service that’s a dependency of tier-one Services A and Y
- What happens if Service A goes down? I’m not sure, but it doesn’t sound good.
Teams exist for a reason, opaque thought it may be, and team members should know what it is.
Teams are works-in-progress
Clarity is even harder to come by when a team is just starting out. Wouldn’t it be nice if teams arrived in the world as the ancient Greek poet Hesiod describes the birth of the goddess Athena?
And the father of men and gods gave her birth by way of his head…arrayed in arms of war. —Hesiod, Theogeny
Anyone who has collaborated with other people can confirm that—unlike ancient Greek deities—teams do not spring forth fully-formed. Nor are they the product of a single head: teams are made up of individuals, and even with a cohesive vision of the team’s objective (not itself a given), everyone likely won’t agree on the best way to get there.
The psychologist Bruce Tuckman framed this reality with a four-stage model for group development. In Tuckman’s model, teams form, storm, norm, and perform, with high-performing teams emerging only after weather the turbulence of the early stages. But while we can’t control the sequence of events, we can hasten the journey.
Accelerating team formation
Shared expectations are the foundation underlying all effective teamwork. Yet often the process of establishing them is left up to chance. It’s true that time and good intentions usually lead to common ground, but by forcing explicit conversations about the team’s intentions and beliefs up front, a written charter can significantly accelerate the process.
At a minimum, a charter should lay out the team’s:
- mission statement, summarizing the team’s shared purpose
- principles for conduct and decision-making
- key performance indicators (KPIs) representing the team’s status and health
While a team lead or manager may write the first draft, revisions are highly encouraged: input and feedback from all team members will only help ensure the charter represents a common understanding of the team’s identity. Ideally the charter-drafting process will start to build collective ownership as well.
Let’s dig into specifics, and look at how we’ve addressed them in the Koan dev team charter.
Mission statement
A charter’s mission statement is a single sentence summarizing what the team does, for whom, and how. Rather than serving specific customer personas or internal stakeholders, our development team is on the hook to advance the company and its mission as a whole. We do it by shipping reliable software and holding ourselves (and our colleagues) to high standards. As the mission statement at the top of our charter reads, we exist:
To advance Koan through engineering excellence and continuous improvement.
Principles
Principles are the guidelines that the team can fall back on when assessing contradictory or otherwise unclear choices. They also set expectations. A principles that we, “win the marathon” both encourages thoughtful, long-term decision-making and implies that team members will do it.
The team’s principles should be short and memorable. In creating our own charter, we brainstormed, debated, and revised our way down to just four. They’re both a clear expression of our common values and simple enough to remember. They read:
In support of our company Mission, Vision and Goals, and Values, Koan engineers:
Figure it out. We find a way to deliver our objectives while continuously improving along the way.
Ship to learn. We release the moment that staging is better than prod, listen early and often, and move faster because of it.
Deliver customer value. Our work directly benefits our customers — whether they’re outside Koan or at the next desk down.
Win the marathon. We’re in it for the long haul, making decisions that balance today’s needs against the uncertain future ahead.
Once again, our closeness to the rest of the company shows through in a brief preamble connecting our team-specific principles back to the mission, vision, and values of the organization as a whole.
KPIs
The team’s charter should include a measurable definition of its health. Is the team maintaining basic responsibilities and expectations? Team members should always be able to reference KPIs that quantify its current status.
As with the mission and principles, the specific metrics will vary considerably across functions. While a sales org may be looking at calls per rep or the total value of qualified leads, a dev team will often focus on the “—ilities”—stability, durability, and so on.
Our own KPIs are split between numbers we’re interested in (but not actively losing sleep over) and numbers that really matter. The latter are important enough to take up precious real estate on our company dashboard, and as the lone development team in a dynamic startup we’ve limited our focused to just two themes with very specific measures:
- Quality: % TypeScript coverage (FE, BE)
- Velocity: PR lifetime (time delta from opened to merged)
There are plenty of other numbers we’re interested in—but for the charter (2021 edition) those two were disproportionately more important to our continued improvement (and quality of life) as a team.
The team evolves. The charter, too.
Existing teams need charters, too, and chances are they aren’t the same as when the team was first formed. Explicit or otherwise, the charter will change. It should change. Revisit it quarterly, revise it yearly, or whenever:
- A principle needs updating to reflect changing expectations or operating conditions
- A KPI is significantly exceeded, or becomes an automatic part of the culture
- Team members join or leave
- And so on!
Of course, the charter is just the beginning. So much more goes into an effective team, from the skills individual team members bring to the goals they work together to achieve.
Even as expectations change over the team’s lifetime, team members should never lack clarity on why the team exists, or on how they can show up and contribute!
Top comments (0)