The Team Charter Template 2.3B.1-1

Using This Template

This template is a tool, not a form. Complete it collaboratively. Each section should be discussed, debated, revised, and agreed to before the charter is finalized. A charter arrived at through argument is stronger than a charter arrived at through consensus theater — it has been tested against actual disagreement.

The template does not prescribe answers. It prescribes questions. Every team's cooperation is structured differently. The structural requirement is that the terms are visible, contestable, and revisable — not that they match a standard pattern.

Section 1: Team Identity

Team name:

Primary purpose: What is the team actually responsible for? Not a mission statement — a specific function.

Team size and composition: Current headcount and roles represented.

Reporting structure: Who does the team report to? Who approves the charter? Who can amend it?

Section 2: Role Map

For each role on the team:

Table 2.3B.1-1 — Role map: scope, decision authority, and interfaces

Scopes that overlap create ambiguity. Ambiguity becomes conflict. The role map's structural function is to prevent the condition where two people each believe they hold the same decision right — a condition that resolves through informal power, not through method.

Section 3: Decision Rights Matrix

Table 2.3B.1-2 — Decision rights: authority, consultation, and appeal

Common decision types include: hiring and termination, budget allocation, technical architecture changes, process changes, customer commitments, promotion and compensation, and tool and platform choices.

Decider is the role whose judgment is final. If two roles can both decide the same thing, rewrite the row — it means no one actually decides. Consulted roles must be asked before the decision is made; their input may change the outcome. Advised roles offer views that are not binding. Informed roles hear the decision after it is made. Appeal process specifies the mechanism — silence here means disputes have no structural path to resolution.

Section 4: Interface Specifications

For each significant handoff between roles:

Table 2.3B.1-3 — Interface contracts: deliverables, standards, and recourse

Quality standards must be testable. "Good specs" is not testable. "All acceptance criteria are present; each criterion can be verified in under two hours of QA time" is testable. The owner of the interface is responsible for maintaining the specification if conditions change — pick one owner, not two.

Section 5: Consent Validity Checkpoints

For each team member, assess the four conditions of valid consent:

Table 2.3B.1-4 — Consent validity assessment

For each "No" or "Partial," name the specific barrier, the action to remove it, the deadline, and the person responsible. A barrier that is identified but never addressed is not a plan — it is a record of inaction.

Section 6: Interface Map

Draw or describe the team's dependencies using this format:

Dependency: [Role A] depends on [Role B] for [specific deliverable or capability].

If this dependency breaks: [Role A] is blocked from [specific output or decision]. Cost of blockage: [what the team loses, timeline impact]. Recovery time: [how long to replace or restore the dependency].

Hardening actions: For each critical dependency, specify one structural hardening action — cross-training, documentation, backup capacity, or redesign — and implement it.

The interface map is a diagnostic tool, not a criticism. It makes load paths visible so the team can identify fragility before it becomes crisis.

Section 7: Payoff Table

Table 2.3B.1-5 — Payoff alignment: contribution mapped to recognition

Input metrics should be within the role's control. Output metrics are team metrics, but the table shows how the role's contribution connects to them. Standard performance is the baseline — what the role is hired to do. Review cycle specifies when the mapping is reassessed; if team outputs change, the payoff table should be revisited.

Section 8: Review Schedule

First review: [Date — typically ninety days after charter adoption.]

Subsequent reviews: [Quarterly / annually] on [specific date].

Amendment process: Changes require approval from [specify who] and agreement from [team consensus / team lead / affected role holders].

Version log:

Implementation Checklist

Move the charter from document to operating system:

• All roles have reviewed and accepted the charter.
• All decision rights have been tested in a real decision within thirty days of adoption.
• All interfaces have been specified and reviewed by both parties.
• Consent validity barriers have been addressed, or a plan with deadlines exists.
• The interface map has been drawn and shared with the team.
• The payoff table has been reviewed; each person can articulate their own row.
• Entry requirements have been tested with a recent hire.
• Exit process has been walked through (not executed, but simulated).
• A review date has been scheduled.