A team charter is a short, shared document that records why a team exists, what it values, how decisions get made, and how members agree to work together. Teams write it at the start of their work and revisit it whenever something changes. The builder below produces one on a single page, free and ungated.
The charter records how you will work. To see how your team actually fits together, run the free team personality assessment and get a live map of everyone's working styles.
The charter builder
Fill it in together on a screen share, or draft it solo and let the team argue with the draft. Everything stays in your browser: no account, no upload, and the result prints onto one page or copies out as Markdown.
Start from a preset, or from nothing. Everything stays editable.
The test of a good purpose line: would a stranger reading it know what your team should say no to?
Hover a value to see the plain-language meaning it carries into the document.
Meetings
Communication
Decisions
Feedback
Five to eight is the sweet spot. Two norms your team keeps beat ten it admires.
One name per line. Shared ownership is how work gets orphaned politely.
Every standing meeting should be able to say what it is for in one phrase.
Two or three measures are plenty. The review date is the difference between a document and a decoration.
Team charter
Your charter assembles itself here as you fill in the form. Start from a preset above if you want something to react to instead of a blank page.
Saved in your browser as you type. Nothing is uploaded, and nothing here needs an account.
A practical note on how to use it. The presets are complete, realistic charters, so the fastest route is to load the one nearest your situation and edit it against your own frictions. Drafting solo first is fine, and often better than a cold-start meeting, as long as the team gets to argue with the draft before anyone signs it. The meeting agenda below is built for exactly that argument.
What a charter is
A team charter is the answers a team will eventually need, written down before anyone needs them. Why do we exist, what do we protect, how do we behave, who holds what, and how do we decide when we disagree. On one page, drafted by the team rather than for it, and signed by the people it describes. It goes by other names in other places: team agreement, team contract, ways of working. The shape is the same.
The reason to write one early is that the alternative is not "no charter". Every team acquires working rules within weeks, set by precedent and by whoever spoke first, and unwritten rules are the hardest kind to change[5]. In a classic study that followed real project teams from first meeting to deadline, the approach each team fell into in its very first meeting tended to persist all the way to the project's midpoint[4]. Group researchers have described this norm-forming stage since the 1960s[6]. A charter is simply the choice to set those defaults on purpose.
Does it help? The evidence is moderate and worth stating precisely. In a semester-long study of project teams, the teams that produced high-quality charters and performance strategies early sustained higher performance across the term, while otherwise similar teams faded as the work got harder[1]. Teams required to charter showed measurably better teamwork behaviours than matched teams that skipped it[2], and qualitative work on real organisations finds early explicit agreements act like psychological contracts: they make later friction discussable instead of personal[3]. Google's own study of 180 of its teams points the same direction from another angle: how a team worked together mattered more than who was on it[8].
The honest read
Most charter research is on student and project teams, so effects on long-standing workplace teams are inferred rather than measured. What predicted performance was charter quality, not the existence of a document: a template filled in to be filed does nothing. And no page of agreements compensates for the wrong people, the wrong goal, or a leader who ignores it. Treat a charter as a well-supported bet with a very cheap downside: an hour, honestly spent.
Three research threads meet here. Team-design work, most visibly Hackman's, argues that effectiveness is set less by daily coaching than by conditions established up front: a compelling direction, an enabling structure, clear norms of conduct[7]. Process research sorts teamwork into phases and places mission analysis, goal specification, and strategy formulation in the "transition" phase between episodes of work, which is exactly the work a charter forces[9].
The third thread is practice: agile software teams normalised the "working agreement" as a lightweight, revisable norms document. The modern one-page charter is those three threads braided together, and it is why the builder above asks for purpose and structure as well as etiquette.
What goes in one
Seven sections cover almost every team. This is the exact template the builder produces, and each piece has to earn its place on the page.
One or two sentences, written to exclude. A purpose no reasonable team could disagree with ("deliver value collaboratively") excludes nothing, and so decides nothing. Name the work, the people it serves, and by implication what you will say no to. Teams argue about purpose once at the start, or weekly forever.
"We exist to migrate every customer to the new platform without breaking their week."Three to five, each with a plain-language meaning attached, because a bare word like "quality" agrees with everyone and binds no one. The test of a real value is that you can name the moment it would cost you something. In the builder, every value carries its meaning into the document automatically.
"Candor: we say the hard thing early, kindly."The load-bearing section: five to eight rules phrased as behaviour someone could witness, not virtues to aspire to. Norms deserve their own treatment, so the full section with twenty examples is below.
"We reply within one working day, even if only to say when."One line of responsibility per role, one name per line. This is not an org chart; it is a promise about who catches what. Shared ownership reads as generous and functions as orphaned.
"Risk keeper: owns the risk list and says the uncomfortable thing early."The section most templates skip and most teams need first. A team that has never named its decision rule discovers it during its first real disagreement, which is the most expensive possible moment. The builder offers five defaults:
Every standing meeting, with its rhythm and its purpose in one phrase. A meeting that cannot say what it is for in one phrase is a calendar habit, and the charter is a polite place to notice that.
"Friday review: 20 minutes, what shipped and what slipped."Two or three success measures with a number or a date inside them, plus a review date for the charter itself, written down now. The review date is the difference between a document and a decoration.
"Every customer migrated by 28 March, with zero data loss."Three examples
The builder's presets, rendered as finished documents. Steal the shapes, not the sentences: a team charter example is a pace-setter, and yours should sound like your team. If you need a sample to show a sceptical sponsor, print any of these.
Team charter
Why we exist
Ship the Atlas rollout by the end of Q1: migrate every customer to the new platform without breaking their week. We exist so that one team owns the move from first email to final cutover, instead of five departments owning a fifth each.
What we value
How we work
Who holds what
| Project lead | Priorities, scope calls, and the tie-break when we stall |
| Delivery owner | The plan, the dates, and the definition of done |
| Customer voice | Brings real customer reactions into every review |
| Risk keeper | Owns the risk list and says the uncomfortable thing early |
How we decide
One owner decides, after hearing the team. Fast and accountable. Each decision names an owner who gathers input, decides, and explains the call.
When we meet
How we'll know it's working
What to notice: The purpose names a date and a customer promise, so "done" is never a matter of opinion. Notice how delivery-flavoured the norms are: blockers surface the day they appear, and every decision gets one named owner.
Team charter
Why we exist
Run customer support and success across four time zones without anyone working someone else's hours. We exist to make distance an advantage: round-the-clock coverage, written answers that outlive the conversation, and colleagues who trust each other without sharing an office.
What we value
How we work
Who holds what
| Team lead | Priorities, hiring, and the final call on policy |
| Docs keeper | Keeps the handbook current so answers stay findable |
| Handover editor | Makes the daily time-zone handover readable in two minutes |
How we decide
Consent: we proceed unless someone objects with a reason. Quick for reversible choices. An objection has to name the harm it prevents, not a preference.
When we meet
How we'll know it's working
What to notice: Nearly every norm is about writing. Distributed teams live on defaults like "channels, not direct messages", because the hallway repair that fixes friction in an office does not exist across time zones.
Team charter
Why we exist
Find out whether anyone will pay for this before the money runs out. We exist to learn faster than we spend: build the smallest thing that tests the riskiest assumption, put it in front of real users weekly, and be honest about what we hear.
What we value
How we work
Who holds what
| Product founder | What we build next, and what we say no to |
| Commercial founder | Users, revenue, and the runway maths |
| Technical founder | How it gets built, and which debt we accept |
How we decide
One owner decides, after hearing the team. Fast and accountable. Each decision names an owner who gathers input, decides, and explains the call.
When we meet
How we'll know it's working
What to notice: The awkward subjects (equity, money, workload) get a standing monthly slot before they are urgent. That single line prevents more founder fallouts than any value statement, because it makes the hard conversation routine.
A fourth preset, a leadership team charter with confidentiality and alignment norms, is in the builder above. Load any of the four and edit it against your team's real frictions; an example you have argued with beats an example you have admired.
Team norms
Team norms are the small, shared rules a team runs on: how meetings start, how disagreement is voiced, how fast a message deserves an answer. Every team has them within weeks, because norms crystallise out of early precedents and critical moments whether anyone writes them down or not[5][6]. Writing them is not adding rules to a free team. It is taking the rules that already run the team and putting them where everyone can see, question, and change them.
Twenty concrete team norms examples, grouped by where the friction usually lives. Each is phrased as behaviour you could witness, which is what separates a norm from a poster:
Four properties, in descending order of how often they are missing. Observable: a new member could tell within a week whether the team keeps it. Small: it governs a moment, not a mindset; "cameras optional, contribution not" beats "be present". Invokable: someone mid-meeting can call it without a speech, which is why the process-check norm exists: it is the norm that protects all the others. Answering a real friction: the best norms are autobiographical, written from something that actually happened, which is also why the charter meeting below starts its norms step with a complaint-gathering round.
All twenty are one click away in the builder, and the best charters take four or five of them plus one norm nobody else would need, because it answers a friction only your team has.
Charter vs agreement
The three terms overlap enough to cause meetings about meetings, so here is the clean version. A team working agreement is the norms section of a charter grown into its own document: how we meet, how we message, how we give feedback, and nothing else. The term comes from agile practice, where teams revise it retro by retro. A team charter is the umbrella document: the agreement plus purpose, roles, decision rules, and measures. Team norms are the individual lines inside either.
| Document | What it covers | Length | When it's the right tool |
|---|---|---|---|
| Team charter | Purpose, values, norms, roles, decision rules, meeting rhythm, success measures | One page | New teams, cross-functional teams, and any team inheriting ambiguity from the org around it |
| Working agreement | Norms only, in day-to-day detail: meetings, communication, feedback | Half a page | Stable teams whose purpose, roles, and decision rules are already settled and shared |
| Team norms | The individual behavioural rules inside either document | One line each | Always. Norms are the unit both documents are made of |
If you are unsure which you need, write the charter: it contains the agreement, and the extra sections take fifteen minutes you will otherwise spend in your first real disagreement. The builder produces the full version either way, and a team that only wants the agreement can simply skip the sections it does not need.
The charter meeting
One hour, the whole team, the builder open on a shared screen. The agenda is timed and scripted where scripts help, and it prints for the meeting itself. Running it in 45 minutes works too; the trims are in the footnote.
The team charter meeting 60 minutes · whole team · builder or a blank draft on screen
0:00 – 0:05
Say what the hour is for and what the document is not. A charter written under suspicion reads like a contract; one written openly reads like a promise. Name the review date up front so nothing today has to be perfect.
"We are writing down how we will work so we never have to argue about it mid-crisis. Everything we draft today is a version one, and we review it in a month."0:05 – 0:15
Two minutes of silent writing first, so the first voice does not set the frame for everyone. Then merge the drafts into one sentence. The test of the result: a stranger reading it could name something this team would say no to.
"Two minutes each, silently: finish the sentence 'This team exists so that...'. Then we argue the versions into one."0:15 – 0:25
Everyone picks three from the list in the builder; the overlaps become the shortlist. A value only makes the page if the team can attach a plain-language meaning and name a moment it would cost something.
"A value counts only if we can name the day it would cost us something. Which of these would we still keep on a bad week?"0:25 – 0:40
Start from friction, not aspiration. Three minutes of silent writing: what happened in the last month that a rule would have made cheaper? Then pick or write five to eight norms that answer those moments. Real frictions produce norms the team actually invokes.
"Norms answer frictions we have actually had. What happened recently that a shared rule would have made easier?"0:40 – 0:50
One line of responsibility per role, one name per line, no committees. Then choose the default decision rule out loud, because a team that has never named its rule discovers it during its first real disagreement, which is the most expensive possible moment.
"For each recurring piece of work: who owns it, in one line? And when we disagree, what happens by default?"0:50 – 0:55
Two or three measures with a number or a date inside them. Then book the 30-day review before the meeting ends; the booked date is the difference between a document and a decoration.
"How will a stranger know in three months whether this team is working? And which date are we reviewing this?"0:55 – 1:00
One person reads the whole charter, top to bottom. Anything that makes the room wince gets cut on the spot. Then everyone signs, literally. The mild ceremony matters: it converts a mood into a norm.
"If a line makes anyone wince, we cut it now. Whatever survives the reading is the charter."The most common way this meeting disappoints is politeness: an hour of agreeable nodding that produces a document nobody remembers writing. The silent-writing rounds are the antidote, and so is the facilitator disagreeing with one of their own suggestions out loud, once, to show the draft can take it.
Where personality fits
A charter records the behaviour a team is choosing. Personality is the behaviour each member would default to anyway, and the distance between those two is what a norm actually costs. Rules that run with the grain of the room are cheap to keep; rules that run against it need to be fewer, sharper, and chosen on purpose. That is worth knowing before the meeting, not after the third breach.
It changes what you write. A team of natural talkers needs airtime norms more than it needs "speak up in meetings". A team with no natural finisher needs two hard delivery norms, not six aspirational ones. And the same norm can cost one member nothing and another real, daily effort, which is worth knowing before anyone judges compliance. Personality will not tell you what to value; it tells you where your charter will be tested.
See how your team actually fits together: run the free team personality assessment. Each person answers 60 questions in about 8 minutes, and the team gets one live map of working styles, gaps, and the pairs that deserve a little deliberate care.
Run it before the charter meeting and you will write norms for the team you have, not the team the template imagined.
Questions
A team charter is a short, shared document that records a team's purpose, values, norms, roles, and how decisions get made. Teams write it together at the start of their work and revisit it when something changes. Its value is less the paper than the argument: agreeing the answers out loud before pressure arrives.
Seven sections cover almost every team: purpose, values, norms, roles and responsibilities, a decision-making approach, meeting rhythm, and success measures, plus a review date so the document stays current. If you only have time for three, write the purpose, the norms, and the decision rule. Those are the ones teams fight about later.
Team norms are the behavioural rules a team agrees to run on; a team charter is the wider document those norms sit inside. The charter also records purpose, roles, decision rules, and measures. Every charter contains norms, but a list of norms alone is not yet a charter.
A working agreement is the norms section of a charter grown into its own document, and the term is most common on agile teams. It covers how people treat each other day to day. A charter adds purpose, roles, decisions, and measures. Stable teams often need only the agreement; new or cross-functional teams benefit from the full charter.
One page. A charter earns its keep by being read, quoted, and waved at during disagreements, and nobody quotes page four. If yours is growing, move detail into linked documents and keep the charter as the index: one purpose sentence, three to five values, five to eight norms, one decision rule.
The team writes it together; one person may hold the pen, but not the answers. A leader-written charter reads as policy and collects polite nods instead of real commitment. The research on charters comes from teams that built them jointly, and the shared argument appears to be most of the mechanism.
At the start, ideally within the first week or two of working together. Research on project teams found that the patterns set in a team's first meeting tend to persist to the project's midpoint, so early defaults harden fast. An established team can still charter; time it to a natural reset like a new goal, leader, or member.
Review it after the first month, then quarterly, and always when membership or mission changes. The first review matters most: it catches norms that sounded good and turned out to be decoration. A review takes fifteen minutes: which line earned its place, which line nobody used, and what needs adding.
No. A template gives you the sections; the value comes from the argument your team has while filling them in. In the study that made charters credible, quality was what mattered: teams with thoughtful charters sustained performance while teams that treated the exercise as paperwork faded. Use a template to start the conversation, not to skip it.
A good team norm is observable, small, and phrased as a behaviour rather than a virtue. "We reply within one working day" can be seen and invoked; "we communicate well" can only be nodded at. The test: could a new member tell, within a week, whether the team actually keeps it?
The evidence is moderate, and honest pages say so. In a semester-long study of project teams, those with high-quality charters and performance strategies sustained higher performance while similar teams declined, and later studies found better teamwork behaviours. Most of this research is on student and project teams, so treat a charter as a well-supported bet, not a guarantee.
Usually a working agreement covers the day to day, and many agile teams stop there happily. A full charter adds purpose, roles, and decision rules, which earn their place when a team is new, cross-functional, or inheriting ambiguity from the organisation around it. If your retros keep circling the same conflict, that is often a missing charter section talking.
Keep reading
A charter is an hour of arguing that replaces a year of guessing. Draft yours in the builder above, book the meeting, and let the document be wrong out loud, where it can be fixed.
Methods & sources
The structure of the builder follows the team-effectiveness literature rather than consultancy folklore. The headline evidence: in a semester-long study of project teams, those that produced high-quality charters and performance strategies early sustained higher performance while otherwise similar teams faded[1]. Required charters improved observable teamwork behaviours in classroom comparisons[2], and qualitative work on real teams finds early explicit agreements function like psychological contracts, keeping later friction discussable[3]. The emphasis on the first weeks comes from the first-meeting persistence finding[4] and from norm-formation research[5][6]; the section list maps onto Hackman's enabling conditions[7] and the transition processes of the Marks taxonomy[9].
Limits, stated plainly: most of this research is on student and project teams, effect sizes are modest, and what predicted performance was the quality of the thinking, not the existence of a document. A charter is decision support for how a team runs. It is not a substitute for the right people, a real goal, or a leader who means it.