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 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.
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 (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.
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).
- 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?"
⭐ Field Operations North Star 2027-28
KVOwned by @Karel Vondra · Last updated 15 Sep 2026
Horizon: October 2026 to March 2028. Reviewed every quarter in the customer-area 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, refreshed daily, open to everyone in the stream.
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?"
🚚 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
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).
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). The scope page should send people to the right team.
Ask your team"What were we asked to do last month that nobody owns?"
🔭 Scope & ownership
Services we run (we get paged)
- sched-svc: assigns jobs to technicians by skill, location and free capacity.
- route-opt: builds each technician's daily route and the ETAs.
- dispatch-board: 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 tagsAssign jobs
Auto-assignManual reassignEmergency insertRoute
Build routesCalculate ETAsMaps & geocodingRun the live day
Drag & drop changesJob status syncTechnician appClose the day
End-of-day reportCustomer SMSInvoicingwe own shared, named partner not ours
We don't own
| Technician mobile app | Field App |
| SMS & email to end customers | Notify |
| Maps provider, CI/CD, observability | Delivery Platform |
| Invoicing | Billing stream |
Surface areas: Dispatcher board (/board), Settings → Working hours, public API /v2/schedule.
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).
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?"
🎯 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
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.
- KPIs per customer area. Always on, reviewed monthly.
- OKRs. The quarter's bets, each moving one KPI.
- Guardrails. What must not get worse while you push.
How to write it
- A KPI is a change in client behaviour or experience (Seiden). Pick from HEART: happiness, engagement, adoption, retention, task success. Use only the ones that fit (Rodden et al., 2010).
- 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; NPS's superiority didn't replicate, Keiningham et al., 2007).
- 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).
- DORA metrics go on the team health page. They measure delivery, not client value (dora.dev).
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?"
⛳ Customer areas, KPIs & OKRs
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. Platform metrics after SPACE (Forsgren et al., 2021) and the CNCF platform maturity model. All numbers are examples.
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?"
🧭 Why my work exists
One ticket, all the way up
- TicketDSP-1482 Use technician skill tags in auto-assign
- EpicDSP-1400 Skill-aware assignment
- Key resultO1 KR1 · Jobs auto-scheduled with no manual edit 52% → 70%
- Customer areaPlan the day
- North StarPerfect jobs 46% → 70%
- 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
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?"
🛣️ 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" · 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.
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).
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).
- 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?"
🔀 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.
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).
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?"
👥 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.
Roles & responsibilities
One entry per role, each with its top 3-5 responsibilities. The point is to find the work nobody owns (Atlassian).
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?"
🤝 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 upgrades | Shield engineer of the week |
| Flaky test triage | Shield engineer of the week |
| Release notes for Operations | Author of the epic |
| Dashboard upkeep | @Priya Nair |
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?"
📲 Communication & rituals
| #dispatch-help | Requests and questions. Answered within 4 working hours. |
| #dispatch-team | Internal. Decisions get written here. |
| Incident | Page 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 |
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).
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).
- 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?"
📜 Working agreements
- Pull requests get a review within 1 working day.
- Core hours 10:00-15:00 CET. No meetings on Wednesday afternoon.
- At most 2 epics in progress.
- Priorities change inside the quarter only through the PM and EM, with the reason written in #dispatch-team.
- Overtime is agreed in advance and paid back within the month, as time off or money.
- Anyone can post an improvement idea to the Ideas board. We go through it every retro.
- Critical feedback goes in private first. Praise goes in public.
- An agreement we can't keep gets changed in the next retro.
Last changed 12 Sep 2026: #3 went from 3 epics to 2.
Decisions: DACI + ADR log
Who decides what, and where it gets written down. DACI names a Driver, one Approver, Contributors and the Informed (Atlassian). Hard-to-reverse technical decisions become ADRs (Nygard).
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?"
⚖️ 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.
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).
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?"
✅ 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.
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?"
⚙️ Capacity & tech debt
Capacity split · agreed with Head of Field Ops
The 10% is improvements and AI experiments.
Tech-debt register
| DEBT-31 | One logging format across sched-svc and route-opt | Q4 2026 |
| DEBT-28 | Static analysis as a pipeline gate | Q4 2026 |
| DEBT-25 | Move secrets to the secret manager | Q1 2027 |
| DEBT-22 | Link every commit to its Jira ticket | Done |
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
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).
- 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).
- 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). 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?"
🚨 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.
| P1 | Dispatchers can't publish a schedule, or ETAs are down. Page. Response within 15 min. |
| P2 | Degraded, workaround exists. Ticket, next working day. |
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. 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?"
🩺 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.
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).
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?"
📊 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.
- 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 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.
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). 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) 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) 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). 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.
