Five Whys

Why it matters

The first answer to “what caused this?” is almost always a symptom wearing the costume of a cause. Ask “why?” a few more times and the real, fixable root finally takes the costume off.

For example: a customer’s payment fails at checkout. The obvious cause is “the payment service timed out — retry it.” But ask why it timed out: the service was waiting on the fraud check. Why was the fraud check slow? It was querying a table that had grown unindexed. Why had it grown unindexed? A migration that should have added the index silently failed months ago, and nothing checked. The real fix is five “why”s down from the symptom — restore the index and add a check that catches a failed migration — and you’d never have reached it by retrying the timeout. Retrying would have felt like a fix and bought you a week before the next outage.

What it reveals. The chain that connects a visible symptom to the structural cause underneath it — and the exact rung where the chain stops being something you can patch and starts being something you can fix.
How it changes the read. You stop asking “what’s the cause?” (the first plausible one, which is usually a symptom) and start asking “and why did that happen?” — until the answer is a process or a policy, not an event.
When to foreground it. A problem you’ve already “fixed” once that keeps coming back, or a post-mortem that has established what happened but not why the system allowed it.
What you’d miss without it. The systemic cause sitting one or two rungs below where the investigation comfortably stopped — almost always the one worth fixing.
Where it misleads. A real failure often has several converging causes, not one tidy chain; drill a single line of “why”s and you can descend confidently into one cause while two others go unexamined.

How it works

Picture a machine on a Toyota production line that suddenly stops. The natural thing — the thing almost everyone does — is to find what broke, fix that, and get the line moving again. So you look, and you find it: a fuse has blown from an overload. You replace the fuse, the line runs, and you move on. And next week the fuse blows again, because replacing it never touched whatever was overloading the circuit.

Now suppose, instead of stopping at the fuse, you keep asking one stubborn question. The machine stopped — why? The fuse blew from an overload. Why was it overloaded? The bearing wasn’t getting enough lubrication. Why wasn’t it getting enough lubrication? The lubrication pump wasn’t pumping enough. Why wasn’t the pump pumping enough? The pump’s shaft was worn and rattling. Why was the shaft worn? There was no filter on the pump, so metal shavings had gotten in and ground it down. Five “why”s below the dead machine, you finally reach something you can actually fix: install a filter. No one who stopped at the fuse — or even at the bearing — would ever have arrived there.

That descent is the whole technique, and it has a name: the five whys. Each “why” peels back one layer, and every layer down you go, the thing you find is less of an event and more of a condition — from a blown fuse (an event, fix it and it recurs) to a missing filter (a condition, fix it and the recurrence stops). The discipline is not the counting; “five” is just a rule of thumb for “more than you’ll want to.” The discipline is the refusal to stop at the first layer, the symptom, where instinct and the pressure to get moving both beg you to quit. Taiichi Ohno built exactly this habit into the Toyota Production System, as the heart of what he called “go and see” problem-solving — go to the actual machine, watch the actual failure, and ask “why” until the answer is something in how the work is designed rather than something that merely happened. Its complement, the fishbone diagram, handles the breadth — laying out every category a cause might live in — and runs this same drill down each branch worth pursuing; the five whys is the part that goes deep.

There is one trap the technique sets for the careless, and it’s the mirror image of its strength. Because it produces one clean chain, it tempts you to believe the failure had one clean chain — to drill a single satisfying line of “why”s while two other causes, quietly converging on the same symptom, never get asked about at all. The honest use treats a chain as one route to the root, not the only one: where the symptom could have several parents, you drill each, and you require evidence for every answer rather than inferring a plausible one just to keep the descent moving. A chain that reaches a tidy root by guessing at the middle is a story, not a diagnosis.

Framework & implementation

Origin and evidence

