Team Charters: Writing One That Is Read After Month Two

Six team charters were written in one quarter, and four of them were unread after two months, measured by the document tool’s own view count. The two that survived shared one property: they contained a rule that had already been broken and repaired.

The company had 80 employees in nine teams. Charters were introduced by a new operations lead as a way to make expectations explicit, which they were, and which turned out not to be enough.

What the failed four contained

Values, communication preferences, meeting norms and a definition of done. All reasonable, all generic, and all phrased in a way that could not be disagreed with. A charter that says we communicate openly has never changed a single behaviour.

View counts confirmed what the writing suggested: the documents were opened by their authors, once by a manager, and then not again.

The two that survived

The first contained a rule about response times written after a two-day silence had blocked a release. The rule named the hours and the escalation path, and it had a date and a short paragraph explaining the incident.

The second contained a rule about who could merge code, written after an incident where two people merged conflicting changes. The rule named a role, a review count and an exception for hotfixes.

Why those two were read

Both were consulted when the situation recurred, because both answered a question people actually asked under pressure. A charter that answers a live question gets opened; a charter that describes a culture does not.

The incident paragraph mattered more than expected. It gave the rule a reason, and a rule with a reason survives a change of team membership.

The rewriting exercise

Three of the failed charters were rewritten with one rule each, chosen by asking the team what had gone wrong in the last quarter. Each rewrite took about forty minutes and produced a document of less than a page.

Two of the three rewrites are still consulted. The third addressed a problem that had stopped occurring, which is a fate that any incident-driven document risks.

What the charter cannot do

A charter cannot create a habit. The response-time rule worked because the team already wanted to answer quickly and needed a boundary. Where the team did not want the behaviour, no document produced it.

The operations lead’s own note afterwards said that charters document agreement rather than produce it, which is the sentence the programme should have started with.

The maintenance question

Two charters have been edited twice in nine months, both times after an incident. Nobody has run a scheduled review, and no review date is printed on them.

That is arguably fine: a rule is tested when it is used, and a rule nobody uses does not need reviewing. The risk is a rule that becomes wrong quietly, which is the same risk every document carries.

What the count showed

Of six charters, two survived their second month and a further two survived in rewritten form. The pattern is not about document quality. It is about whether the document answers a question the team asks out loud.

The rule that was never used

One charter contained a rule about decision escalation that was written carefully, agreed unanimously, and never invoked in nine months. It was not wrong; the situation it described simply did not arise, because the team had one decision-maker and no ambiguity to resolve.

The team left it in place. A rule for a situation that has not happened is cheap to keep and expensive to write, which is a balance each team has to strike on its own.

Four of six charters were unread after two months. The two that were read each contained a rule that had already been broken, and that is now the only test the operations lead applies before agreeing to write one.