Milestone map
Milestone map
3 milestones
Map Decision Failures and Diagnose the Cadence Gap
2–4 weeks for failure log collection and diagnosis
Decision cadence failures take three forms: decisions made too slowly (the team waits for a meeting that hasn't been scheduled), decisions made without the right people (someone with essential context is excluded), or decisions that are made but not recorded (the decision is revisited in a future meeting because no canonical record exists). The baseline must name which failure type dominates with specific incidents, and commit to a structural intervention — a new meeting rhythm, a decision log, a DACI or RACI framework, or a clear decision-rights specification — before implementation begins.
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
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
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
- 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
Implement Decision Structure and Collect Adoption and Outcome Evidence
6–8 weeks post-implementation evidence collection
The structural change is live. This milestone captures two types of evidence: adoption evidence (the decision structure is being used by the people it targets) and outcome evidence (decisions of the dominant failure type from M1 are being handled differently). A decision log that no one uses does not improve decision cadence; the post-implementation evidence must show both use and outcome improvement.
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
Resources
Foundationstart here
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
- 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
Report Decision Cadence Improvement with Expert Review
1 week for summary, lessons-learned, and expert review session
The final milestone requires a before/after summary comparing the dominant failure type from M1 against the post-implementation evidence, a lessons-learned document, and a real-time review with a named, qualified reviewer. The ADVERSARIAL VERIFICATION Level 2 standard applies: the reviewer must challenge the intervention design and the evidence, particularly whether the improvement reflects a structural change or simply a period of lower decision volume.
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
Resources
Foundationstart here
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
- 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