--- title: "Team Charter Guide for Software Engineering Teams" description: "How to write a team charter for a software engineering team: 18 Confluence pages, from North Star and customer-area KPIs to Done, each with a worked example." url: "https://www.marian.coach/blog/team-charter-guide/" lang: "en" image: "https://www.marian.coach/images/blog/team-charter-guide/infographic.webp" --- Most teams I work with can deliver software. The trouble is the loop they deliver it in. Short-term focus, then pressure, then compromises, then debt, then inefficiency, then more pressure. Every sprint runs at full speed and carries a few shortcuts by design. There’s never a sprint to clean up after the last one. The people in that loop are rarely lazy or bad at their jobs. They’re tired, and most of them can’t tell you what the client got out of the last quarter. They can tell you what shipped. A **team charter** is a short set of pages, usually in Confluence, that says what a team is for, who it serves, how it measures success and how it works. It’s where you break that loop on paper first, including what the team agrees to stop doing so the rest can happen. The line I keep coming back to when I help leaders write one: > We don’t want to do more work. We want to create more value, with quality, efficiently, and in a way we can sustain. In my First 90 days talk the charter is week four of month one (the whole plan is in the first 90 days as engineering manager). It can’t come earlier, because in the first three weeks you listen, meet everyone [1:1](https://www.marian.coach/blog/one-on-ones/) and learn the product. And it shouldn’t come later, because by month two the team needs something to hold on to while you start changing how it works. ![Hand-drawn loop: the North Star, set for 12-18 months, leads to 3-5 customer areas, then to team OKRs, then to your work. A green arrow labelled quarterly review runs from your work back to the North Star.](https://www.marian.coach/images/blog/team-charter-guide/infographic.webp) ## Four pillars behind every page Each page of the charter below belongs to one of four pillars, and you’ll see the tag above each one. **Focus and client value.** Fewer priorities, more stable ones, less jumping between them. The team understands what it delivers, who the client is and what value it brings them. Permanent firefighting isn’t high performance, and it won’t become high performance. **Quality.** Done means done, not deployed to a test environment. The formula is short: **Done = Delivered + Stable + Maintainable + Operable + Valuable**. **Efficiency and innovation.** First simplify, then standardise, then automate, and only then add capacity. Sometimes the best automation is deleting the process. Tech debt gets an agreed share of capacity instead of a promise. **Sustainable performance.** Performance you can keep up for years, as opposed to one quarter: people who grow, stable priorities, overtime that is rare and always paid back. ## How to read the 18 pages Every section has two sides. On the left, what the page is for, how to write it, the trap most teams fall into and one question to ask your team. On the right, the same page filled in for a made-up team, the way it would look in Confluence. The example company is Routewise, which sells scheduling software to plumbing and heating firms. Its Field Operations stream has four teams. You follow one of them, Dispatch: seven people who own the scheduling engine, the route optimiser and the dispatcher’s board. Every name, number and ticket on the right is invented, and they stay consistent from page to page, so you can see how the North Star flows down into one engineer’s Tuesday. Two pages sit at stream level: the North Star and the quarterly customer-area review. They belong to all teams in the stream. The other sixteen belong to one team, with the team home page carrying the mission. Want to start from blank pages? [Download the team charter template](https://www.marian.coach/downloads/team-charter-template.zip) (27 KB zip). It holds the same 18 pages as Markdown files that paste straight into Confluence, plus one Word file for Confluence’s Word import. Focus & client valueStream page · 1 of 18 ## Stream North Star The charter starts one level above the team. Each stream agrees a North Star for the next 12-18 months: where the product is heading, described as 3-5 customer areas you can measure. How to write it - Name each customer area as a job the client gets done ("plan the day"), not a component ("scheduling service"). - 3-5 areas. Two is a feature, eight is a wish list. - Each area gets 1-3 metrics with today's baseline and an 18-month target. No data yet? Write down how you'll get it next quarter. - Add one North Star metric on top. The area metrics feed it, and teams move those directly ([Amplitude](https://info.amplitude.com/rs/138-CDN-550/images/Amplitude-The-North-Star-Playbook.pdf)). - Put the metrics on a dashboard every person in the stream can open. Look at it together every month. - Every area has an owning team. An area with no team is a hole in the plan. The trap A North Star that's a revenue target. Revenue lags; it tells you in nine months what went wrong. Client behaviour moves first, so measure that. Ask your team"If this works, what does the client do in March 2028 that they can't do today?" Example page · fictional stream Field Operations ⭐ Field Operations North Star 2027-28 KVOwned by @Karel Vondra · Last updated 15 Sep 2026 i Horizon: **October 2026 to March 2028.** Reviewed every quarter in the [customer-area review](#review). By March 2028, a service company runs its whole field day in Routewise. Every job is planned the evening before, the technician arrives when we said, the job is fixed on the first visit, and the end customer never has to call to ask where anyone is. ### North Star metric Perfect jobs Share of jobs that are on time, fixed on the first visit and trigger no "where is my technician" call. 46% → 70% Q3 2026 → Q1 2028 ### Customer areas | Area | What the client gets | Metrics · baseline → target | Team | | --- | --- | --- | --- | | **Plan the day** | The dispatcher builds tomorrow and trusts it | Schedule build time 22 → 10 min Jobs auto-scheduled, no manual edit 52% → 75% | Dispatch | | **Get there on time** | The technician arrives inside the promised window | On-time arrival 81% → 92% | Dispatch | | **Fix it first time** | The technician has parts, history and skills | First-time fix rate 71% → 85% | Field App | | **Keep the customer informed** | The end customer knows when, who and why | "Where is my technician" calls per 100 jobs 11 → 3 End-customer CSAT 4.1 → 4.5 | Notify | 📈 Live dashboard: [Field Ops customer areas](#kpis), refreshed daily, open to everyone in the stream. Focus & client valueTeam home page · 2 of 18 ## Team mission One or two sentences that say what your team does and for whom. If you can't explain it in two sentences, the scope is too wide. How to write it - The bold line names who you serve and the outcome they get. No technology in it. - One paragraph underneath says why it matters to the business. - Name the customer areas from the North Star that your team owns. - Keep it stable for about a year, while the OKRs change every quarter. - This is the home page of the charter. Keep it short enough to read on one screen and link the rest. The trap "Build and run scalable scheduling microservices." That describes your code. The client doesn't buy microservices. Ask your team"Who would notice first if our team disappeared tomorrow, and what would break for them?" Example page · fictional team Field Operations / Teams 🚚 Dispatch: team charter JHOwned by @Jana Horáková · Charter v3 · Reviewed 15 Sep 2026 · Next review 14 Dec 2026 ### Mission Dispatchers build tomorrow's schedule in under 10 minutes and trust it, and technicians arrive inside the window the customer was promised. Scheduling is the first thing a service company does every morning and the last thing it does every evening. When the plan is wrong, everything after it goes wrong too: late arrivals, wasted drive time, angry end customers. We give dispatchers a plan they don't rebuild by hand, so a 40-technician firm can run its day with one dispatcher instead of three. ### Customer areas we own Plan the day Get there on time ### Start here - [Scope & ownership](#scope) - [KPIs & OKRs](#kpis) - [Roadmap](#roadmap) - [The crew](#crew) - [#dispatch-help](#comms) Focus & client value3 of 18 ## Scope & ownership What you own, by name, and what you don't, with who does. Scope sets how much a team has to hold in its head, and that is limited ([Team Topologies](https://teamtopologies.com/key-concepts)). How to write it - Split **services** (they run in production and page you) from **components** (libraries you evolve and others use). - Map ownership along the client's journey, as jobs to be done. It shows gaps a list of repos hides. - Write a "we don't own" list with the owning team next to each line. - List the surface areas: the screens where your jobs show up in the product. - Anything shared gets one named holder. The trap Using the charter to say no to every ask. Gergely Nemeth warns against weaponising it ([source](https://nemethgergely.com/blog/team-charters)). The scope page should send people to the right team. Ask your team"What were we asked to do last month that nobody owns?" Example page · fictional team Field Operations / Teams / Dispatch: team charter 🔭 Scope & ownership ### Services we run (we get paged) - [sched-svc](#scope): assigns jobs to technicians by skill, location and free capacity. - [route-opt](#scope): builds each technician's daily route and the ETAs. - [dispatch-board](#scope): the dispatcher's web board. ### Components we evolve (others use them) `capacity-calendar` · `eta-calc` · `skills-taxonomy` ### Jobs-to-be-done ownership Plan capacity Set working hoursBlock leaveSkill tags Assign jobs Auto-assignManual reassignEmergency insert Route Build routesCalculate ETAsMaps & geocoding Run the live day Drag & drop changesJob status syncTechnician app Close the day End-of-day reportCustomer SMSInvoicing we own shared, named partner not ours ### We don't own
Technician mobile appField App
SMS & email to end customersNotify
Maps provider, CI/CD, observabilityDelivery Platform
InvoicingBilling stream
Surface areas: Dispatcher board (`/board`), Settings → Working hours, public API `/v2/schedule`. Focus & client value4 of 18 ## Customers & personas Who the client is, in one page. A persona is a realistic description of a typical user, and it has to come from research on real people ([NN/g](https://www.nngroup.com/articles/persona/)). How to write it - 1-3 primary personas, each with their job to be done and top pain. - Link the research each one came from: interviews, tickets, recordings. - Tie every persona to the customer area it lives in. - Internal teams name their internal customers: the teams that consume them. - Keep only details that change a decision. Hobbies don't. The trap A persona invented in a meeting room. It confirms what the team already believed. Ask your team"When did each of us last watch a real client use what we built?" Example page · fictional team Field Operations / Teams / Dispatch: team charter 🎯 Customers & personas Martina, dispatcher Plan the day Heating and plumbing firm, 40 technicians, 3 dispatchers. **Job to be done:** "Have tomorrow planned before I go home." **Top pain:** rebuilds about 30% of auto-assignments by hand, because skill tags are wrong. One emergency job breaks the whole afternoon. Radek, technician Get there on time Works alone, 6-8 jobs a day, van stock only. **Job to be done:** "Know my first job tonight, and don't send me across town twice." Notify team internal customer Consumes our `eta.updated` events to tell end customers when the technician arrives. ✎ Source: 14 dispatcher interviews (May-Aug 2026) and 212 support tickets tagged _schedule_. [Research folder](#personas) Focus & client value5 of 18 ## Customer areas, KPIs & OKRs Few streams can measure their product's success in client value or satisfaction. They report what they shipped: releases, velocity, story points. The client feels none of it. This page fixes that in three layers. 1. **KPIs** per customer area. Always on, reviewed monthly. 2. **OKRs**. The quarter's bets, each moving one KPI. 3. **Guardrails**. What must not get worse while you push. How to write it - A KPI is a change in client behaviour or experience ([Seiden](https://www.producttalk.org/outcomes-vs-outputs/)). Pick from HEART: happiness, engagement, adoption, retention, task success. Use only the ones that fit ([Rodden et al., 2010](https://research.google.com/pubs/archive/36299.pdf)). - Measure satisfaction at the moment of the task. An effort score on the flow tells you more than a yearly NPS ([Dixon et al., 2010](https://hbr.org/2010/07/stop-trying-to-delight-your-customers); NPS's superiority didn't replicate, [Keiningham et al., 2007](https://journals.sagepub.com/doi/10.1509/jmkg.71.3.039)). - Objective: qualitative, from the client's side. Key result: a number, baseline → target. One or two objectives per team per quarter, three KRs each at most. - An aspirational KR that lands at 60-70% is a good quarter. Mark the committed ones apart ([Google re:Work](https://rework.withgoogle.com/intl/en/guides/set-goals-with-okrs)). - DORA metrics go on the team health page. They measure delivery, not client value ([dora.dev](https://dora.dev/guides/dora-metrics/)). The trap "KR: ship skill tags v2." A task with a percentage sign next to it is still a task. Ask your team"Which number would the client's operations manager check to know we did a good job?" Example page · fictional team Field Operations / Teams / Dispatch: team charter ⛳ Customer areas, KPIs & OKRs i KPIs live on the stream dashboard. We check them every planning and in the monthly KPI review, first Tuesday. ### KPIs | Metric | Q3 2026 | Mar 2028 | Source | | --- | --- | --- | --- | | Plan the day | | Median schedule build time | 22 min | 10 min | board events | | Jobs auto-scheduled, no manual edit | 52% | 75% | sched-svc log | | Dispatcher effort score (1 easy, 5 hard) | 3.2 | 2.0 | in-app survey | | Get there on time | | On-time arrival (±15 min) | 81% | 92% | app check-in | | Drive time per job | 29 min | 24 min | route-opt | Guardrails: board p95 load under 2 s · support tickets per 100 accounts ≤ 4. ### OKRs · Q4 2026 Aspirational O1 · Dispatchers stop rebuilding the schedule by hand. - KR1 · Jobs auto-scheduled with no manual edit **52% → 70%** - KR2 · Median schedule build time **22 → 15 min** - KR3 · Dispatcher effort score **3.2 → 2.7** Aspirational O2 · Technicians arrive inside the promised window. - KR1 · On-time arrival **81% → 86%** - KR2 · Late-arrival complaints per 1,000 jobs **9 → 5** Committed Board p95 load stays under 2 s all quarter. Scoring: 0.7 on an aspirational KR is a good quarter. Not every team is a product team. Three more, same stream, same rules Platform team Delivery Platform · its clients are the other teams KPIs - Voluntary adoption of the golden path, % of services - Developer satisfaction with the platform, quarterly survey - Time to first production deploy of a new service - CI success rate and duration OKR Shipping a new service is boringly easy. - Time to first prod deploy 5 days → 1 day - Golden-path adoption 40% → 70% - Platform satisfaction 3.1 → 4.0 of 5 Enabling team Reliability Coaching · wins when it's no longer needed KPIs - Capability of supported teams before and after, e.g. change fail rate - Weeks until a supported team is self-sufficient - Supported teams' satisfaction after the engagement - Practice still in use 90 days after exit OKR Three stream teams own their observability without us. - Teams with SLOs and alerts 0/3 → 3/3 - Each engagement closed in ≤ 8 weeks - Practice retained after 90 days: 3 of 3 Internal tools team Back-office Tools · its clients are colleagues KPIs - Task success and time-on-task in core staff workflows - Staff effort score, quarterly pulse - Manual corrections per 100 transactions - Availability in business hours OKR Support staff process a refund in one pass. - Refund handling time 11 → 4 min - Refund correction rate 8% → 2% - Staff effort score 3.8 → 2.5 Team types from [Team Topologies](https://teamtopologies.com/key-concepts). Platform metrics after [SPACE (Forsgren et al., 2021)](https://queue.acm.org/detail.cfm?id=3454124) and the [CNCF platform maturity model](https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/). All numbers are examples. Focus & client value6 of 18 ## Why my work exists Every person in the stream should be able to explain why their work exists and what the client gets from it. This page makes the line from a ticket to the client visible. How to write it - Every epic links to a KR, every KR to a customer area. No link, no epic. - Give people the one-sentence test and one worked example from your own backlog. - In refinement, a ticket that can't be traced gets one question: keep, park or drop? - New joiners pass the test in their first week, for the thing they're working on. The trap The links exist in Jira and nobody reads them. Test it by asking people. If an engineer can't answer, the lead has work to do. Ask your teamRound the table in retro: "Why does what you did this week matter to Martina?" Example page · fictional team Field Operations / Teams / Dispatch: team charter 🧭 Why my work exists ### One ticket, all the way up 1. TicketDSP-1482 Use technician skill tags in auto-assign 2. EpicDSP-1400 Skill-aware assignment 3. Key resultO1 KR1 · Jobs auto-scheduled with no manual edit 52% → 70% 4. Customer areaPlan the day 5. North StarPerfect jobs 46% → 70% 6. For the clientMartina stops fixing wrong assignments at 7 in the morning. ### The one-sentence test ✓ "I'm working on  what  so that  who  can  do what . We'll see it in  which metric ." > "I'm working on skill tags in auto-assign so that Martina stops reassigning a third of her jobs by hand. We'll see it in jobs auto-scheduled with no manual edit." Lukas, backend engineer Focus & client value7 of 18 ## Roadmap & stop-doing list Now, next, later, and every item points to a KR. Next to it sits the list of what you stopped doing to make room, because you can't add fuel to a boiler that's about to burst. How to write it - Link the live roadmap tool. A pasted copy is stale by Friday. - Each item names the KR or customer area it moves. - Show discovery work too. It's work, and it's how the next items earn their place. - Dates on "Now" only. - Keep a stop-doing list: fewer parallel priorities, no initiative without a business outcome, fewer priority changes inside the quarter. The trap Fourteen features with dates and no reason. The team delivers all of them and no metric moves. Ask your team"If we cut the bottom third of this list, which KR gets hurt?" Example page · fictional team Field Operations / Teams / Dispatch: team charter 🛣️ Roadmap Now · Oct-Dec 2026 DSP-1400 Skill-aware assignment O1 KR1 DSP-1420 Traffic-aware ETAs O2 KR1 Discovery: emergency job insert, 5 dispatcher interviews Plan the day Next · Q1 2027 Templates for recurring jobs Plan the day Late-risk alerts to the dispatcher Get there on time Later Multi-depot routing Get there on time Live view: [Jira plan "Dispatch 2026-27"](#roadmap) · WIP limit: 2 epics in progress. ### What we stopped to make room ! - ~Custom colour themes for the board~: no customer outcome, parked. - ~Weekly status report~: replaced by the live dashboard. - ~Three epics in parallel~: now two. - ~Manual deploys to staging~: automated in Q3. Efficiency & innovation8 of 18 ## Team interactions Who you depend on, who depends on you, and how you work together. Team Topologies names three modes: collaboration, X-as-a-Service and facilitation ([source](https://teamtopologies.com/key-concepts)). How to write it - One row per team: mode, what for, until when. - Collaboration and facilitation get an end date and exit criteria. Both are temporary by design ([source](https://teamtopologies.com/news-blogs-newsletters/2025/2/21/team-topologies-interaction-modes-breaking-through-common-misconceptions)). - What you provide as a service gets a written promise: what, how fast, how reliable. - Include the handover to the people who run production. - Draw it. A diagram gets read, a table gets skimmed. The trap "We work closely with everyone." The Team Topologies authors call it an interaction nobody defined, and it's where waiting time hides. Ask your team"Which team did we wait on longest last quarter, and did we ever agree how we work with them?" Example page · fictional team Field Operations / Teams / Dispatch: team charter 🔀 Team interactions | Team | Mode | What for | Until | | --- | --- | --- | --- | | Field App | Collaboration | Live job reassignment across board and mobile | 15 Dec 2026 | | Notify | We provide | `eta.updated` events, 99.9% delivered within 60 s | ongoing | | Delivery Platform | We consume | CI/CD, maps gateway, observability | ongoing | | Reliability Coaching | Facilitation | SLOs and alerts for sched-svc | 30 Nov 2026 | | Operations | Handover | Runbooks, release notes, first-line support | ongoing | Exit criteria for Field App collaboration: reassignment works end to end for 3 pilot customers, Field App owns the mobile side alone. Sustainable performance9 of 18 ## The crew Names, faces, roles, time zones and how much of each person the team really has. How to write it - Time zone and core hours per person. - Allocation, honestly. A 50% designer shared with another team is a different plan than a 100% one. - Name the embedded PM and designer. - Link each person's "how to work with me" and the career framework, so everyone knows what the next level asks of them. - Keep the team small: the minimum number of people and no more ([Haas & Mortensen](https://hbr.org/2016/06/the-secrets-of-great-teamwork)). The trap "See the org chart." Then nobody knows Sara is here only on Mondays and Tuesdays. Ask your team"Who on this list is here less than 100%, and does everyone know it?" Example page · fictional team Field Operations / Teams / Dispatch: team charter 👥 The crew | Who | Role · focus | TZ | Time | | --- | --- | --- | --- | | JHJana Horáková | Engineering manager · people, delivery, charter owner | CET | 100% | | TRTomás Reyes | Tech lead · architecture, sched-svc | CET | 100% | | PNPriya Nair | Product manager · discovery, KPIs, roadmap | GMT | 100% | | LBLukas Berger | Backend · sched-svc | CET | 100% | | MCMei Chen | Backend · route-opt | CET | 100% | | OMOndřej Malý | Frontend · dispatch-board | CET | 100% | | SLSara Lindqvist | Product designer · board UX | CET | 50% | Sara is with Notify Wednesday to Friday. Each name links to a "how to work with me" page. Career levels and expectations: [Engineering career framework](#crew). Sustainable performance10 of 18 ## Roles & responsibilities One entry per role, each with its top 3-5 responsibilities. The point is to find the work nobody owns ([Atlassian](https://www.atlassian.com/team-playbook/plays/roles-and-responsibilities)). How to write it - Describe the role, then who holds it. People change, roles stay. - 3-5 responsibilities per role, written as things you can check. - Finish with the orphans: the recurring work that belongs to no role until you assign it. - Review every 3-6 months, or when someone joins or leaves. The trap "Isn't all of this the PM's job?" No. Making sure the mission, the goals and the roadmap are understood by everyone is the team lead's job. Ask your team"What happens in this team every month that nobody would list as their job?" Example page · fictional team Field Operations / Teams / Dispatch: team charter 🤝 Roles & responsibilities Engineering manager @Jana Horáková - People growth, 1:1s, hiring - Delivery predictability - Owns this charter and its review - Protects the capacity split Tech lead @Tomás Reyes - Approver on architecture and ADRs - Code review within 1 working day - Tech-debt register Product manager @Priya Nair - Discovery with clients - KPI dashboard and OKR draft - Roadmap order Engineer everyone else - Part of solution design from the start - Owns quality up to Done - Passes the one-sentence test ### Orphans, now assigned
Dependency upgradesShield engineer of the week
Flaky test triageShield engineer of the week
Release notes for OperationsAuthor of the epic
Dashboard upkeep@Priya Nair
Efficiency & innovation11 of 18 ## Communication & rituals Where to reach you, how fast you answer, and which meetings the team runs and why. How to write it - One entry point for requests, with the response time next to it. - A team-internal channel apart from the one outsiders use. - How to raise an incident, in one line. - A table of rituals: purpose, cadence, length, who. A meeting without a purpose line is a candidate for deletion. - Put the monthly KPI review and the quarterly review in the calendar on day one. The trap Direct messages as the intake queue. Work arrives invisible, and the loudest person gets served first. Ask your team"Where did the last three requests from outside the team arrive?" Example page · fictional team Field Operations / Teams / Dispatch: team charter 📲 Communication & rituals
#dispatch-helpRequests and questions. Answered within 4 working hours.
#dispatch-teamInternal. Decisions get written here.
IncidentPage the on-call engineer. Don't DM anyone.
### Rituals | What | When | Why | | --- | --- | --- | | Daily sync | 09:30, 15 min | Blockers, not status | | Planning | Every 2nd Monday, 60 min | Pick work that moves a KR | | Refinement | Wednesday, 45 min | Trace each ticket to a KR | | Demo | Every 2nd Friday | Two client dispatchers join | | Retro | Every 2nd Friday | One change, owner, date | | KPI review | 1st Tuesday, 45 min | What moved and why | | Customer-area review | Quarterly | Present to the stream | Sustainable performance12 of 18 ## Working agreements A short list of behaviours the team agrees on and can check. A few things you always do, a few you never do ([Haas & Mortensen](https://hbr.org/2016/06/the-secrets-of-great-teamwork)). How to write it - Under ten lines. Each one checkable by an outsider. - Cover hours, reviews, meetings, focus time, priority changes, overtime and feedback. - Aim for a compromise everyone can live with ([Atlassian](https://www.atlassian.com/team-playbook/plays/rules-of-engagement)). - Overtime happens. Write down that it's rare and always compensated. An overloaded person isn't a high performer for long. - When an agreement can't be kept, change it in the retro. Don't let it rot. The trap "We respect each other." Nobody can check it, so nobody keeps it. Ask your team"What annoyed you most last month that a rule could have prevented?" Example page · fictional team Field Operations / Teams / Dispatch: team charter 📜 Working agreements 1. Pull requests get a review within 1 working day. 2. Core hours 10:00-15:00 CET. No meetings on Wednesday afternoon. 3. At most 2 epics in progress. 4. Priorities change inside the quarter only through the PM and EM, with the reason written in #dispatch-team. 5. Overtime is agreed in advance and paid back within the month, as time off or money. 6. Anyone can post an improvement idea to the Ideas board. We go through it every retro. 7. Critical feedback goes in private first. Praise goes in public. 8. An agreement we can't keep gets changed in the next retro. Last changed 12 Sep 2026: #3 went from 3 epics to 2. Quality13 of 18 ## Decisions: DACI + ADR log Who decides what, and where it gets written down. DACI names a Driver, one Approver, Contributors and the Informed ([Atlassian](https://www.atlassian.com/team-playbook/plays/daci)). Hard-to-reverse technical decisions become ADRs ([Nygard](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions)). How to write it - Map decision types to roles: architecture, priority change, release, hiring. - Exactly one Approver per type. - ADRs are numbered, live in the repo and are one or two pages. A reversed one is marked superseded, never deleted. - Write the deadlock path: who breaks the tie, and within how many days. The trap Decisions made in a Slack thread and lost within a week. Then the team makes the same decision again in March. Ask your team"Which decision did we make twice this year?" Example page · fictional team Field Operations / Teams / Dispatch: team charter ⚖️ Decisions | Decision | Driver | Approver | Informed | | --- | --- | --- | --- | | Architecture change | Proposer | Tech lead | Stream, Platform | | Priority change in quarter | PM | EM | #dispatch-team | | Release go / no-go | Shield engineer | Tech lead | Operations | | Hiring | EM | Head of Field Ops | Team | ### ADR log - ADR-0014 Use OR-Tools for route optimisation Accepted - ADR-0013 Split sched-svc and route-opt Accepted - ADR-0009 Nightly batch scheduling Superseded by 0013 Deadlock: the Head of Field Operations decides within 2 working days. Quality14 of 18 ## Definition of Done Done means done, not deployed to a test environment. The solution works, stays stable, is easy to run and to change, adds no needless debt, and brings the value you expected. Quality isn't a luxury for when there's time. Done = Delivered + Stable + Maintainable + Operable + Valuable How to write it - One short checklist under each of the five words. - Automate whatever you can check automatically. The rest goes in the PR template. - "Valuable" needs a check too: the metric event fires, and someone looks at the number two weeks later. - Write operations docs together with the people who run production, so they don't need to call you. - Inspect the list in retro and tighten it as the team matures ([Scrum Guide](https://scrumguides.org/scrum-guide.html)). The trap "Dev complete." Then the last 20% shows up in the next sprint as bugs, and the one after as debt. Ask your team"What broke in production last quarter that this list should have caught?" Example page · fictional team Field Operations / Teams / Dispatch: team charter ✅ Definition of Done Delivered - Merged and in production, behind a flag or released - Build and deploy fully automated Stable - Unit tests for new logic - Approved by the component owner plus one more reviewer - No new alert firing 48 h after release Maintainable - Docs updated in the same PR - New tech debt written as a ticket, planned by the end of the quarter at the latest Operable - Runbook written with Operations - Dashboard and alerts exist - Operations can run it without calling us Valuable - The KPI event fires in production - After 2 weeks, the result is posted in #dispatch-team ! Deployed to staging is not Done. It's "Delivered" minus four. Efficiency & innovation15 of 18 ## Capacity & tech debt An agreed split of the team's capacity, a visible debt register, and the order in which you make things efficient: simplify, standardise, automate, and only then add people. How to write it - Agree the capacity split with your manager as a percentage, then protect it in planning. - Each debt item has a ticket, an owner and a planned quarter. - Efficiency is the amount of lasting value you create with the capacity you have, not the number of things shipped. - Show where AI helps across the lifecycle: research, analysis, code, tests, docs. - Improvement ideas come from anyone. Review them on a fixed cadence, or they stop coming. The trap "We'll clean up after the release." There's always another release. Debt without a budget is a promise nobody keeps. Ask your team"Which manual step did we do more than ten times last month?" Example page · fictional team Field Operations / Teams / Dispatch: team charter ⚙️ Capacity & tech debt ### Capacity split · agreed with Head of Field Ops Customer areas 70%Tech health 20%10% The 10% is improvements and AI experiments. ### Tech-debt register
DEBT-31One logging format across sched-svc and route-optQ4 2026
DEBT-28Static analysis as a pipeline gateQ4 2026
DEBT-25Move secrets to the secret managerQ1 2027
DEBT-22Link every commit to its Jira ticketDone
### Simplify → standardise → automate → add capacity Release notes for Operations: one template in Q3, generated from Jira in Q4. We hired nobody for it. ### Where we use AI interview synthesis code assistant test generation release-note drafts Quality16 of 18 ## Run & on-call Who runs production, who builds new things, and how interruptions reach the team without eating the whole sprint. How to write it - Split run from build in writing: who takes first line, who takes second, in which hours. - Pages for P1, tickets for everything else ([Google SRE](https://sre.google/workbook/on-call/)). - One person a week absorbs interruptions and has no sprint commitments. A person should know if they're on project work or on interrupts ([source](https://sre.google/sre-book/dealing-with-interrupts/)). - Google caps on-call at 25% of an engineer's time and asks for at least 8 people in a rotation at one site ([source](https://sre.google/sre-book/being-on-call/)). Five engineers is too few for nights, so pair with a sibling team. - Handoff note at every rotation change. The trap Everyone gets interrupted a little. Then nobody finishes anything, and it looks like a planning problem. Ask your team"How many hours last sprint went to work nobody planned?" Example page · fictional team Field Operations / Teams / Dispatch: team charter 🚨 Run & on-call | | Who | When | | --- | --- | --- | | First line | Operations | 24/7 | | Second line | Dispatch, Shield engineer | Mon-Fri 08:00-18:00 | | Second line, nights | Dispatch + Field App rotation, 9 engineers | 18:00-08:00, weekends | ### Shield week - Handles pages, #dispatch-help, dependency upgrades, flaky tests. - No sprint commitments that week. - Handoff note every Monday at 09:15.
P1Dispatchers can't publish a schedule, or ETAs are down. Page. Response within 15 min.
P2Degraded, workaround exists. Ticket, next working day.
Sustainable performance17 of 18 ## Team health KPIs say what the client gets. Health metrics say how the team works while getting it there. Ten of them, reviewed with the KPIs. How to write it - Same ten metrics in every team of the stream, so the stream can compare trends. - Read the trend. One bad sprint is noise. - Keep them out of OKRs. The moment a health metric becomes a target, people learn to game it ([Kohavi et al.](https://assets.cambridge.org/97811087/24265/frontmatter/9781108724265_frontmatter.pdf) on guardrails). - Sprint completion near 100% every sprint means the team plans too little. - Put sustainability next to delivery on purpose. Speed bought with overtime shows up later as attrition. The trap Reporting velocity to management. It's a planning tool for the team, and the number inflates as soon as someone upstairs watches it. Ask your team"Which of these ten would you hide from your manager, and why?" Example page · fictional team Field Operations / Teams / Dispatch: team charter 🩺 Team health · Q3 2026 | Metric | How we measure | Q3 | Trend | | --- | --- | --- | --- | | Focus | Epics in progress per sprint | 2.1 | ↓ from 3.4 | | Stability | % of quarter priorities unchanged | 83% | ↑ | | Roadmap contribution | % capacity on customer-area work | 68% | ≈ plan 70% | | Value | Customer outcomes defined for our work | 2 of 2 areas | ✓ | | Delivery | Sprint completion, planned vs delivered | 76% | ↑ | | Quality | Escaped defects · P1 incidents · availability | 3 · 1 · 99.93% | ≈ | | Cycle time | Median, start to production | 3.8 days | ↓ | | Epic dev weeks | Average weeks per finished epic | 5.5 | ↑ from 4.9 | | Tech health | Open debt items | 14 | ↓ from 19 | | Sustainability | Overtime h · engagement · leavers | 6 · 7.8 · 0 | ≈ | Green = moving the right way. Epic dev weeks grew because DSP-1400 was sliced too big; noted for refinement. Focus & client valueStream page · 18 of 18 ## Quarterly customer-area review After every quarter, the stream measures and presents how each customer area changed, through the metrics it tracks. The team is the unit that presents. The charter gets its review in the same week. How to write it - Fixed date, before quarterly planning. - Per area: metric, last quarter, this quarter, target. Then what moved it, and what didn't. - Say which bets were wrong. A hypothesis that failed is still a finding. - Close with charter changes: joiners, scope moves, broken agreements. Review the charter every three months at least, or after a pivot ([Atlassian](https://www.atlassian.com/software/confluence/templates/team-poster)). The trap A slide of shipped features. The review asks what changed for the client, and a feature list can't answer that. Ask your team"Which of our KRs moved, and do we know why?" Example page · fictional stream Field Operations / Quarterly reviews 📊 Q3 2026 customer-area review KVPresented 2 Oct 2026 · 4 teams · 60 min | Area · metric | Q2 | Q3 | Target | | | --- | --- | --- | --- | --- | | **North Star** · perfect jobs | 42% | 46% | 70% | On track | | Plan the day · build time | 34 min | 22 min | 10 min | On track | | Plan the day · auto-scheduled | 41% | 52% | 75% | On track | | Get there on time · on-time | 78% | 81% | 92% | At risk | | Fix it first time · FTF rate | 70% | 71% | 85% | Off track | | Keep informed · calls per 100 | 12 | 11 | 3 | At risk | ### Dispatch - **What moved it:** skill tags piloted with 3 customers took auto-scheduled jobs from 41% to 52%. - **What didn't:** ETAs on rural routes stayed as bad as before. Our traffic hypothesis was wrong; the problem is missing addresses. - **Next quarter:** O1 and O2, see [KPIs & OKRs](#kpis). - **Charter changes:** Mei took over route-opt; agreement #3 is now 2 epics. ## How to run the charter workshop Don’t write the charter alone and present it. Draft the skeleton, then let the team fill it in and argue about it. In practice two sessions of 90 minutes work better than one long day. **Before the first session.** The stream lead publishes the North Star with its customer areas. You draft the mission, the scope and the escalation path. The PM brings today’s baseline for every KPI the team will own. If there’s no baseline, that’s the first finding. **Session A, 90 minutes.** Mission and scope (30 minutes), customer areas and KPIs (30), the first OKR draft (20), wrap-up and owners (10). If OKRs are new to the team, read [how to make your teams beat OKRs](https://www.marian.coach/blog/how-to-make-your-teams-beat-okrs/) first, and the OKR-to-sprint translation layer for how key results turn into weekly work. **Session B, 90 minutes.** Roles and decision rights (30), working agreements and channels (30), Definition of Done and run (20), when and how you’ll review the charter (10). Then one week of comments directly on the Confluence pages. Where people disagree, look for a compromise the team can keep rather than full consensus. Bring the result to the month-one review with your manager: it’s the most concrete proof you can show that you’ve started owning the team’s focus. If you’d like a second pair of eyes on the draft before that review, bring it to a [mentoring session](https://www.marian.coach/engineering-manager-mentor/). ## Three lessons from the talk **Keep it focused.** Don’t do it alone, and listen more than you write. Be neither Mr Nice Guy, who writes down whatever the loudest person says, nor the unhelpful jerk, who arrives with the finished charter and asks for comments. Take your time to create the right ammunition for your team when you start out, or don’t expect to do a good job in your first 90 days. **Make it stick.** It’s your responsibility that the mission, the goals and the roadmap are understood by everyone. Refer to the charter in planning, in refinement and in 1:1s. A charter that’s opened only during the review is out of date within weeks. **It’s your job.** People ask me: “isn’t all of this the PM’s job?” No. The PM owns discovery and the order of the roadmap. The team lead owns whether the team knows why its work exists. ## What the research says A good charter that the team uses helps. One written once and filed away does very little. The best-known study is [Mathieu and Rapp (2009)](https://pubmed.ncbi.nlm.nih.gov/19186898/). Across 32 teams in a business simulation, the highest sustained performance came from teams that had both a high-quality charter and a strong performance strategy. A charter without a strategy behind it wasn’t enough. [Courtright and colleagues (2017)](https://psycnet.apa.org/record/2017-22541-001) found in 239 teams that charter quality raised performance through task cohesion, most of all in teams whose members were less conscientious. The counter-evidence matters too. In a study of 1,891 global virtual teams, [Johnson and colleagues (2022)](https://pure.psu.edu/en/publications/do-team-charters-help-team-based-projects-the-effects-of-team-cha/) found charters helped mostly in the forming stage and had no direct link to the quality of the final output. Every one of these studies used student teams, so treat them as a direction. Google’s Project Aristotle points the same way from another angle. It lists structure and clarity, meaning clear goals, roles and plans, among the five things that separate effective teams, with psychological safety first ([re:Work summary, hosted copy](https://www.michigan.gov/-/media/Project/Websites/mdhhs/Folder4/Folder10/Folder3/Folder110/Folder2/Folder210/Folder1/Folder310/Google-and-Psychological-Safety.pdf)). A charter is structure and clarity written down. Whether the team feels safe enough to say “this page is wrong” decides if it stays alive. So write the charter in week four, make the North Star and its customer areas measurable, review it every quarter with the numbers on the table, and change it when it stops being true. ## Frequently asked What should a software engineering team charter include?+ A software engineering team charter covers 18 pages in two layers. The stream owns a 12-18 month North Star with 3-5 measurable customer areas, and a quarterly review of them. The team owns its mission, scope, customers, KPIs and OKRs, roadmap, interactions, roles, working agreements, decisions, Definition of Done, capacity, on-call and health metrics. How long should a team charter be?+ The home page should fit on one screen: mission, the customer areas the team owns, and links. Each child page stays short enough to read in two minutes. There is no research-based length; a charter nobody reads is too long at any size. How often should a team charter be updated?+ Review it every quarter, in the same week as the customer-area review and before quarterly planning. Update it sooner when someone joins or leaves, when scope moves, after a pivot, or when the team can no longer keep one of its working agreements. What is the difference between KPIs and OKRs in a team charter?+ KPIs are always-on measures of what the client gets in each customer area, such as on-time arrival or task effort. OKRs are the bets for one quarter, and each key result moves one KPI from a baseline to a target. Team health metrics like cycle time or sprint completion describe how the team works and stay out of OKRs. Do team charters improve team performance?+ A good team charter improves performance when the team keeps using it. Mathieu and Rapp (2009) found the best sustained performance in teams with both a high-quality charter and a strong performance strategy. A large 2022 study of student teams found charters helped mainly in the forming stage. Writing it once and filing it away does little. 1:1 mentoring ## Ready to move this from advice to action? 1:1 mentoring for engineering leaders. 317 mentees since 2019. Pay-as-you-go or a 6-session pack. First intro is free. [Book a free 30-min intro →](https://www.marian.coach/mentoring/) ## Read next - [![Marian Kamenistak presenting at the Engineering Leaders Conference, client logo wall projected behind him.](https://www.marian.coach/_astro/elc-conference-83.C-jfqKbZ_bLDO1.webp) ### AI Engineering Manager: The 2027 Career Fork The engineering manager job is splitting in two by 2027: AI engineering manager, or staff AI engineer. The dead zone is the shape most EMs hold today. 4 September 2026 · By Marian Read → ](https://www.marian.coach/blog/ai-engineering-manager-2027/) - [![Should You Take the VP of Engineering Job?](https://www.marian.coach/images/blog/engineering-director-to-vp-engineering/infographic.webp) ### Should You Take the VP of Engineering Job? 44 engineering directors have brought me this decision. What the VP seat costs, the five things to negotiate before you say yes, and who should decline it. 3 September 2026 · By Marian Read → ](https://www.marian.coach/blog/engineering-director-to-vp-engineering/) - [![Marian Kamenistak in a 1:1 mentoring session.](https://www.marian.coach/_astro/mentoring-06.CFmbsSxo_Z28Cr7r.webp) ### Your CTO Is Happy. You Still Feel Like a Fraud. Most advice says the imposter feeling is your brain lying to you. Sometimes it is an accurate reading of a real gap, and the gap is not your ability. 25 August 2026 · By Marian Read → ](https://www.marian.coach/blog/imposter-syndrome-engineering-manager/) ### New posts, straight to your inbox. Your emailSubscribe You're on it. Nothing hits your inbox today. First send goes out once the list is live, and you're already on it. [Connect on LinkedIn →](https://www.linkedin.com/in/mariankamenistak/)[See the free tools →](https://www.marian.coach/ai-coaching-tools/) ## Structured data ```json {"@context":"https://schema.org","@type":"ProfessionalService","name":"Marian Kamenistak | Engineering Leadership Mentoring","url":"https://www.marian.coach/blog/team-charter-guide/","image":"https://www.marian.coach/images/blog/team-charter-guide/infographic.webp","description":"How to write a team charter for a software engineering team: 18 Confluence pages, from North Star and customer-area KPIs to Done, each with a worked example.","serviceType":["Engineering leadership mentoring","Engineering manager coaching","CTO coaching","Fractional CTO","Leadership development for software engineers"],"hasOfferCatalog":{"@type":"OfferCatalog","name":"Engineering leadership mentoring and advisory","itemListElement":[{"@type":"Offer","itemOffered":{"@type":"Service","name":"1:1 engineering leadership mentoring","description":"One-to-one mentoring for engineering leaders from Staff Engineer to CTO. 60-minute sessions, weekly or bi-weekly.","url":"https://www.marian.coach/pricing/"}},{"@type":"Offer","itemOffered":{"@type":"Service","name":"Engineering manager coaching","description":"Coaching for first-time and experienced engineering managers: delegation, performance, hiring, team scaling.","url":"https://www.marian.coach/engineering-manager-mentor/"}},{"@type":"Offer","itemOffered":{"@type":"Service","name":"CTO and VP Engineering mentoring","description":"Mentoring for CTOs, VPs of Engineering and Heads of Engineering running 30-200 person organisations.","url":"https://www.marian.coach/cto-mentor/"}},{"@type":"Offer","itemOffered":{"@type":"Service","name":"Mentor in Residence","description":"A dedicated onsite mentor for your engineering organisation, booked by the quarter.","url":"https://www.marian.coach/mentor-in-residence/"}},{"@type":"Offer","itemOffered":{"@type":"Service","name":"Fractional CTO","description":"Part-time CTO engagements for companies without a full-time technology leader.","url":"https://www.marian.coach/fractional-cto/"}}]},"telephone":"+420 736 519 879","email":"marian@marian.coach","sameAs":["https://www.linkedin.com/in/mariankamenistak/","https://www.youtube.com/@engineeringleaders","https://github.com/marian-kamenistak","https://www.engineeringleaders.io/","https://www.elc-conference.io/","https://www.marianslist.com/","https://www.mentoringhub.io/"],"address":{"@type":"PostalAddress","streetAddress":"Varšavská 715/36, Vinohrady","addressLocality":"Praha 2","postalCode":"12000","addressCountry":"CZ"},"geo":{"@type":"GeoCoordinates","latitude":50.0734418,"longitude":14.4385757},"openingHoursSpecification":[{"@type":"OpeningHoursSpecification","dayOfWeek":["Monday","Tuesday","Wednesday","Thursday","Friday"],"opens":"09:00","closes":"17:00"}],"priceRange":"296–395 EUR","areaServed":[{"@type":"Place","name":"Europe"},{"@type":"Country","name":"Czechia"},{"@type":"Country","name":"Slovakia"},{"@type":"Country","name":"Poland"},{"@type":"Place","name":"North America"}]} {"@context":"https://schema.org","@type":"Person","@id":"https://www.marian.coach/#person","name":"Marian Kamenistak","url":"https://www.marian.coach/","image":"https://www.marian.coach/images/blog/team-charter-guide/infographic.webp","jobTitle":["Fractional CTO & Chief AI Officer for AI transformation","Founder, Engineering Leaders Community","Engineering Leadership Mentor","Engineering Manager Coach","CTO Coach","Keynote Speaker"],"hasOccupation":{"@type":"Occupation","name":"Engineering Leadership Mentor"},"worksFor":{"@type":"Organization","name":"Engineering Leaders Community","url":"https://www.engineeringleaders.io/"},"alumniOf":[{"@type":"Organization","name":"Mews"},{"@type":"Organization","name":"Manta (acquired by IBM)"},{"@type":"Organization","name":"Databricks"}],"knowsLanguage":["English","Czech","Slovak"],"knowsAbout":["Engineering leadership","Engineering management","Scaling engineering teams","CTO mentoring","Engineering org design","VP of Engineering role","Engineering director role","CTPO role","Team lead development","Staff engineer career path","Fractional CTO engagements","AI-assisted engineering leadership","Conference keynotes on engineering leadership","Panel moderation","Podcast guest — engineering leadership"],"homeLocation":{"@type":"Place","name":"Prague, Czechia"},"sameAs":["https://www.linkedin.com/in/mariankamenistak/","https://www.youtube.com/@engineeringleaders","https://github.com/marian-kamenistak","https://www.engineeringleaders.io/","https://www.elc-conference.io/","https://www.marianslist.com/","https://www.mentoringhub.io/","https://www.crunchbase.com/person/marian-kamenistak","https://www.wikidata.org/wiki/Q140488098","https://developers.mews.com/author/marian/","https://startupdisrupt.com/speakers/marian-kamenistak/","https://theorg.com/org/engineering-leaders-community/org-chart/marian-kamenistak"]} {"@context":"https://schema.org","@type":"WebPage","url":"https://www.marian.coach/blog/team-charter-guide/","name":"Team Charter Guide for Software Engineering Teams","inLanguage":"en","dateModified":"2026-09-22T00:00:00.000Z"} {"@context":"https://schema.org","@type":"FAQPage","inLanguage":"en","mainEntity":[{"@type":"Question","name":"What should a software engineering team charter include?","acceptedAnswer":{"@type":"Answer","text":"A software engineering team charter covers 18 pages in two layers. The stream owns a 12-18 month North Star with 3-5 measurable customer areas, and a quarterly review of them. The team owns its mission, scope, customers, KPIs and OKRs, roadmap, interactions, roles, working agreements, decisions, Definition of Done, capacity, on-call and health metrics."}},{"@type":"Question","name":"How long should a team charter be?","acceptedAnswer":{"@type":"Answer","text":"The home page should fit on one screen: mission, the customer areas the team owns, and links. Each child page stays short enough to read in two minutes. There is no research-based length; a charter nobody reads is too long at any size."}},{"@type":"Question","name":"How often should a team charter be updated?","acceptedAnswer":{"@type":"Answer","text":"Review it every quarter, in the same week as the customer-area review and before quarterly planning. Update it sooner when someone joins or leaves, when scope moves, after a pivot, or when the team can no longer keep one of its working agreements."}},{"@type":"Question","name":"What is the difference between KPIs and OKRs in a team charter?","acceptedAnswer":{"@type":"Answer","text":"KPIs are always-on measures of what the client gets in each customer area, such as on-time arrival or task effort. OKRs are the bets for one quarter, and each key result moves one KPI from a baseline to a target. Team health metrics like cycle time or sprint completion describe how the team works and stay out of OKRs."}},{"@type":"Question","name":"Do team charters improve team performance?","acceptedAnswer":{"@type":"Answer","text":"A good team charter improves performance when the team keeps using it. Mathieu and Rapp (2009) found the best sustained performance in teams with both a high-quality charter and a strong performance strategy. A large 2022 study of student teams found charters helped mainly in the forming stage. Writing it once and filing it away does little."}}]} {"@context":"https://schema.org","@type":"BlogPosting","headline":"Team Charter Guide for Software Engineering Teams","description":"How to write a team charter for a software engineering team: 18 Confluence pages, from North Star and customer-area KPIs to Done, each with a worked example.","inLanguage":"en","articleSection":"engineering-management","datePublished":"2026-09-22T00:00:00.000Z","dateModified":"2026-09-22T00:00:00.000Z","author":{"@id":"https://www.marian.coach/#person"},"publisher":{"@type":"Organization","name":"Marian Kamenistak","url":"https://www.marian.coach/","logo":{"@type":"ImageObject","url":"https://www.marian.coach/favicon-192x192.webp","width":192,"height":192}},"image":{"@type":"ImageObject","url":"https://www.marian.coach/images/blog/team-charter-guide/infographic.webp"},"mainEntityOfPage":{"@type":"WebPage","@id":"https://www.marian.coach/blog/team-charter-guide/"},"keywords":"engineering-management, team-lead, leadership, okrs","wordCount":1316,"timeRequired":"PT6M","isAccessibleForFree":true} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://www.marian.coach/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://www.marian.coach/blog/"},{"@type":"ListItem","position":3,"name":"Team Charter Guide for Software Engineering Teams","item":"https://www.marian.coach/blog/team-charter-guide/"}]} ```