The Second Story of an Incident
The first story blames human error and stops there; the second story asks why the action made sense to the person at the time and what systemic conditions enabled it. Seeking the second story is the heart of blameless, learning-oriented incident analysis.
Why it exists
Stopping an investigation at human error feels satisfying but explains nothing and fixes nothing, because the next person facing the same conditions will make the same choice. The concept of the second story exists to push analysis past blame into the systemic factors that made the error likely and even reasonable.
The mental model
Every incident has two stories. The first story is the convenient narrative: a person did the wrong thing, end of analysis. The second story assumes the person was competent and acting in good faith, then asks why their action made sense to them at the time, given what they could see, the tools they had, the time pressure, and how the system was designed. Human error becomes the starting point of inquiry, not its conclusion.
How it works
To reach the second story, you reconstruct the responder's local rationality: what information was and was not visible, what the interface or alert implied, what defaults or ambiguous design nudged them, and what production pressure shaped the decision. From that you identify systemic contributors, a confusing UI, a missing guardrail, a misleading metric, and you fix those. This is the operational expression of a blameless culture, drawn from how high-reliability fields study accidents.
When it matters
It matters whenever an incident is quickly labeled operator error or fat-finger, which is precisely when the real lessons are about to be missed. Seeking the second story is what makes postmortems generative rather than punitive, and it directly protects psychological safety, since people disclose mistakes honestly only when they trust the analysis will examine the system, not punish them.
A concrete example
First story: an engineer ran a delete command against production and caused an outage, so the cause is human error. Second story: the staging and production terminals looked identical, the command had no confirmation prompt, and the engineer was rushing during an unrelated incident. The fixes that follow are distinct prompts for production, a confirmation guard, and clearer environment indicators, none of which the first story would ever surface.
Interview question
What distinguishes the second story of an incident from the first story?
- a.The second story identifies which person to discipline more firmly
- b.The second story is simply a more detailed account of the timeline
- c.The second story concludes that human error was the root cause
- d.The second story asks why the action made sense given the person's conditions and uncovers systemic causesCorrect
Why? this is the answer
The second story treats human error as a starting point and probes the systemic conditions, like tools, design, and pressure, that made the action reasonable. The first story stops at blaming the person, which surfaces no durable fix.
Just read this? Test yourself on what you have been reading.
- #second-story
- #blameless
- #human-error
- #resilience-engineering
- #sre
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles