CassioRoos Premortem / Postmortem
Use premortems to prevent predictable failure. Use postmortems to learn without rewriting history.
Premortem
Frame it as: "It is six months after launch. This failed badly. What killed it?"
Steps:
- Define success in measurable terms.
- List failure causes independently before filtering.
- Classify causes:
- Real threats: plausible, damaging, actionable.
- Noise: scary but unlikely or unactionable.
- Avoided truths: politically or emotionally uncomfortable risks.
- Score real threats by impact, likelihood, and detectability.
- Turn the top threats into controls, owners, and validation tests.
- Define launch gates and rollback triggers.
Premortem output:
## Success Definition
## Failure Story
## Top Failure Causes
- Cause:
Class:
Evidence:
Impact:
Likelihood:
Detectability:
Prevention:
Detection:
Owner:
## Launch Gates
## Rollback Triggers
Postmortem
Do not hunt for a single root cause when the evidence shows a chain. Most failures are systems failures.
Steps:
- Build a timeline from evidence: logs, metrics, deploys, alerts, commits, tickets, user reports.
- Separate facts from interpretations.
- Identify contributing factors across code, process, config, monitoring, docs, and decision-making.
- Ask why detection failed or succeeded.
- Define corrective actions with owners and deadlines.
- Add regression tests, monitors, runbooks, or guardrails.
Postmortem output:
## Impact
## Timeline
## What Happened
## Contributing Factors
## Detection And Response
## What Worked
## What Failed
## Corrective Actions
- Action:
Owner:
Due:
Verification:
## Follow-up Risks
Rule
Do not accept "human error" as a root cause. Human error is where the investigation starts.