The 5 Whys: Finding Root Causes Without Blaming People

How Toyota's 5 Whys works, how to back each answer with evidence, when to stop, when to switch to a fishbone diagram, and a worked warehouse example.

2026-10-24 · 6 min read

On 2 October, 14 of 120 orders at a mid-size e-commerce warehouse missed the 3 pm same-day dispatch cutoff. The first explanation in the morning meeting was "we were short-staffed". It was true, and it was useless: the warehouse had been short-staffed before without missing the cutoff. Twenty minutes with the 5 Whys found the real cause, a permission setting that let only one supervisor release picking waves. Fixing it took an afternoon.

That is the 5 Whys at its best. It is a simple discipline: keep asking why the previous answer happened until you reach something you can change that would stop the problem coming back. This guide covers where the method came from, how to run it well, where it breaks down, and how to record it in the 5 Whys Root Cause Analysis tool.

Where the 5 Whys came from

The technique comes from Toyota. Sakichi Toyoda, the inventor and industrialist whose loom company became the Toyota group, is credited with the practice. Taiichi Ohno, the engineer who built the Toyota Production System, made it standard on the shop floor and wrote about it in his book on the system.

Ohno's own example is a machine that stopped working:

1. Why did the machine stop? A fuse blew because of an overload.
2. Why was there an overload? The bearing was not sufficiently lubricated.
3. Why was it not lubricated? The lubrication pump was not pumping enough.
4. Why was it not pumping enough? The pump shaft was worn and rattling.
5. Why was the shaft worn? There was no strainer, so metal scrap got in.

Replacing the fuse gets the machine running today. Fitting a strainer stops it happening again. The whole method is in that difference.

How to run a 5 Whys well

The method looks trivial, and that is why it is so often done badly. Four rules make the difference.

Start from a fact, not a feeling. "Dispatch is a mess" cannot be analysed. "14 of 120 orders missed the 3 pm cutoff on 2 October" can. Write the problem statement with a time, a place and a number.

Answer each why with evidence. Every answer should be something you could show someone: a log entry, a timestamp, a photo, a document. If you find yourself guessing, stop and go and look. A chain built on guesses produces a confident wrong answer.

Stop at something you can change. The right place to stop is a cause that is within your control and whose fix would prevent recurrence. Five is a rule of thumb. Some chains get there in three steps; a few need six. If you keep going past a fixable cause, you tend to end up at "the economy" or "company culture", which nobody can fix by Monday.

Never stop at a person. "The supervisor was in a meeting" or "Alex forgot to check" is where weak analyses end. Ask why the process depended on that person remembering or being present. The answer is almost always a missing check, an unclear instruction or a tool that allowed the mistake.

Worked example: the missed dispatch cutoff

Here is the warehouse analysis as it was recorded in the 5 Whys tool.

1. Title: "Missed dispatch cutoff". Problem Statement: "14 of 120 orders missed the 3 pm same-day dispatch cutoff on 2 October."
2. Click Add Why. Why 1: "Picking for those orders finished at 3:40 pm." (Evidence: scanner timestamps.)
3. Add Why. Why 2: "Pickers waited 35 minutes for the afternoon wave to be released." (Evidence: wave release log shows 1:55 pm instead of 1:20 pm.)
4. Add Why. Why 3: "Wave release is a manual step and the shift supervisor was in a meeting." (Evidence: calendar and the warehouse system audit log.)
5. Add Why. Why 4: "Only the supervisor role has permission to release waves; there is no backup." (Evidence: role configuration in the warehouse system.)
6. Root Cause Identified: "Wave release depends on a single role with no backup and no automatic trigger."
7. Action Items: "Grant release rights to the two shift leads" and "Configure an automatic release at 1:30 pm if no manual release has happened."

The team stopped at four whys because the fourth answer was a setting they could change that day. Asking a fifth (why is it set up that way?) led to "the system was configured in 2019 and nobody reviewed it", which is true but adds nothing to the fix.

The Analysis Summary showed 4 whys and 2 actions. Download as Text produced root-cause-analysis-missed-dispatch-cutoff.txt, a plain report that went straight into the operations ticket. Download as Image saves a PNG of the summary card (counts and root cause), which is handy for a slide, but the full chain is only in the text and JSON exports. The page does not autosave, so the team also used Export JSON to keep an editable copy.

Where the 5 Whys breaks down

The method has real limits, and knowing them is what separates a useful analysis from a ritual.

It follows one chain. Many problems, especially outages and quality escapes, have several contributing causes. A deploy fails because a test was missing and the alert was misrouted and the on-call engineer had no runbook. A single chain picks one and ignores the rest. When a why has two honest answers, run a second chain or switch to a fishbone (Ishikawa) diagram, which lays out causes by category such as people, process, equipment, materials and environment.

It depends on who is asking. Two teams can run a 5 Whys on the same incident and reach different roots, because each follows the branch it knows best. Include someone from outside the team that owns the process.

It does not rank risks. The 5 Whys explains one problem after it happened. To look ahead at many possible failures and decide which to address first, use a Failure Mode and Effects Analysis, which scores each failure mode for severity, occurrence and detection.

Common mistakes

• Writing the problem as a solution. "We need more staff" is a conclusion, not a problem statement.
• Jumping to the answer you already had. If the root cause matches what the most senior person said before the session started, check that each step really has evidence.
• Blame. As soon as an answer names a person, people stop telling you what really happened. Keep it about the system.
• Actions without owners. An action item with no name and no date is a wish. Write "Ops lead: grant release rights by Friday."
• Never checking the fix. Put a date in the calendar to confirm the problem has not recurred. If it has, the chain stopped in the wrong place.

Where it fits with other tools

The 5 Whys pairs well with a few other structured methods. Before changing a process, a force field analysis helps you see what will support and resist the fix. When the root cause shows a capability that is missing, such as no backup for a key role, a gap analysis lays out the current and target state across the team. And for engineering incidents, the incident review tool gives the wider post-mortem a home.

Next time a problem repeats, open the 5 Whys tool, write the problem with a time and a number, and do not write the next why until you have seen the evidence for the last one. Most teams find a fixable cause by the third or fourth step.

Open the 5 Whys Root Cause Analysis