Ship a Team Charter and Ways of Working

Proof required

Submit: (1) the final team charter document (300 words minimum), covering at minimum: team purpose, decision-making process, norms for communication and conflict, and how the charter will be reviewed; (2) evidence that the charter was created through a team process — meeting notes, async comment threads, or a workshop summary showing that all team members had a meaningful opportunity to contribute; (3) a sign-off record showing all team members acknowledged the charter — this can be a message thread, a shared-doc acknowledgement, or a meeting attendance record with a follow-up message confirming agreement.

What gets checked

• Charter addresses all four dimensions: purpose, decision process, behavioural norms, and review cadence — a charter that only covers ground rules for meetings is not a team operating system
• Charter was created with genuine team input — a document the manager drafted and sent for 'feedback' with no substantive changes is not a co-created charter; the facilitation evidence must show specific contributions from team members that shaped the final document
• Sign-off is from actual team members, not implicit — 'nobody objected' is not the same as 'the team agreed'; a positive acknowledgement from each team member is required

Common mistakes

• Writing the charter before the facilitation and using the team session to 'review' it — a pre-written charter presented for rubber-stamping is not a co-created team charter; the facilitation evidence must show the team's input shaped the content
• Creating a charter with no operational specificity — 'we will communicate openly' is a value statement; 'we will respond to async messages within one business day and escalate to synchronous conversation after two days with no resolution' is a charter norm
• No review cadence — a charter without a scheduled review point will be ignored after 90 days; the charter must specify when the team will return to assess how well it is working

Resources

What a verifier looks for

• Facilitation depth: ask the submitter which part of the charter changed most from their initial draft after team input — a real facilitation process changes content, not just formatting
• Charter specificity: ask for one example of an operational norm — 'we communicate openly' is a values statement; 'we resolve disagreements by async first, escalate to sync after two failed attempts' is a norm
• Sign-off evidence: confirm sign-off came from all named team members; a charter adopted by 5 of 7 members who were 'in the meeting' is not a full-team agreement

You'll sign in first, then come straight back here.

Proof required

Submit: (1) a 30-day log showing the charter was referenced or actively used — at minimum 3 entries, each dated, describing a specific situation where the charter provided guidance or resolved ambiguity; (2) one specific example with more detail: the situation, which charter element applied, how it guided the decision, and whether the outcome was as intended; (3) any amendments to the charter since sign-off and why they were made — a charter with no amendments in 30 days of real use warrants explanation.

What gets checked

• 30-day log entries are specific, dated events — not a summary statement such as 'we used the charter regularly'; each entry must describe a specific situation
• Detailed example shows the charter changed what happened — 'we discussed the issue' is not evidence; 'the conflict escalated to sync because we had exhausted async per the charter' shows the charter was operational
• Charter amendments are honest — either amendments with reasons, or a credible explanation for why none were needed (a very short and flexible charter, or a genuinely low-conflict 30 days)

Common mistakes

• Submitting the charter document with a note it was 'in use' — without specific usage examples, this does not satisfy the operational evidence standard
• Logging process-compliance moments instead of real-decision moments — 'we ran standup per the charter' is compliance; 'the async-first norm prevented two unnecessary synchronous meetings when the answer was found in thread' is impact
• Never amending the charter without explanation — if no amendments occurred, state why; unexplained absence of any friction suggests the charter may have been too vague to violate

Resources

What a verifier looks for

• Usage log specificity: ask for one situation from the log in more detail — a real usage moment produces a specific description; vague 'we referenced it' entries should prompt further probing
• Charter impact test: ask what would have happened in the detailed example if the charter did not exist — if the answer is 'the same thing', the charter did not change behaviour
• Amendment honesty: if there are no amendments, ask what the hardest norm to follow was in the first 30 days — almost every team finds at least one norm that required clarification

You'll sign in first, then come straight back here.

Proof required

Submit: (1) the 90-day retrospective document: at minimum one norm that worked as intended with evidence, one norm that did not work as expected with evidence, and the specific charter changes the team agreed on as a result; (2) the amended charter after the retrospective, with tracked changes or a summary of what changed; (3) documentation of a real-time Q&A session with a named reviewer who has ≥3 years of people management experience and a verifiable professional profile — the documentation must include specific challenge questions and your responses; the reviewer must not be a current direct report or close personal friend.

What gets checked

• Retrospective document uses specific evidence — 'the decision process worked well' is an impression; 'we used the defined decision process in 6 of 8 contentious situations and escalations to me dropped by roughly half' is evidence
• Charter amendments are connected to retrospective findings — each amendment must trace back to a specific team-identified problem
• Q&A documentation shows the reviewer challenged design choices — a reviewer who only said 'this looks good' did not meet the adversarial standard; look for reviewer questions like 'why did you design the decision process this way rather than X?'

Common mistakes

• A 90-day retrospective with no norms that failed — if the submitter claims all norms worked perfectly, ask them to describe the hardest team situation in 90 days and which charter element they wished they had written differently
• Manager retrospective presented to team — the team must be the source of retrospective evidence; a manager survey then shared is not a team retrospective
• Selecting a reviewer who already agrees with the approach — the reviewer must challenge specific design decisions with domain expertise behind the challenge

Resources

What a verifier looks for

• Retrospective quality: ask which norm the team most disagreed on — a genuine retrospective surfaces some disagreement; unanimous 'everything worked' is suspicious
• Amendment traceability: for each charter amendment, ask the submitter to name the specific retrospective finding that caused it
• Reviewer adversarial quality: look for design-challenge questions ('why a consensus model rather than a designated decider?') rather than only process questions

You'll sign in first, then come straight back here.