Team charter: a working version you can write today

TL;DR. A team charter is a short, written agreement that says who your team is, what it owns, how it makes decisions, and how it talks to everyone else. The good ones fit on one page, get re-read on Tuesdays, and change every quarter. The bad ones run to fourteen sections, get filed under Onboarding (final, final), and survive only because nobody remembers where they live. This post is about the first kind — the working document, not the framed certificate.

Most posts about team charter are templates with extra words wrapped around them. We are going to compete on a different axis: the charter as a working document, not as a deliverable to file. The download-the-template-and-fill- it-in version of a team charter has a known failure mode — the team writes one, photographs it, sticks it to the sidebar, and never looks at it again until the re-org makes it false.

The way out of that pattern is small and undramatic. Write less. Revise more. Treat the charter like a runbook, not a constitution. The rest of the post is the working version.

What a team charter actually is

A team charter is a short, deliberate document that answers a small set of questions about how a team works. The standard version, paraphrased from the project- management literature, names six items: purpose, scope, roles, success criteria, working agreements, communication norms. The phrasing varies by source — Atlassian, Miro, Mural, and the Project Management Institute all publish slight variants — but the underlying questions are stable. Who is on this team. What do we own. How do we decide. What does done look like. How do we work together. Where does this team end and another begin.

A team charter is not the same as a project charter. Project charters scope a single project; team charters scope a team that may run several projects in sequence. They share DNA — both are short, both clarify scope, both get adopted by the team in question — but the team charter has a longer half-life and gets revised, where a project charter usually closes when the project does.

For the broader operating-discipline frame on top of any charter, see our knowledge management best practices — the charter is one artifact among many, and it earns its keep only if the rest of the system keeps it current.

The opinion: scaffolding, not finished work

The opinion this post stands behind: a team charter is scaffolding, not finished work. The same opinion drives every template page on this site, and it generalises. A charter that pretends to be a finished contract is a charter that gets buried. A charter that reads like here’s what we’re going to try, until something breaks this is a charter the team will actually re-open on a Tuesday and edit.

Three implications follow.

Charters are short. The good ones fit on one page — six headings, a sentence or two under each, a date at the top, an owner at the bottom. The fourteen-section template asks the team to make decisions they’re not ready to make about a future they can’t predict. The one-page version asks them to commit to what they already know.

Charters are dated. A charter without a last revised date and a next review date is a charter without a clock. The clock is the part that converts the document from written once to living. Most of the value of the document is the cadence around it; some of the value is the words.

Charters are revised. Not annually. Not when the re-org happens. Quarterly, by default — the same cadence many engineering teams use for OKR review or planning. Quarterly is short enough that the document stays true and long enough that the team isn’t writing instead of working.

(Maple, our designer, has the long-form rule: if a template grows past the headings someone can hold in their head, it grows past the headings someone will fill in. The team charter version is the same thing — a fourteen-section charter is a charter someone fills in during onboarding and never opens again. We are not going to argue with Maple.)

What to put in a one-page team charter

Six sections, one paragraph each. The order matters; we have tried other orders and this one survives.

1. Purpose. One sentence on why this team exists. Not we are the platform team; the platform team is on the hook for keeping core infrastructure running for the rest of the engineering org, with a target of zero unscheduled downtime. The sentence is a statement another team could read without context and understand. If it depends on internal vocabulary, simplify it.

2. Scope. Two short bullet lists: what this team owns, and what this team does not own. The second list is the one that pays the rent. Not-owned is what prevents the every-week meeting where someone realises two teams thought they owned the same thing for the past three months. (Patches, our SRE, calls this the fence- posts conversation; we are also not going to argue with Patches.)

3. Roles. Names, not just titles. Lead: a name. Engineering manager: a name. Tech lead: a name. PM: a name. If the team has rotating roles (incident commander, on-call lead), include the rotation pattern. Avoid listing every individual contributor here; that’s what the org chart is for.

4. How we decide. Two cases — small decisions and big decisions. Small decisions get made by whoever owns the area; big decisions go through a named process (consensus, Lead-decides-with-input, RFC + comment). The distinction is yours; the act of writing it down is the charter’s work.

