Team Charter Template

Eight questions a team answers once, together. Questions rather than headings, because a charter filled in by whoever talks most is a charter nobody follows.

What kind of team

Optional. Printed at the top of the charter.

Team charter

Product or engineering team

  1. 1. What this team is for

    If your team disappeared for a month, what would break first, and what would nobody miss?

    A team that never agreed this says yes to everything that arrives, because nothing on the list is obviously not its job.

    • We own checkout end to end: if money moves through it, it is ours, including the parts we did not write.
    • We do not take on internal reporting requests. If one arrives, we send it to the data team and tell the requester the same day.
    • If a piece of work does not change what a customer can do, it needs a named reason before it goes on the board.
  2. 2. How we decide

    For the decisions you make every week, who decides, who has to be asked first, and what happens when they disagree?

    Skip it and the default is that whoever is most senior in the room that day decides, and the room changes every day.

    • Anything reversible within a day: whoever is doing the work decides, and posts what they chose.
    • Anything that changes the public API needs the engineering lead and the designer to agree. If they have not agreed by Thursday, the engineering lead decides.
    • If a decision has been open for three days with no new information, we take the cheaper option and move.
  3. 3. Who owns what

    For each thing you own, who is the one person a question goes to, and who covers for them when they are away?

    Work with no owner does not stop. It gets picked up late by whoever notices, and it is the same person every time.

    • Every service has one named owner in the service list, and the team is not a valid entry.
    • The owner is the person who says yes or no to a change, not the only person allowed to touch it.
    • If an owner is away for more than two days, they name their cover in writing before they go.
  4. 4. How we communicate

    Which channel is for which kind of message, and how quickly should somebody expect an answer from you in each one?

    With no agreed response time, silence gets read as an answer, and half the team reads it the opposite way to the other half.

    • Anything the whole team needs goes in the team channel. Direct messages are for things that concern one person only.
    • A question in the team channel gets an answer the same working day, even when the answer is 'not today'.
    • If a thread reaches ten replies without resolving, somebody calls fifteen minutes and posts the outcome back into the thread.
  5. 5. Our meetings

    Which meetings do you hold, what is each one for, and what would have to be true for you to cancel one?

    A meeting nobody agreed to keeps running long after the reason for it has gone, because everyone assumes somebody else still needs it.

    • Fifteen minutes each morning, and it is for blockers only. Everything else moves to a thread.
    • Any meeting without an agenda posted the day before is cancelled by whoever notices.
    • If nobody can say what a meeting is for, we drop it at the quarterly review rather than keeping it out of politeness.
  6. 6. How we disagree

    When two of you cannot agree on how to build something, what happens next, and by when?

    Teams without a way to disagree do not stop disagreeing. They do it after the meeting, in smaller rooms.

    • We spend at most one day disagreeing about anything reversible. Then we build the cheaper option and look at what happens.
    • If two engineers disagree on an approach, they write a paragraph each and the engineering lead picks by the end of the day.
    • Once it is decided we build it that way properly, including the person who argued against it.
  7. 7. What done means

    What has to be true before you call something done, and who is allowed to say it is not?

    Without this, finished means whatever the person handing over needs it to mean, and the person receiving it finds out later.

    • Done means merged, released, monitored, and seen working by the person who asked for it.
    • Documentation is part of done, never a follow-up ticket.
    • If it needs a runbook to operate, it is not done until the runbook exists.
  8. 8. How we change this charter

    When will you read this again, and what would make you change a line of it before then?

    A charter with no review date gets written once, filed, and quietly contradicted by the first difficult week.

    • We read this at the start of every quarter and delete anything we did not actually do.
    • Anyone may propose a change in the team channel. If nobody objects within two working days, it is in.
    • A rule we have broken three times gets changed or dropped, not repeated more loudly.

Answer these together rather than filling them in for the team. The examples are the shape to aim for: a rule somebody could break, not a value nobody could disagree with.

Ask the team this, privately

Put it on a slide and your audience joins from their phones — no app and no accounts for them. Free to start.

Ask the team this, privately

Run it live, not just on paper

Everything these tools make can become a slide your audience joins from their phones — no app, no accounts for them.

Create a presentation