How to Write a Team Charter in One Page

Teams form faster than they agree on how to work. A new group gets pulled together for a project, a reorganization merges two teams, or a team that has existed for years discovers that nobody can say what it is actually responsible for. A team charter is a short document that answers those questions in writing.

Atlassian describes a team charter as a record of a team’s purpose, roles, and working agreements, and that is a good working definition. The trick is keeping it short enough that people read it, and specific enough that it settles real arguments.

Start With Purpose And Ownership

The two most useful sections are the first two. If a charter does nothing else, it should say why the team exists and what it owns.

Before:

The Platform team is dedicated to driving excellence and innovation across our technology stack, empowering teams to deliver value to customers.

After:

Purpose: Make it fast and safe for product teams to ship. We own the deploy pipeline, staging environments, the internal component library, and on-call for shared infrastructure. We do not own product features, the data warehouse, or customer support tooling.

The “we do not own” list is the part people will use most. Most cross-team friction comes from work that two teams each assume belongs to the other.

Name Roles, Not Just People

List who does what, by role, so the charter survives people joining and leaving:

• Lead: sets priorities and is the escalation point.
• On-call: rotates weekly; first responder for pipeline and staging issues.
• Intake owner: triages requests from other teams every Monday and Thursday.

If roles overlap or are unclear, the charter is a good place to settle it. If they are unsettled because nobody has decided, write that down and decide.

Write Working Agreements People Can Check

Working agreements are where charters become vague. “We communicate openly” means nothing. Agreements should be observable.

• Requests from other teams go through the intake form, not direct messages.
• We reply to intake requests within two working days, even if only to say when we will start.
• Decisions that affect other teams are written up in a decision log entry within a day.
• Core collaboration hours are 10am to 3pm UK time; outside them, nobody is expected to reply.

Each one can be checked against reality, which means it can be enforced or revised.

Define How Success Is Measured

Two or three measures are enough, ideally ones the team already tracks: deploy frequency, time to resolve internal requests, uptime of shared systems. If your organization uses OKRs, link to them rather than duplicating; how to write OKRs that are not a task list covers the outcome language that also works here.

Keep It To One Page

A charter longer than a page tends not to be read. The sections, roughly:

1. Purpose (two sentences).
2. What we own, and what we do not.
3. Roles.
4. How to work with us (intake, response times, channels).
5. Working agreements.
6. How we measure success.

Put it where people look: the team’s wiki page, the channel description, the top of the intake form. Review it every six months or after any significant team change, and date each version.

A Context For Team Documents

A Wrivio Context for team charters could say:

Rewrite this as a one-page team charter with these headings: Purpose, What We Own, What We Do Not Own, Roles, How To Work With Us, Working Agreements, How We Measure Success. Replace vague phrases such as “drive excellence” with the concrete responsibilities and agreements already in the notes. Keep every team name, system name, time, and number exactly as written. Do not add responsibilities, roles, or commitments that are not in the draft.

Press Ctrl+Shift+Space, paste the workshop notes, and review the diff. The ownership lists are the part to check hardest: a rewrite that quietly moves a system from “do not own” to “own” has just changed the team’s job.

Common Questions

What should a team charter include?

The team’s purpose, what it owns and does not own, roles, how other teams should work with it, working agreements, and how success is measured. One page is usually enough.

Who should write the team charter?

The team should draft it together, often in a short workshop, with the lead responsible for finishing and publishing it. A charter written by one person and announced to the team tends not to stick.

How often should a team charter be updated?

Review it every six months, and after any significant change such as new members, a reorganization, or a new major responsibility. Date each version so people know it is current.

What is the difference between a team charter and a project charter?

A project charter describes a temporary piece of work with an end date. A team charter describes how an ongoing team operates, regardless of which projects it is running.

Download Wrivio for Windows to turn messy workshop notes into a crisp one-page team charter.