Five Whys

The Toyota technique adapted for SRE: where it works, where it lies, and "contributing factors" as the modern alternative.

Overview

Ask why, five times

Five Whys is a root-cause technique from Toyota's manufacturing process, adapted into SRE postmortem practice. Ask "why?" five times, peeling back one layer each time.

By why 5 you have moved from the symptom (500 errors) to a systemic cause (a library bug). Action items at the systemic level are higher-leverage than those at the symptom level.

Where it works and where it breaks

Linear causal chains: each effect has one obvious cause — Multiple contributing factors: most software incidents have 3-5 independent ones, and Five Whys forces a tree into a list
Manufacturing defects, Toyota's domain: physical parts with well-defined failure modes — Hindsight bias: you ask the question that fits the answer you already know
Single-component failures: a bad disk, config push or query — False precision: five layers feels rigorous, but choosing which "why" to follow is subjective
Stopping point — Arbitrary stopping: the answer may be at why 2 or why 8; "five" is convention, not science

The modern alternative: contributing factors

List every factor that needed to be true for the incident to happen. Most incidents have 3-7.

1 — The bad code was introduced in commit X
2 — The CI test for connection leaks was disabled (legacy)
3 — Canary deployment didn't cover the slow-path code
4 — The connection-pool alert was at 90%, but the pool sat 95% saturated for hours before the page
5 — The on-call runbook didn't list "check connection pool" as a debug step
6 — The retry library has known bugs (since 2024), but we're still on the old version

> [!IMPORTANT] Each factor is independently fixable. Cause is plural, and the postmortem should say so.

> [!NOTE] The Sidney Dekker (human factors) school: every incident has several contributing factors that aligned. Pulling on the one labeled "root cause" misses the vulnerability that let many factors align at once.

Pragmatic guidance

Exploration — Five Whys as a brainstorming technique in the postmortem: "keep asking why until we run out"
Documentation — A contributing-factor list, not "the root cause": "here are the seven things that all had to be true"
Action items — Target several factors, not just the deepest: the library bug and the missing CI check and the runbook gap

Key concepts

Five Whys: Iterative why-chain. Toyota origin. Useful for brainstorming; lying as a sole technique.
Contributing factors: Multiple things that combined to cause the incident. Modern human-factors approach. More accurate.
Hindsight bias: In retrospect, the cause is "obvious." Ask "given what was known at the time, was the decision reasonable?" to combat.
Linear vs systemic causation: Five Whys assumes linear chain; reality is usually networked — multiple causes aligned.
Sidney Dekker school: Human factors approach to incidents: multiple factors must align for failure. Eliminating one factor breaks the chain.

When to use it

During the postmortem review meeting — Five Whys as a brainstorming technique
When documenting root cause — favor "contributing factors" over a single "root cause"
Action item generation — each factor is its own action item
Recurring incidents — the contributing-factor list is more useful than a single root cause for finding patterns

Interview questions

Walk me through Five Whys for this scenario: a deploy caused a 30-minute outage.
What's wrong with Five Whys, and what's the alternative?
Why is "user error" rarely a valid root cause?