---
name: Five Whys
status: draft
territory: causal-investigation
host_mode: root-cause-analysis
also_loadable_in: []
msi_wired: false
sources:
  - title: "Ohno, Taiichi (1988), Toyota Production System: Beyond Large-Scale Production, Productivity Press"
    url: https://openlibrary.org/works/OL8681881W
---

# 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 to invoke it in Ora

You have a problem you've already tried to fix once — something that keeps coming back, or where the obvious patch didn't hold — and you want the cause underneath the cause, not the first one that stops the bleeding.

State the problem as a *failure*, and ask:

> "Find the root causes: our nightly data export keeps failing, we already added a retry and it still fails about once a week — why does this keep happening?"

The five whys is one of the two core protocols of the Root Cause Analysis mode. Ora states the problem precisely, lays out the candidate categories of cause, and then — on the candidates that survive — drills downward, taking each answer and asking "why did *that* happen?" again, until the chain reaches something structural: a process gap, a missing check, an incentive that made the failure likely. It reports the chain, the depth it reached, and a fix aimed at the structure rather than the symptom.

One thing to know: phrases like *what are the root causes of*, *why does this keep happening*, *what's the real problem here*, or *we tried X but it didn't work* are what route you here. State the thing as a failure ("X keeps doing Y"), not as a wish ("we need X to be more reliable") — the analysis reshapes wishes into failures before it can diagnose them. And the deeper you can make the symptom — *when* it happens, *what* it costs — the sharper the drilling, because a vague problem statement produces vague "why"s.

One thing Ora won't do: let the chain stop at a person. When a line of "why"s bottoms out at "someone made a mistake," the analysis is required to ask one more — why did the system let that mistake cause the failure? — because the fixable root is the missing guard, not the human who tripped without one.

## 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

*This section uses Ora's own terms for the parts of an analysis, so that if you open the actual mode and lens files they line up. Each is glossed in plain language on first use.*

### Pipeline execution

The five whys is one of the two **required** protocols of the Root Cause Analysis mode (the other is the fishbone diagram, which nests this drill inside each of its category branches) — listed in the mode's `lens_dependencies` and loaded in its **`ANALYTICAL PERSPECTIVES`** block. As a `lens_type: protocol`, it contributes a procedure rather than a concept: where the fishbone supplies the mode's *breadth*, the five whys supplies its *depth*. The mode runs at **Gear 4**, Ora's most thorough setting — a **Depth analyst** and a **Breadth analyst** diagnose the problem in parallel, critique each other, and revise before a final pass consolidates the result.

**Where the lens engages.** It activates on its **Detection Signals** — a bug or failure patched but still recurring in slightly different forms; a post-mortem that records *what* happened but not *why*; a proposed root cause of "human error"; a process throwing defects that the team is treating one at a time. Its **Application Steps** receive the problem and proximate explanation from the host, run the iterative drill, define a systemic corrective action, and return the chain — flagging any "why" answer that lacks supporting evidence as a hypothesis still needing verification.

**What it produces in the analysis.** This protocol is the engine of two output sections. Inside the **Category analysis** section — the populated fishbone — it runs the descent on the *survivors*: for each candidate cause that wasn't ruled out, it takes the answer and asks "why did that happen?" again, each answer becoming the new problem statement, peeling proximate causes (someone forgot; a value was wrong) down toward a structural one (the missing check that let the value be wrong). That descent is what populates the **Root causes** section and produces its **depth measure** — the mode reports causes that reach real depth, *2–4 levels beneath the symptom*, each justified by the test "would removing it prevent recurrence?" A chain that stops one level down hasn't found a root; it's found another symptom.

**Cross-adversarial evaluation.** At Gear 4 each analyst's reading is critiqued by the other, which catches this protocol's signature failures — keyed to its **Critical Questions**: a chain that bottomed out at a proximate cause without reaching the systemic one; "why" answers inferred to keep the chain moving rather than supported by evidence; a single chain drilled when the symptom plausibly had several parents. The evaluator presses the mode's discipline hardest at the **Evidence assessment** section, where each link in the chain must be evidenced rather than asserted and at least one cause→effect relationship carries an explicit *correlation-vs-causation* note — a "why" answer that merely co-occurs with its effect is not yet a cause.

**Honesty discipline.** The mode's hardest rule lives in this protocol: where a chain reaches **"human error,"** it is required to descend *one more level* — to the process, policy, or incentive that made the error likely — rather than stopping at a person to blame. This is the lens guarding the mode against **fundamental-attribution-error**, the always-loaded bias that reads a bad outcome as a flaw in the operator when the situation made the slip nearly inevitable; the fixable root is the absent guard, not the human who tripped without one. The mode then separates **corrective** recommendations (fix the surfaced instance) from **preventive** ones (fix the structural condition the drill exposed), and records **confidence** in the dominant chain alongside the alternative framing it considered and rejected.

**What the analysis will not do.** It will not accept "operator error" as a terminal answer when a process produced the operator's mistake, will not let a "why" answer pass as fact when it is only a plausible guess, and will not present one clean chain as the whole story when the symptom had more than one parent.

### 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.

## Related

- **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.

## Sources

- [Ohno, Taiichi (1988), Toyota Production System: Beyond Large-Scale Production, Productivity Press](https://openlibrary.org/works/OL8681881W)