5. How we work. Working hours and time zones, the core sync meetings (when, what for, who attends), how the team uses Slack vs the wiki vs tickets, the agreement on when async is fine and when it isn’t. One paragraph, five lines max. (For the longer treatment of the ticket-vs-doc question, see our Confluence vs Jira post — the same distinction shows up here in miniature.)

6. How we measure. Two or three metrics the team agrees define successful quarter. Specific numbers, not adjectives. Reduce incident MTTR below thirty minutes; ship the new auth service by end of Q3; close the backlog of high-priority tickets to under fifty. Numbers the team knows whether they’re winning on every Friday.

That is the one-page charter. The combined word count of the six paragraphs lands at around three to five hundred words; if you go past eight hundred, one of the sections is doing two jobs.

A working example

A working example, paraphrased and lightly fictionalised, adapted from Raccoon Corp’s own OPS team charter — the team that runs the runbook for the wiki you’re reading this on.

OPS team charter — last revised 2026-04-12 — next review 2026-07-12 — owner: Patches.

Purpose. OPS is on the hook for keeping Raccoon Page available for paying users, with a stretch goal of being faster than every customer’s expectation.

Scope. Owns: production reliability, on-call, incident response, capacity planning, the Hangfire job runner, the Postgres tier. Does not own: feature work, editor performance, the marketing site. Edge cases go to Rocket.

Roles. Lead: Patches. On-call rotation: weekly, three-person, documented in the OPS space. Incident commander: rotates with the on-call lead. Capacity liaison: Chrome Claw.

How we decide. Small decisions (deploy windows, Hangfire concurrency tweaks): made by whoever’s on shift. Big decisions (datastore changes, runbook rewrites, on-call schedule changes): RFC + 48-hour comment window, decision by Lead.

How we work. Core sync: 09:30 PST Tue/Thu, 30 minutes, optional unless on-call. Async-default elsewhere. Slack for live; wiki for everything that outlives the week. Tickets for work in flight; pages for runbooks and postmortems.

How we measure. MTTR under thirty minutes; error budget at 99.95% rolling 28-day; weekly on-call burnout score under 3 (1-5 scale, anonymous).

That’s the charter. About two hundred and twenty words. The team re-reads it at the start of every quarterly review; the document changes when the team changes.

If you want a starting template that’s shaped exactly like this, the templates index has the working version — copy the page, fill the six sections, date it, schedule the review. The charter you write today is the charter you’ll edit; both versions are valuable.

When the charter is most useful

The charter pays back across a small set of scenarios. Knowing which scenario you’re in is most of the value.

Team formation. A new team — engineering, product, ops — usually spends its first two weeks negotiating implicit answers to the six questions above. Writing the charter on day three turns the negotiation explicit. The team that argued about decision-making in week six tends not to argue about it in week one if the charter says how they decide.

Re-orgs. A team whose composition changes — a new lead, a merged team, a split team — needs the charter the same way a new team does. The fastest re-org we’ve seen at Raccoon Corp finished with a half-day of charter rewriting; the slowest one didn’t write the charter and was still arguing about ownership in February.

Onboarding. A team charter is the first thing a new member should read. It’s not the only document, but it answers more who-decides questions in a single page than the rest of the wiki combined. The signal that the charter is good: a new joiner reads it on day one and asks fewer questions in week one than the previous joiner did.

Cross-team conflicts. Two teams who think they own the same thing usually have unaligned charters. A fifteen-minute conversation comparing the scope sections of both charters resolves most of the unaligned ones; the rest become the case for a third charter (the platform team, the joint working group).

The pattern: charters are most useful at moments of ambiguity. The rest of the time they sit in the wiki and don’t earn their keep — which is fine, because the moments of ambiguity are when they pay back.

Common charter failure modes

Four ways teams write charters that don’t survive contact with the team.

The fourteen-section template. Filled in once, never opened again. The headings ran out of patience before the team did. Fix: cut to six sections; make the team write their own version of the headings, not fill in the template’s.

