Free template
A team charter template for engineering teams.
Mission, what you own, who's on the team and where, the hours you share across time zones, how you communicate, your rituals, code review and on-call, a definition of ready and done, and how you handle time off. Tick what fits and copy a finished charter.
Filled in with an example payments team. Change anything.
Payments charter
Agreed by the whole team. Revisit it every six months, and whenever someone joins or leaves.
Mission
Customers can pay, get refunds and download invoices without thinking about it, and finance can trust every number we send them.
What we own
- checkout-api and the checkout UI
- Stripe and Adyen integrations, including webhooks
- Invoices and receipts emails
- Payments on-call
Not ours (send these elsewhere):
- Pricing pages and plans (Growth team)
- Tax rules (Finance systems)
People and roles
| Name | Role | Time zone |
|---|---|---|
| Ana | Engineering lead | Berlin, Amsterdam, Paris (Europe/Berlin) |
| Tariq | Senior backend engineer | London, Dublin (Europe/London) |
| Priya | Backend engineer | Bangalore, Mumbai (Asia/Kolkata) |
| Jess | Frontend engineer | New York, Toronto (America/New_York) |
| Leo | Product manager | New York, Toronto (America/New_York) |
Core hours
Everyone works roughly 09:00–17:00 in their own time zone.
There's no time when all 5 of us are working. The best window has 4 of 5 (missing: Priya).
| Time zone | Best window |
|---|---|
| Berlin, Amsterdam, Paris | 15:00–17:00 |
| London, Dublin | 14:00–16:00 |
| Bangalore, Mumbai | 18:30–20:30 |
| New York, Toronto | 09:00–11:00 |
So we work async by default, record every team meeting, and rotate the time of the ones we hold so the same people aren't always up late.
Worked out for 2026-10-17. Daylight saving time moves these by an hour in March, October and November.
How we communicate
- @mentions get a reply within 4 working hours. Urgent means a page, not a DM.
- Async first: write it down before you book a meeting. A meeting needs an agenda and a written outcome.
- Ask in the team channel, not in DMs, so the answer helps the next person.
- Keep your Slack status and calendar current: focus time, out sick, on vacation.
- Nobody is expected to answer outside their working hours. Schedule messages instead of sending late at night.
- Wednesday afternoons are meeting-free. No meetings, no expectation of quick replies.
- Cameras on for small meetings (under 6 people) when you can, optional for larger ones.
- Decisions are written down in: Architecture Decision Records (ADRs) in the repo, under docs/adr. If it isn't written down, it wasn't decided.
Rituals
| Ritual | When | Length | What it's for |
|---|---|---|---|
| Standup | Daily | 15 min | What's blocked and who needs help. Status updates go in the ticket. |
| Sprint planning | Every 2 weeks | 60 min | Agree the sprint goal and pull work up to capacity, after time off. |
| Backlog refinement | Weekly | 45 min | Get the next sprint's tickets to ready. |
| Retro | Every 2 weeks | 45 min | One or two changes we'll actually make, each with an owner. |
| Demo | Every 2 weeks | 30 min | Show working software to stakeholders. No slides. |
Every recurring meeting has an owner. If it stops being useful, anyone can propose cutting it at the retro.
Code review
- First review within one working day. Reviews come before starting new work.
- Keep PRs small: aim for under 400 changed lines. Split bigger changes behind a feature flag.
- One approval to merge. Two for payments, auth, migrations and infra.
- The author merges and watches the deploy.
- Label comments: "nit:" is optional, "blocking:" must be resolved before merge.
On-call
- Weekly rotation, primary and secondary, handing over on Monday at 10:00.
- Acknowledge a page within 15 minutes. Escalate to secondary after 30.
- Handover note at the end of each shift: open incidents, noisy alerts, anything half done.
- Swap shifts in the on-call channel and update the schedule yourself.
- Nobody is on call during their time off or a public holiday where they live. Swap at least two weeks ahead.
- Paged overnight? Start late or take the morning off the next day.
Definition of ready
A ticket can go into a sprint when:
- The ticket says what problem it solves and for whom
- Acceptance criteria are written and testable
- Designs are linked and agreed, if there's UI
- Dependencies on other teams are known and unblocked
- Estimated by the team, and small enough to finish in one sprint
Definition of done
A ticket is done when:
- Code reviewed and merged to main
- Unit and integration tests written and passing in CI
- Acceptance criteria met and checked by someone other than the author
- Deployed to production, behind a flag if it isn't ready for everyone
- Logs, metrics and alerts in place for anything that can fail
- Docs, runbook or README updated
Time off and coverage
- Notice: 2 weeks for up to a week off, 4 weeks for longer. Check the company policy with HR for the official rules.
- Put every day off on the team calendar as soon as it's booked, including tentative plans.
- Every critical area keeps at least one person in who can handle it. Check the calendar before you book.
- Before you go: a handover note, your open PRs reassigned, and an out-of-office message.
- Avoid release weeks and the code freeze for long trips, or agree cover early.
- On vacation means offline. Nobody pings you, and you don't check Slack.
- Sick days need no notice: post in the channel and log off.
Critical areas that always need someone in:
- Payments on-call
- Stripe webhook failures
- Month-end invoice run (last working day)
Changing this charter
Anyone can propose a change in the retro or as a PR to this file. We change it when most of the team agrees, and we note the date below.
Last updated: 2026-10-17
Copy pastes as formatted text into Google Docs, Notion or Confluence. Markdown is for GitHub, Jira or Slack.
Save it as TEAM.md in your main repo, or paste it into Notion, Confluence or a GitHub wiki.
What a team charter is, and why engineering teams need one.
A team charter is one page that answers the questions a new engineer asks in their first week, and that the rest of the team argues about in month six. What do we own? When are people around? How fast should I reply? Who reviews my PR? What counts as done? Without a charter, the answers live in the lead's head and in old Slack threads, and each person works to a slightly different version.
Writing it down doesn't make it bureaucratic. It makes disagreements cheaper: when someone merges without tests, the conversation is "we agreed tests are part of done", not a debate about who's right. It also makes the implicit rules visible to people who weren't there when they formed, which matters most for remote and new team members.
Team charter vs working agreement, and where each part goes.
Team charter
Why the team exists and what it's responsible for. Changes when the team's scope changes.
- Mission
- What we own, and what we don't
- People and roles
- Critical areas that need cover
Working agreement
How the team works day to day. Changes at retros, as the team learns what helps.
- Core hours and response times
- Meetings, focus time and cameras
- Code review and on-call
- Definition of ready and done
- Time off notice
Most teams don't need two documents. Keep one file with both parts, as the template does, and put it in your main repo as TEAM.md so changes go through a PR like anything else. The definition of done section works well copied into your pull request template, so it's in front of people when it matters.
When to write one, and when to revisit it.
Write it when a team forms, when two teams merge, when the team first spans more than one time zone, or when the same argument has come up at three retros in a row. Draft it yourself as the lead if you like, but agree it as a team in a 60-minute session: walk through each section, and change anything one person can't live with.
Revisit it every quarter or six months, and whenever someone joins or leaves. A new joiner is the best reviewer: ask them which parts matched what they saw in their first month, and which didn't. Daylight saving time is a good reminder too, because the hours a US and European team share change by an hour for a few weeks each March and autumn.
Team charter examples from three engineering teams.
The parts that make each charter specific to its team. Use them as team agreement examples to start your own discussion.
Platform team, 6 people, one time zone
Owns CI, the Kubernetes clusters and the internal developer portal. Lots of interrupts from other teams.
- One person a week is the "interrupt shield": they take support questions so the others can focus.
- Requests from other teams go in #platform-help, never in DMs.
- Thursdays are meeting-free.
- Any change to production infra needs two approvals and a linked runbook.
Mobile team, 5 people, New York to San Francisco
Ships iOS and Android every two weeks. Three hours of shared time a day.
- Core hours are 12:00–15:00 Eastern. Team meetings happen there and nowhere else.
- Release week has no long vacations without cover agreed four weeks ahead.
- Done includes tested on a real device on both platforms.
- Release captain rotates each sprint, never the person going on vacation that week.
Payments team, 5 people, Bangalore to New York
Owns checkout and billing. The team has no hour when everyone is working.
- Standup is async in Slack by 10:00 local. Live sync twice a week, at alternating times.
- Decisions go in ADRs in the repo. If it isn't written down, it wasn't decided.
- Payments on-call always has one person in each region who can handle it.
- Two approvals for anything that touches money.
Time off norms only work if you can see who's out.
A charter can say every critical area keeps someone in. It can't tell you that the two people who know the release process both booked the same week. Here's a five-person mobile team with three people out in release week, on a live board.
- Everyone's time off on one board
- The release day shows who's away
- A tentative request next to booked ones
- Drag a vacation to a week that works
To find the areas only one person can handle, use the bus factor calculator. If your charter has a lot of rituals, the meeting cost calculator shows what they add up to in a year.
Questions
What is a team charter?
A short document a team writes together that says why the team exists, what it owns, who is on it and how it works: when people are available, how they communicate, which meetings they hold and what done means. It's the page a new hire reads first and the one you point to when there's a disagreement about how things work.
What should a team charter include?
For an engineering team: the mission, the services and areas the team owns (and what it doesn't), people and roles, core hours across time zones, communication norms, rituals, code review and on-call agreements, a definition of ready and done, and how the team handles time off and coverage. Keep it to one or two pages.
What is the difference between a team charter and a working agreement?
A team charter covers why the team exists and what it owns, as well as how it works. A working agreement is the "how we work" part on its own: response times, meetings, code review, cameras, focus time. Many teams keep the working agreement as a section of the charter, which is what this template does.
What are some examples of team norms?
Reply to @mentions within four working hours. Ask questions in the team channel, not in DMs. Wednesday afternoons are meeting-free. First code review within one working day. Nobody is on call during their vacation. Put every day off on the team calendar as soon as it's booked.
What goes in a definition of done checklist?
Code reviewed and merged, tests written and passing in CI, acceptance criteria checked by someone other than the author, deployed to production (behind a flag if needed), monitoring and alerts in place, and docs or runbooks updated. Add accessibility, product sign-off or flag cleanup if they matter to your team.
How often should a team charter be revisited?
Every quarter, or every six months for a stable team, and always when someone joins or leaves, the team takes on a new area, or it starts working across new time zones. A short review at a retro is enough: read it, and change what no longer matches how you actually work.