Safety II is not just a philosophy — it is a practice. The practice is to stop ignoring events where nothing bad happened and start treating them as primary learning opportunities.
The Near Miss is a Goldmine
Imagine an engineer is about to run kubectl delete namespace production and stops at the last second because something "felt off." They re-read the command, realize the mistake, and close the terminal.
- Safety I response: "Nothing bad happened. No incident ticket needed. Move on."
- Safety II response: "That was remarkable. What signal made them pause? Was it the namespace name? The lack of a
--dry-runflag? Can we surface that signal automatically — a confirmation prompt, a color-coded terminal for production contexts — so every engineer gets that protection, not just the experienced ones?"
The near miss reveals a defensive mechanism that exists in one person's head. Safety II asks how to make that mechanism systemic.
Learning from Successful Incident Response
Even when an incident is handled well, the Safety II lens finds learning. The framing shifts from deficit-based to capacity-based:
| Safety I Question | Safety II Question |
|---|---|
| "Why did it take 5 minutes to detect?" | "How did you detect it in only 5 minutes given how noisy the alerts are?" |
| "Why did the fix take 20 minutes?" | "How did you know which fix to apply so quickly?" |
| "Why wasn't this in the runbook?" | "You solved this without a runbook — what knowledge did you use, and how do we capture it?" |
This reframing reveals hidden capacities: the senior engineer's mental model, the undocumented dashboard, the Slack channel where the real knowledge lives. These are organizational assets that Safety I analysis never surfaces because it only looks at what went wrong.
The Practical Tool: The Success Post-Mortem
A Success Post-Mortem (also called a "Resilience Analysis" or "Positive Debrief") follows the same structure as a standard post-mortem but inverts the questions. Instead of "what failed and why?", it asks "what succeeded and how?" The output is not a list of action items to prevent recurrence — it is a list of capabilities to amplify and distribute across the team.