# Team charter Team structure is part of system design. The communication paths, decision rights, and ownership model become boundaries and coupling in the software. Write this together in about 45 minutes; revise it when it stops describing what the team does. Source: lesson 0048 · Run a Small Cross-Functional Initiative Team. --- ## Blank | Section | One-line guidance | | --- | --- | | Purpose | The outcome and the first cohort, in one sentence. Copy it from the frame; do not paraphrase it. | | People | Accountabilities, availability (what fraction of their week), missing expertise, and the consultation path for it. | | Decision rights | Who has the final call, and who must be asked first. Advice improves a decision; it does not create a consensus veto. | | Flow | WIP limit, swarm rule, review and pairing expectations, the trigger for declaring an item blocked. | | Sources of truth | One location for each fact. Duplicated status creates conflicting truth. | | Cadence | For each meeting: purpose, inputs, the artifact it changes, and the rule for canceling it. | | Escalation | Objective triggers, the DRI, the format of the ask, the recipient, and the response-needed-by date. | | Health | Sustainable pace, focus protection, learning and knowledge redundancy, one team experiment. | ### Decision-rights table | Accountability | Final call on | Must seek advice from | | --- | --- | --- | | `[role]` | `[decision area]` | `[roles]` | ### The meeting test Every recurring meeting needs an input people can inspect, a decision or learning purpose, a source of truth it changes, and a shorter asynchronous alternative for weeks with no decision. If the output is "everyone is informed", a written update is the deeper module. ### Team-system failures | Signal | System problem | Intervention | | --- | --- | --- | | Eight items, each "90%" | Utilization outranks finishing | Cap WIP; swarm one slice | | A design handoff every Monday | Discovery and delivery are detached | Shape examples together continuously | | The tech lead approves every pull request | Authority is a throughput bottleneck | Publish guardrails; distribute review | | The same blocker for three days | No owner or escalation trigger | Name a DRI, a fallback, and a deadline | --- ## Completed — returns resolution pilot **Purpose.** Move eligible domestic return resolution from 72 hours to under 4 hours and cut support contacts by a quarter, for signed-in customers with unopened items, with the pilot open by 30 September. **People (7).** Priya — product (outcome, scope, cohort). Marco — product design (experience, research, accessibility). Dana — tech lead (technical integrity, architecture, risk). Sam, Lea, Tomas, Ije — engineers, implementing within agreed boundaries: Lea owns the worker, Sam owns eligibility, Tomas owns the API and adapters, Ije owns telemetry and the pipeline. **Consulted, not embedded:** Anya (returns policy), Nils (support operations), Ola (privacy and security), Ravi (payments), Asha (platform). Missing expertise: nobody on the team had run the carrier integration before, which is why it got a spike and a pair rather than an estimate. ### Decision rights | Accountability | Final call on | Must seek advice from | | --- | --- | --- | | Priya (product) | Outcome definition, priority, cohort, scope trades | Marco, Dana, Nils, Anya, Risk | | Marco (design) | Experience coherence, interaction, research method, accessibility | Customers, Priya, engineers, the accessibility reviewer | | Dana (tech lead) | Technical integrity, architecture decisions, technical risk acceptance | The engineers, Priya, Marco, Ola, Nils | | Engineers | Implementation decisions inside agreed boundaries | Peers, and any owner affected by a contract change | | Anya (policy) | The content of eligibility rules | Priya, Risk, Nils | | Risk | **Stopping exposure on a fraud guardrail breach** — unilaterally | Nobody | | Dana **with** Nils | Advancing an exposure stage | Risk, Ola, Priya | | **Any on-call engineer** | **Stopping exposure**, acting first and explaining afterwards | Nobody | The asymmetry in the last two rows is the single most useful line in the charter. **Advancing exposure requires two named people to agree; stopping it requires one person to act.** A team that needs permission to stop will not stop in time. ### Flow - **WIP limit: two slices in progress.** With seven people that feels wrong for about a week and then stops feeling wrong. - **Swarm rule:** when a slice has not moved for half a day, the team moves to it rather than starting a third. - **Review:** any engineer may approve. Dana reviews only changes crossing a module boundary, a contract, or an authorization path — the three places where a mistake is expensive. Everything else is peer review, which is why the tech lead is not a throughput bottleneck, and which is also what makes driver D4's one-day policy release achievable. - **Blocked trigger:** no progress for one working day → a named DRI, a fallback, and a date. - **Ownership is collective.** Adapter and worker work rotates through pairs, so no module has exactly one person who understands it. ### Sources of truth | Fact | One location | | --- | --- | | Why and what counts | The initiative frame, versioned, with its history | | Scope and slices | The story map | | Current flow | The delivery board | | Decisions | The ADR log in the repository | | Uncertainty | The risk and dependency map | | Evidence | The pilot dashboard | Status is not restated in slides, tickets, chat, and a document. One place per fact, because duplicated status creates conflicting truth and someone eventually acts on the stale copy. ### Cadence | When | Purpose | Artifact it changes | Cancel when | | --- | --- | --- | --- | | Daily, 10 min | Flow, blockers, swarming — not status recitation | Board and dependency map | Never; it is ten minutes and it is where swarming is triggered | | Twice weekly, 30 min | Shape the next slice with examples, design, and engineering together | Story map and example cards | No slice is within two weeks of starting | | Weekly, 30 min | Review outcome evidence, risk, decisions, forecast | The weekly review page | Never during the pilot | | Weekly, 45 min | Demo integrated behavior to users or stakeholders | Feedback and decision log | Nothing integrated changed — say so in writing instead | | As needed, timeboxed | Resolve one design decision with the required advisers | An ADR, or an explicit "no decision yet, and why" | — | | Fortnightly, 45 min | Improve the team system and technical health | One owned experiment | Two consecutive sessions with no experiment worth running | ### Escalation triggers Escalation asks for a decision or a resource, states the options and their consequences, and names the date a response is needed. "Leadership awareness" is not an outcome. 1. An external dependency misses its needed-by date → that row's named recipient, same day. 2. A driver cannot be met inside the agreed scope → Priya's director, with two scope options and their consequences. 3. A decision crosses another team's ownership → that team's lead, with the contract change written out. 4. Forecast confidence drops below the agreed range → the weekly review, with the smallest scope trade already identified. 5. A guardrail breaches at any stage → immediate stop by whoever notices, then a conversation. ### Health Sustainable pace: no planned weekend work; the pilot date moves scope, not hours. Focus: two protected no-meeting mornings a week, protected by Priya including from Priya. Redundancy: every module has been touched by at least two people before the pilot gate — checked, not assumed. Current experiment: the twice-weekly shaping session replaced written handoffs from design, reviewed at the next fortnightly with one question — did an engineer have to ask what a screen meant? **Traces to:** the purpose line is the outcome in `initiative-frame.md`; the stop authority is exercised in `rollout-contract.md`; the distributed review is what makes driver D4 in `architecture-driver-table.md` reachable; escalation trigger 1 is the recipient column in `delivery-and-dependency-map.md`.