Improve Team Accountability

Proof required

Submit: (1) a baseline accountability report covering 4–8 weeks: total commitments made (documented from standups, sprint plans, or weekly plans), total commitments completed on time, completion rate, and the 2–3 most common failure categories with example commitments that fell into each; (2) a root cause diagnosis (200 words minimum): the dominant accountability failure pattern and what is sustaining it; (3) a pre-committed structural change and target: the specific change to how commitments are tracked, reviewed, or followed up on — written before implementation begins — and the completion rate target you expect after 4–8 weeks.

What gets checked

• Baseline draws from an actual tracking source — a commitment list assembled from memory after the fact is not a baseline; the proof must reference standup notes, sprint retrospectives, project plans, or another real record of commitments made
• Failure categories name specific patterns with examples — 'people don't finish things' is not a pattern; 'commitments are made in standup under time pressure with no size estimate, making 40% of them unrealistic from the start' is
• Structural change is specific and distinct from a cultural appeal — 'remind people to be accountable' is a cultural appeal; 'add a Wednesday commitment-check-in where each person gives a 30-second status on every open commitment from Monday's standup' is a structural change

Common mistakes

• Conflating accountability with discipline — accountability failures are usually systemic, not individual; a diagnosis that attributes missed commitments to specific team members' attitudes is not a structural diagnosis and will produce a structural change that does not address the real cause
• Setting a target after the intervention results are visible — the target must be written before the structural change is implemented; a target that matches what happened is not a pre-committed target
• A structural change that adds tracking overhead without changing the accountability feedback loop — adding a spreadsheet where people log their commitments without any consequential review of that spreadsheet is not an accountability change; the structural change must alter what happens when a commitment is missed

Resources

What a verifier looks for

• Baseline source quality: ask the submitter where the commitment data came from — if they say 'I estimated based on what I remember', the baseline is not real; a real baseline traces to standup notes, sprint boards, or project plans
• Root cause specificity: ask what specifically sustains the failure pattern — a diagnosis with no mechanism for why the pattern persists is not a structural diagnosis
• Structural change test: ask whether the change would still improve accountability if no individual team member changed their attitude or effort — if the answer is no, the change is a cultural appeal, not a structural change

Proof required

Submit: (1) post-change commitment data for 4–8 weeks: the same metrics from M1 per week, using the same tracking source and method; (2) a structural change implementation log: the date the change went live, any adjustments made to the structural change design during the measurement period and why, and the current state of the structural change at the end of the period; (3) a notes log for each week capturing any anomalous weeks — team member absences, holidays, major incidents, or external deliverable deadlines that compressed the normal commitment cycle.

What gets checked

• Post-change data uses the same metric definition as M1 — the comparison is only valid if both periods measure the same thing the same way
• Implementation log captures real adjustments — a structural change that required zero adjustments in 4–8 weeks is unusual; the log should include at least one edge case that required a design decision
• Anomalous weeks are documented proactively — the notes log should be written contemporaneously, not reconstructed at the end of the period; dated weekly entries are the standard

Common mistakes

• Abandoning the structural change after 2 weeks because it was 'not working' — meaningful signal in accountability data requires 4–8 weeks; early discontinuation produces data too noisy to interpret
• Changing the metric definition mid-period to show improvement — if the week-4 completion rate looks worse than baseline, redefining what counts as a commitment to show a better figure is not a valid adjustment
• Implementation log that only records successes — most accountability systems encounter resistance in the first few weeks; an implementation log with no friction entries does not reflect a real implementation

Resources

What a verifier looks for

• Metric consistency: check that M2 data uses the same commitment definition as M1 — ask the submitter whether any commitments that would have been counted in M1 were excluded in M2, and why
• Implementation friction: ask what the most difficult part of implementing the structural change was — a frictionless implementation description should prompt investigation into whether the change was substantial enough to create friction
• Contemporaneous documentation: ask when the notes log entries were written — end-of-period reconstructions are less reliable than dated weekly entries

Proof required

Submit: (1) a before/after comparison: M1 baseline completion rate, M2 post-change completion rate, M1 pre-committed target, and the delta — with a 200-word attribution analysis noting which factors besides the structural change might explain the change; (2) a lessons-learned document (300 words minimum): what the structural change did well, what it did not address, and what the next structural improvement would be if you were 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

• Comparison uses M1 pre-committed targets — the analysis must address whether the target was met; if not, the analysis must explain why rather than reporting a different metric that improved
• Attribution analysis names specific confounds — team composition changes, commitment volume changes, and period-specific pressures must each be addressed; 'there were no confounds' is rarely credible for a 4–8 week period
• Q&A shows the reviewer challenged the structural change design — a reviewer who only validated the outcome numbers without probing the design choices ('why did you choose this structural change over alternative approaches?') did not meet the adversarial standard

Common mistakes

• Reporting improvement by switching to a metric not committed in M1 — the pre-committed target was written at M1; the M3 analysis must address that target
• Claiming improvement while commitment volume dropped — a higher completion rate with half as many commitments per week is not an accountability improvement; the analysis must normalise for commitment volume
• Reviewer who only reads the numbers — a reviewer who did not ask about the structural change design and attribution methodology during the Q&A session has not met the adversarial verification standard

Resources

What a verifier looks for

• Volume normalisation: ask whether the number of commitments made per week changed between M1 and M2 — a higher completion rate on fewer commitments is not an accountability improvement
• Target fidelity: compare the M3 reported target to the M1 pre-committed target — if they differ, ask when the target was set
• Reviewer challenge quality: look for design-challenge questions in the Q&A documentation — 'why did you choose a commitment-check-in cadence rather than a weekly retrospective review?' is an adversarial design question; 'were you happy with the results?' is not