The five whys is Taiichi Ohno’s, developed at Toyota and set down in his Toyota Production System: Beyond Large-Scale Production (1988), where the lubricated-pump example above is his own illustration of the method. Ohno was the principal architect of the Toyota Production System, and he framed the technique as the practical core of genchi genbutsu — “go and see for yourself”: stand at the actual site of the problem, observe the real failure, and ask “why” five times to drive past the symptom to its structural cause. Its evidence is the same kind the broader Lean and Toyota Production System literature rests on — decades of industrial practice in which asking “why” repeatedly reliably surfaced process causes that single-pass fixes left untouched, which is why the drill spread from the factory floor into software incident response, healthcare safety review, and operations far beyond its origin. The number five is explicitly heuristic, not magic: Ohno’s point was that the first one or two answers describe what happened, and the real cause tends to surface only when you refuse to stop there.

Applications and common uses

The five whys is a working tool wherever a problem has already resisted its first fix and the team needs the cause beneath the cause before spending again.

Manufacturing and process quality. Its native ground: a defect or line stoppage drilled past the broken part to the process condition that broke it, the use Ohno built it for.
Software incident post-mortems. A retrospective that has nailed down what failed uses the drill to reach why the system allowed it — past the bad deploy to the missing rollback, past the bad query to the absent index check.
Healthcare and patient safety. Adverse-event review uses the descent to push past the clinician nearest the error to the staffing, handoff, or procedure gap that set the error up — the discipline that keeps a review from stopping at a name.
Operations and recurring complaints. A delay or failure that keeps recurring gets drilled until the answer is a policy or incentive rather than a one-off slip, so the fix changes the structure instead of re-firefighting the instance.
Inside a fishbone, on every branch worth it. Whenever a categorize-then-drill analysis is running, the five whys is the drill — the breadth tool finds the candidate causes, this one takes each promising candidate down to its root.

In every case the payoff is the same: a causal chain that descends from a visible symptom to a structural cause, an honest record of how deep it reached, and a fix aimed at the condition that produced the failure rather than the instance that revealed it.

Failure modes and when not to use it

The protocol’s characteristic ways of going wrong are catalogued in its Common Failure Modes:

Stop-at-blame. The chain stops at “person X made an error.” The tell is a “root cause” that names a human and goes no further. Correction: ask why the system permitted the error to cause the outcome — the systemic cause is the absence of a guard, not the person who needed one.
Speculative drilling. Each “why” answer is plausible but unsupported by evidence, the chain descending on inference rather than fact. The tell is a confident root reached without a single verified link. Correction: require evidence at each step; pause the drill where evidence is missing and resume when it arrives, rather than guessing through the gap.
Single-chain tunnel vision. Only one causal line is drilled while alternative chains go unconsidered. The tell is a tidy linear chain for a failure that plainly had several converging causes. Correction: when multiple proximate causes exist, drill each — this is exactly the gap the fishbone wraps the five whys to cover, supplying the breadth a single chain lacks.

When not to reach for it. When the failure is genuinely the convergence of several independent causes rather than one chain, the five whys alone will mislead by its own neatness — pair it with a fishbone (or run it under the Root Cause Analysis mode, which already does) so the breadth comes first and the drill follows. When the descent is being steered toward a predetermined culprit — the “why”s chosen to arrive at the answer someone already wanted — the technique launders a foregone conclusion as a diagnosis; the evidence requirement at each step is the guard, and without it the tool is worse than useless. And when the problem is simple and its cause is genuinely known, the ceremony of five “why”s adds nothing — just fix it.

Root Cause Analysis — the analysis this protocol anchors; turns a recurring failure into a tested set of root causes with corrective and preventive fixes.
Fishbone Diagram — the breadth tool that wraps this one: it enumerates candidate causes across every category, and the five whys drills each survivor down to its root.
Fundamental Attribution Error — the bias the descent guards against: blaming a person (“operator error”) when the process or situation was the real cause.
Swiss Cheese Model — when a failure got through because several layered defenses each had a hole, the chain isn’t a single line but a path through gaps; the holes are what the drill is reaching for.