The 5-Whys is Toyota's method for finding root causes. Ask "why" five times, fix the structural problem, and stop fixing symptoms that keep returning.
The 5-Whys is Toyota's method for finding the root cause of a problem. The technique is exactly what it sounds like: state the problem, ask why it happened, ask why about the answer, and repeat until you reach a cause that is structural rather than symptomatic. Five iterations is the convention. Sometimes three is enough, occasionally seven is needed, but five is where most problems yield.
The method exists because most people, when confronted with a problem, fix the first thing they see. The caterer was late, so switch caterers. The server crashed, so restart the server. The report was wrong, so correct the report. Each of these fixes addresses the symptom rather than the underlying condition that produced it, which is why the same problems keep surfacing in slightly different forms. Fixing problems at the surface is like cutting weeds – they grow back. Fixing them at the root cause is like pulling them out entirely.
The 5-Whys provides the discipline to reach the root before acting.
How It Works
The method is straightforward, which is part of its power and part of its danger.
Step 1: State the problem clearly. Be specific. "Our delivery was late" is better than "logistics isn't working."
Step 2: Ask: why did this happen? Note the answer.
Step 3: Ask: why did *that* happen? Note the answer.
Step 4: Repeat until you have asked "why" five times, or until the answer you reach is a structural cause that, if fixed, would prevent recurrence.
Step 5: Formulate countermeasures to address the root cause. The emphasis is on prevention, not correction.
A worked example makes the method concrete. Imagine a team that has just organised an event where the catering arrived two hours late:
| Why | Question | Answer |
|---|---|---|
| 1 | Why was the food two hours late? | The purchase order was issued only three days before the event. |
| 2 | Why was the PO issued so late? | The approval signatures took two weeks to gather. |
| 3 | Why did the signatures take so long? | The primary approver was on leave, with no documented backup. |
| 4 | Why was there no backup approver? | Nobody had set one up – the issue had never surfaced before. |
| 5 | Why hadn't it surfaced? | There was no checklist for time‑critical procurement tasks, so the leave‑cover gap was invisible. |
The root cause is not the caterer, not the approver, and not the leave policy. It's the absence of a checklist for time-critical tasks. Switching caterers – the instinctive fix – would have changed nothing. Installing the checklist prevents recurrence permanently.
When To Ask More (or Fewer) Than Five
Five is a convention, not a rule. In practice:
Fewer than five usually means the analysis hasn't gone deep enough. If your root cause is "the supplier was bad" at iteration two, you've almost certainly stopped at a symptom.
More than five sometimes happens on complex problems, but going past seven or eight tends to produce diminishing returns and analyst fatigue without proportional benefit.
Branching is common. A single "why" can produce two or three answers, each of which becomes its own line of inquiry. The table method and the fishbone (Ishikawa) diagram are two ways to visualise branching analyses and keep them manageable.
Who Should Run the Analysis
This is the single most important implementation detail and the one most often ignored: the 5-Whys should be run by the people closest to the problem, not by management at a distance.
In Toyota, the analysis is almost always conducted by the subject-matter expert on the ground – the person with firsthand knowledge of what happened. Analysis conducted at a distance, by someone reading a report rather than having lived the situation, will produce educated guesses. Countermeasures based on inaccurate root causes will fail, and the problem will return.
The instinct in many organisations is to conduct root-cause analysis in a meeting room, with senior people reviewing incident reports. This is structurally backwards. The people in the meeting room are furthest from the actual problem, while the people on the ground, those who know exactly what happened and why, are absent from the analysis. Toyota's approach inverts this: trust your people to provide the root-cause analysis, and use management's role to remove barriers to implementation rather than to diagnose.
Known Weaknesses
The 5-Whys is qualitative, not quantitative, and its conclusions depend on the perspective and experience of the analyst. This has several implications:
Bias: Two analysts examining the same problem can reach different root causes. Someone predisposed to blame suppliers will find supplier issues. Someone predisposed to blame process will find process issues. Both may be partially right.
Subjectivity: There is no objective "correct" answer to any given "why". The method relies on judgment. High-stakes problems, where political incentives exist to skew the conclusion, are particularly vulnerable.
The remedy is group work: Toyota's standard approach is to have multiple subject-matter experts produce their own analyses independently, then reconvene to present findings and discuss. The group prioritises fixable root causes collectively, reducing the impact of any one person's bias. A deeper discussion of these limitations – and how to compensate for them – is covered in 5-Whys Weaknesses.
Common Mistakes
Stopping at blame: "The supplier failed" is not a root cause. It's an attribution. The question is always: why did the system allow the supplier to fail without a fallback?
Skipping straight to solutions: Teams under pressure often abandon the analysis at iteration two or three because they've already thought of a fix. The fix may work. It may also be a surface fix that addresses a symptom. The discipline is to complete the analysis before acting.
Running it top-down: When management conducts the analysis without the people who experienced the problem, the results are abstractions. The answers to each "why" become what management *assumes* happened rather than what *actually* happened.
Never acting on the output: The most common failure of all. The analysis is completed, the root cause is documented, and the countermeasure is never implemented because the organisation has already moved on to the next crisis.
Comments