Build a High-Signal Team Communication Culture

Proof required

Submit: (1) a communication audit covering 4–6 weeks: at minimum 5 specific communication failure incidents, each dated and categorised (information-not-reaching-the-right-person, decision-not-documented, wrong-channel-for-the-stakes, async-information-treated-as-sync); (2) a root cause diagnosis (200 words minimum): the dominant structural gap in the team's current information-sharing or decision-making system, with the audit incidents as evidence; (3) a pre-committed structural change and expected outcome: the specific change to meeting cadence, async norms, escalation paths, or decision-logging — written before implementation begins.

What gets checked

• Audit incidents are specific and dated — 'people don't communicate well' is not an audit; '2026-06-15: the backend team spent half a day implementing a feature that the PM had already decided to de-scope in a Slack channel the backend lead was not in' is an audit incident
• Root cause diagnosis identifies a structural gap, not a behaviour pattern — 'people don't speak up in meetings' is a behaviour; 'the team has no canonical decision log and decisions are communicated informally, making it impossible to distinguish between live decisions and superseded ones' is a structural gap
• Pre-committed change is specific enough to implement — 'improve communication' is not a change; 'add a weekly 30-minute async written status update replacing the current Monday standup, with a read-receipt requirement from all team members' is a change

Common mistakes

• Auditing communication volume rather than communication failures — a count of Slack messages or meetings per week does not diagnose a communication problem; the audit must name specific incidents where communication failed and someone was worse off as a result
• Diagnosing individual communication styles rather than structural gaps — 'Person A doesn't give enough context in their messages' is an individual behaviour, not a structural gap; the structural gap is the environment that makes under-context communication invisible until it causes a problem
• Proposing a tool change without a norm change — installing a new tool (Notion, Loom, Linear) without specifying the norms for how it will be used does not address a structural communication gap; the change must specify what will happen differently, not just where

Resources

What a verifier looks for

• Incident specificity: ask the submitter to describe the worst communication failure in the audit period in detail — a real incident produces a specific description of who missed what information, when, and what it cost
• Structural vs. individual diagnosis: ask whether the communication failures would have occurred if a different person had been in each role — if yes, the gap is structural; if the answer is 'no, because Person A is just difficult', the diagnosis is individual-focused and will not produce a structural improvement
• Change specificity: ask the submitter what a team member would do differently in a specific scenario after the change is implemented — if the answer is vague, the change is not specific enough

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

Proof required

Submit: (1) an implementation log with at least 3 dated entries documenting how the structural change was adopted, including resistance or friction encountered; (2) a 6-week post-change incident comparison: re-categorise communication failures from the same 5 audit categories as M1; if the same type of failure is occurring less frequently, document a specific example of a situation where the new structure prevented the failure type from occurring; (3) at least 2 direct observations or quotes from team members noting a change in how they experience information access or decision clarity — this can be from retrospectives, 1-on-1 notes, or direct messages.

What gets checked

• Post-change incident comparison is apples-to-apples — the same 5 failure categories from M1 must be re-assessed using the same observation method; adding new categories or removing hard-to-measure ones to improve the appearance of the comparison is not valid
• Prevention evidence is specific — 'the new norm prevented misalignment' is a claim; 'on 2026-07-14, the backend lead found the de-scope decision in the decision log before starting implementation — this would have been a missed communication under the old system' is evidence
• Team member observations are genuine — a quote like 'communication is better now' without a specific example does not satisfy the observation standard; the observation must name a specific experience

Common mistakes

• Measuring adoption (how many people read the async update) rather than outcomes (how many communication failures were prevented) — adoption data is useful but does not prove that communication improved
• Reporting the absence of incidents as evidence of improvement — if no new incidents occurred in 6 weeks, either the change worked or the observation was not rigorous; the post-change incident log must use the same rigor as the M1 audit
• Team member observations that are satisfaction surveys rather than outcome observations — 'I like the new async format' is a preference; 'I found out about the decision to delay the feature in the async update, before I wasted time scoping it' is an outcome observation

Resources

What a verifier looks for

• Apples-to-apples comparison: confirm that the M2 post-change incident comparison uses the same 5 categories and the same observation method as M1 — if different, ask why the categorisation changed
• Prevention evidence quality: ask the submitter to name one specific situation where the new structure prevented a communication failure — if they cannot give a specific example, the prevention claim is not evidenced
• Observation authenticity: ask the submitter for the full context of each team member quote — where did it come from, and what specifically prompted the team member to say it

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

Proof required

Submit: (1) a before/after summary: the M1 dominant structural gap, the structural change implemented, the change in incident frequency for the most prevalent failure category, and 2 specific prevention examples; (2) a lessons-learned document (300 words minimum): what the structural change did well, what it did not address, and what additional change you would make if continuing; (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 your current manager or a direct report.

What gets checked

• Before/after summary is honest about partial improvement — if the M1 dominant failure category still occurs but less frequently, the summary must quantify 'less frequently' and note which categories did not improve
• Lessons-learned document identifies the communication pattern that the structural change did NOT fix — almost no single structural change addresses all communication failures; naming what was left unaddressed is more credible than claiming comprehensive improvement
• Q&A documentation shows the reviewer questioned the structural gap diagnosis — a reviewer who focused only on whether the team adopted the change without questioning whether the change addressed the right structural gap did not meet the adversarial standard

Common mistakes

• Before/after summary with only positive evidence — cherry-picking the two best examples while omitting incident categories that did not improve is not a credible before/after comparison
• Lessons-learned that only credits the structural change — if the incidents reduced, other factors (a difficult project ending, a team member departure) may have contributed; honest attribution is required
• Reviewer who only observed the change process rather than questioning the design logic — a reviewer who participated in the change rollout and already knows the evidence does not provide adversarial challenge; the reviewer should encounter the evidence for the first time during the review session

Resources

What a verifier looks for

• Evidence balance: ask the submitter which failure category showed the least improvement — if they cannot name one, the assessment may not have been balanced
• Design-logic challenge: ask why the specific structural change was chosen over alternative approaches — a reviewer should probe whether the chosen change actually addressed the diagnosed structural gap
• Attribution honesty: ask whether any other changes occurred during the M2 period that might explain some of the improvement

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