Deep Dive · Issue 15
Why the Five Whys makes your postmortems worse
A 1950s Toyota technique is still the default in software postmortems. It drifts toward blame, produces false confidence, and suppresses the operational data postmortems exist to capture.
The problem
A row of dominoes that isn't
The Five Whys came from Taiichi Ohno's Toyota production line in the 1950s. You ask "why did that happen?" five times, follow the chain down, and arrive at a root cause. The method assumes each cause has exactly one antecedent, like a row of dominoes toppling in sequence.
Richard Cook's "How Complex Systems Fail" argues that post-accident root cause attribution is "fundamentally wrong" because complex systems run with multiple latent flaws that only produce an outage in combination. Each small failure is necessary on its own, but only the combination is sufficient. The ClickHouse RCA guide notes the 5 Whys "biases toward one cause" and that chain quality "depends on who answers."
The mechanism
Why drifts to who
John Allspaw, former SVP of engineering at Etsy, identified the central problem: asking "why?" too easily drifts toward "who?" or toward the motivations people bring into the workplace. His canonical example traces a chain from server failure to subsystem misuse to engineer ignorance to insufficient training to managerial failure.
These are answers about "who," not descriptions of what conditions existed. Allspaw notes they depend on hindsight: we know the subsystem was used the "wrong" way only because we connect it to the resulting failure. The engineer using it at the time would have said they were doing it right.
Blame kills curiosity.
The Conflux team adds the psychological safety dimension, citing Amy Edmondson's research: when people fear blame, they stop bringing issues to light. If you think an incident was someone's fault, even silently, you stop asking questions about what happened.
The numbers
One root cause, six actual causes
Mark Paradies at TapRooT analyzed Ohno's own canonical robot example, the one used to teach the Five Whys. Ohno's chain arrived at a single root cause: no filter on the pump. TapRooT's analysis found 6 causal factors, including no low oil pressure alarm, improper QA controls, operator-mechanic communication failure, and the mechanic not reporting metal filings.
Robot stopped
- No filter (Ohno's 1 cause)
- No oil alarm
- Bad QA
- Comm failure
- Unreported filings
The Salesforce Engineering post makes the simpler point about the number itself: five is completely arbitrary. Stop at six or seven and you get a different root cause each time.
Paradies also identifies confirmation bias as a structural problem. Because 5-Whys is easy when you already "know" the answer, investigators look for evidence that fits their chain and ignore evidence against it. This happened even with Ohno himself.
The alternative
How did it unfold?
Allspaw draws on Sidney Dekker's distinction between first stories and second stories. A first story says human error caused the failure, and telling people to be more careful will fix it. A second story says human error is a symptom of systemic vulnerabilities, and the real question is why it made sense for someone to do what they did at the time.
Asking "how" instead of "why" surfaces what Allspaw calls local rationality: the idea that people's actions made sense given the information, pressures, and goals they had at the time. His "Infinite Hows" approach elicits the approaches engineers took, how they gained confidence through tests and reviews, the trade-offs they managed, and the time pressure they experienced. This is the operational data that the Five Whys forecloses.
When 'root cause' is actually useful
Lorin Hochstein argues that "root cause" has a legitimate meaning during active anomaly response: it signals that your mental model doesn't explain what you're seeing. The term becomes harmful when carried into post-incident analysis, where it collapses multiple contributing factors into a single answer and stops the investigation prematurely.
The technique also has no inherent stopping mechanism. The reliamag analysis identifies the "infinite regress trap": each answer naturally prompts another question, creating an endless chain far beyond actionable interventions. Their analysis found the 4th "why" is the most common actionable stopping point in industrial maintenance, not the 5th.
Closing
The cost of a single chain
Why it matters
The Five Whys is still the default root cause method in engineering onboarding decks and incident management templates. The critique from Allspaw, Cook, and the resilience engineering community has been circulating in SRE for a decade, but the practice persists because the technique feels rigorous and produces a clean answer. The clean answer is the problem. A postmortem that ends with a single root cause has stopped looking at everything else that contributed, and the next incident will likely involve the factors it missed.
The short version
- The Five Whys assumes each cause has one antecedent. Complex software systems fail through combinations of multiple latent flaws.
- Asking 'why' drifts toward 'who.' Blame and hindsight bias suppress the operational data postmortems exist to capture.
- Even Taiichi Ohno's own canonical example missed 5 of 6 causal factors. The harm is structural, not a matter of practitioner skill.
- The alternative is asking 'how' instead of 'why,' surfacing local rationality and rich operational narratives.
- Five is an arbitrary cutoff. The method has no stopping criteria, and the chain you get depends on who answers.
Sources
- 1.Making Blameless Post-mortems Work Well — Conflux
- 2.Kitchen Soap – The Infinite Hows (or, the Dangers Of The Five Whys)
- 3.What is root cause analysis? Methods, process, and limits
- 4.How, Not Why: An Alternative to the Five Whys for Post- ...
- 5.Making peace with “root cause” during anomaly response – Surfing Complexity
- 7.Are You Dissatisfied with 5-Why Root Cause Analysis?
- 11.5 Whys Root Cause Analysis: When to Stop Asking Why in Maintenance