The unsigned charter. No owner, no last-revised date, no next-review date. A charter without a clock isn’t a charter; it’s a wall poster. Fix: every charter has a name and two dates at the top. Both dates change when the team revises.

The charter that mirrors the org chart. Every member listed by name, every responsibility assigned. Reads like a job description. Fix: the org chart is the org chart; the charter is how the team works as a team. Names appear only for non-obvious roles (lead, IC, PM).

The aspirational charter. We are a team of high-performers committed to excellence and innovation. Words that don’t survive a Friday standup. Fix: every sentence in the charter should be a claim that could be falsified by next week’s behaviour. We hold a fifteen-minute standup at 09:30 PST every Tuesday and Thursday. That sentence is true or false; committed to excellence is neither.

The pattern across all four: charters die when they stop being a working description of how the team operates and start being something else (a wall poster, a wishlist, a job description). Keep the charter close to the ground; revise when the ground moves.

When you don’t need a team charter

Honest section. Not every team needs a charter. The category sells itself harder than it needs to.

You are a team of two and you have lunch together. Most of what a charter codifies — how you decide, how you work — already lives in the conversation. Write it down when a third person joins, not before.
Your team’s purpose is set externally and there’s nothing to negotiate. A contract-shaped engagement with fixed deliverables, a fixed timeline, and a fixed team has most of the questions answered for it. A short who-owns-what note is enough; a charter is over-engineering.
Your team is going to dissolve in a quarter. A three-month task force doesn’t need a charter that outlives it. The kickoff doc is enough.
You wrote one in a previous role and you can copy it. This is not actually a reason to skip the charter; it’s a reason to write a new one reflecting the current team. Copying yesterday’s charter into today’s team is how the aspirational charter failure mode shows up.

For the operating-discipline framing on top of any of these decisions, our knowledge management best practices covers the cadence work that keeps the document current — which is most of the work.

Things people actually ask

What is a team charter? A short, written agreement — usually one page — that documents the team’s purpose, scope, roles, decision- making process, working norms, and success metrics. The canonical version answers who, what, how, and how-do- we-know in a way the team revises on a regular cadence.

What should a team charter include? Six sections work for most teams: purpose (one sentence), scope (owned and not-owned), roles (named, not titled), decision process (small and big), working norms (sync meetings, async tools, time zones), and success metrics (two or three numbers). Total length: three to five hundred words.

What is the difference between a team charter and a project charter? A team charter scopes a team over time; a project charter scopes a project until it closes. Teams outlive projects. The team charter has a longer half-life and gets revised quarterly; the project charter usually closes when the project does. Both are short and both clarify scope.

Who writes the team charter? The team. The lead drafts the first version; the team edits in a single working session (one to two hours); the charter is signed only when every team member reads it and the lead commits to revising it on the next review date. A charter written by the lead alone is a job description; a charter written by HR is a wall poster.

How long should a team charter be? One page. About three to five hundred words across six sections. If you find yourself past eight hundred words, one of the sections is doing two jobs and the team is going to skim past both.

How often should a team charter be revised? Quarterly is the default that survives most teams. A fixed next-review date at the top of the document is the part that makes revision happen; without the date, the charter ages out of true and stops being read.

Where do you keep the team charter? In the wiki the team uses. The charter belongs in the team’s space, linked from the team’s homepage, with a short URL anyone on the team can remember. (For the broader argument about where this lives — wiki vs ticket — see our corporation wiki explainer.) On Raccoon Page, every team space’s homepage links to the team charter and the charter’s next review date is visible from the homepage.

A team charter is one of the cheapest pieces of operating infrastructure a team can put down. The whole document fits on a page; the whole revision fits in an hour. The work isn’t the writing — it’s the cadence around the writing. Date the page, name the owner, schedule the review, edit when the team changes. The charter your team keeps current is the charter that earns its keep. The charter that doesn’t, doesn’t.

If you want a starting template, the templates index ships a one-page version with the six sections pre-headed and a prompt under each. Copy it, delete the prompts, fill the sections, date the page. Raccoon Page Free is three users, one space, one hundred pages, no card — enough room to write the charter, and the team docs it sits next to.