Improve Decision Cadence

Proof required

Submit: (1) a decision failure log: at minimum 5 specific decisions made in the past 6–8 weeks that exemplify the dominant failure type — for each, name the decision, the delay or error, and the cost; (2) a root cause diagnosis (200 words minimum): which of the three failure types dominates (too slow, wrong people, no record), and what specific structural gap causes it; (3) a pre-committed structural intervention — the specific decision-making change to be implemented (e.g. 'a weekly 30-minute decision log review meeting replacing ad-hoc decision requests' or 'a DACI template for all decisions affecting more than one team, with a 48-hour async comment window before implementation') — written before implementation.

What gets checked

• Decision failure log entries are specific and dated — 'we sometimes don't decide fast enough' is not an incident; '2026-06-12: a vendor contract decision waited 3 weeks for a monthly exec review meeting, during which the preferred vendor was acquired' is an incident
• Failure type diagnosis matches the evidence — if the log shows 4 of 5 incidents are 'no record' failures (decision was re-litigated because no record existed), the diagnosis must be 'no record', not 'too slow'; the diagnosis must be the one the evidence most supports
• Pre-committed intervention is structural and specific — 'we will communicate decisions better' is not a structural intervention; 'we will use a DACI template for all decisions touching more than one team, stored in the team wiki, with a named decision-maker and a rationale section' is a structural intervention

Common mistakes

• Conflating decision speed with decision quality — a fast bad decision is a worse outcome than a slow good decision; the intervention must improve decision reliability (right people, right record) not just decision speed
• Diagnosing all three failure types rather than the dominant one — a diagnosis that identifies three equally important problems produces an intervention that addresses none of them well; the pre-committed intervention must target the most damaging failure type
• DACI or RACI as bureaucratic performance — implementing a decision-rights framework without training anyone how to use it or building the practice into a meeting does not change how decisions are made; the structural change must alter what actually happens, not just what exists on paper

Resources

What a verifier looks for

• Failure type diagnosis: ask the submitter to explain why the dominant failure type is the one they diagnosed — if the log shows a mix of types, which is most costly and why
• Pre-committed intervention specificity: ask the submitter to describe what a team member does differently next Tuesday as a result of the intervention — if they cannot describe a specific behaviour change, the intervention is not specific enough
• Cost of inaction: ask the submitter to estimate the total cost (in time, rework, or missed opportunities) of the 5 failure incidents in the log — teams that cannot quantify the cost of their decision failures may be underestimating the urgency of the intervention

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

Proof required

Submit: (1) an implementation log with at least 3 dated entries: the start date, what was put in place, who was trained or briefed, and any resistance encountered; (2) adoption evidence: for the 6–8 weeks post-implementation, how many decisions were processed through the new structure versus outside it; name at least 3 decisions processed through the new structure with their decision, the named decision-maker or approvers, and the date the decision was made and recorded; (3) outcome evidence: at least 2 specific incidents where the dominant failure type from M1 was prevented — name the decision, what the new structure enabled, and what would have happened under the old process.

What gets checked

• Adoption evidence shows use by others, not just the submitter — a decision log that only the submitter updates has not been adopted; at least 2 of the 3 named decisions in the adoption evidence must have been initiated or updated by someone other than the submitter
• Outcome evidence is specific — 'decisions are being made faster' is not specific; '2026-07-03: the vendor selection decision was made in 48 hours via async DACI comment window rather than waiting for the monthly all-hands' is specific
• Adoption fraction is honest — if only 40% of decisions are going through the new structure, the adoption figure must reflect that; claiming comprehensive adoption when many decisions are still handled ad-hoc overstates the change

Common mistakes

• Counting the creation of templates and wikis as adoption evidence — creating the infrastructure of a decision structure is not the same as adopting it; adoption is measured by decisions processed through the structure, not by documents created
• Measuring speed improvement on decisions that were already fast — if the post-implementation outcome examples are all easy decisions that would have been fast anyway, the outcome evidence does not demonstrate that the dominant failure type was addressed
• Attributing adoption friction to culture rather than design — 'people don't like using templates' is a design problem, not a culture problem; the intervention design can be adjusted to reduce friction without abandoning the structural goal

Resources

What a verifier looks for

• Adoption source: ask who initiated each of the 3 named decisions in the adoption evidence — if the submitter initiated all 3, the structure has not been adopted by others
• Outcome specificity: ask the submitter to describe the best outcome example in detail — what was the decision, what would have happened under the old process, and how long did the decision actually take
• Adoption fraction: ask what percentage of decisions in the 6-week period were processed through the new structure — a low fraction with a high-quality example is still a low-adoption outcome

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

Proof required

Submit: (1) a before/after summary: the M1 dominant failure type, the failure incident rate in M1, the post-implementation rate, the adoption fraction, and 2 specific outcome examples; (2) a lessons-learned document (300 words minimum): what the decision structure improved, what failure type it did not address, and what you would design differently; (3) documentation of a real-time Q&A session with a named reviewer who has ≥3 years of operations, engineering leadership, or product leadership experience and a verifiable professional profile — the documentation must include specific challenge questions and your responses; the reviewer must not be a direct report.

What gets checked

• Before/after failure rate comparison uses the same measurement methodology as M1 — same failure type definition, same observation window length, same team scope
• Lessons-learned names at least one failure type that the intervention did not improve — no single intervention addresses all three decision failure types; naming what was left unaddressed is more credible than claiming complete improvement
• Q&A shows the reviewer challenged the causal logic — a reviewer who asked only 'how did you implement it?' without asking 'how do you know the improvement is from the structure and not from a lighter decision load?' did not meet the adversarial standard

Common mistakes

• Before/after summary with no volume context — a lower failure rate during a period of lower decision volume is not necessarily an improvement in decision cadence; the summary must acknowledge whether decision volume changed between M1 and M3
• Lessons-learned that only credits the successful aspects of the intervention — a decision structure that improved 'no record' failures but did not address 'wrong people' failures should say so explicitly
• Reviewer who participated in or benefited from the new decision structure — a reviewer who was a decision-maker in the new structure has an interest in confirming its success; the reviewer should be external to the team and the decision process

Resources

What a verifier looks for

• Volume context: ask the submitter whether the rate of decisions requiring the new structure changed between M1 and M3 — a lower failure rate during a lighter decision period may reflect context, not structural improvement
• Failure type coverage: ask the submitter which of the three failure types (too slow, wrong people, no record) was not improved by the intervention — and why
• Causal logic: ask how the submitter is confident that the structural change, and not a change in team composition or project urgency, drove the improvement

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