Definition
A post-mortem (or retrospective) is a structured review conducted after an event — success or failure — to extract lessons, identify root causes, and update systems so the same failure is less likely next time. It is the complement to a Pre-Mortem, which runs the same logic before commitment.
Why It Matters
Without post-mortems, organizations repeat mistakes while celebrating wins they cannot reproduce. The goal is not blame assignment but organizational learning: turning one-off incidents into durable improvements in process, training, and design. In high-performance cultures (Extreme Ownership, SpaceX-style failure analysis), post-mortems are a primary mechanism for compounding judgment.
Core Concepts
- Blameless analysis: Focus on what in the system failed — training, clarity, resources, design — not who to punish. Blame cultures produce hidden failures; learning cultures surface them early.
- Root cause vs. proximate cause: “The weld failed” is proximate; “We had no weld inspection standard under schedule pressure” is closer to root. Stop at proximate cause and the same mechanism lives on.
- Five Whys: Repeatedly ask why until you hit a falsifiable system fix, not a person to fire. See First Principles Thinking and The Five Whys.
- Action items with owners: A post-mortem without assigned mitigations is theater. Every finding needs an owner, deadline, and verification.
- Cadence: Post-mortems belong in regular Communication in Management — after incidents, launches, quarters, and major decisions — not only after catastrophes.
- Success post-mortems: Run them on wins too. What was luck vs. skill? What must be preserved?
- Where it lives in the vault: After outcomes — complements step 3 of Difficult Decision Protocol, which runs before commitment. This note defines the tool; post-decision learning follows its own cadence via Communication in Management.
Pre-Mortem vs. Post-Mortem
| Pre-mortem | Post-mortem | |
|---|---|---|
| When | Before commitment | After outcome |
| Question | ”It failed — why?" | "It happened — why?” |
| Output | Mitigations, go/no-go | System fixes, updated playbooks |
| Primary risk avoided | Preventable failure | Repeated failure |