What is the five whys?
Engineering culture and software practice
The five whys is a root-cause technique from the Toyota Production System. When something goes wrong you ask why, then ask why of the answer, and keep going, about five times, until you reach a cause you can fix rather than a symptom you can patch. Taiichi Ohno formalised it at Toyota and gave the classic example of a machine that stopped. It is simple, popular and easy to misuse.
What this means
The five whys is the most basic root-cause tool that actually works, which is exactly why it gets misused. You state the problem, ask why it happened, then treat that answer as a new problem and ask why again, and keep going until you reach something you can change. The point is to stop treating symptoms and start removing causes.
The number five is a rough guide, not a rule. Sometimes three whys are enough; sometimes you need eight. You stop when you reach a cause that, if fixed, would genuinely prevent the problem returning, and not before.
It has a name because most investigations stop far too early, at the first plausible answer, and then keep solving the same problem over and over. The discipline of asking again is the whole value.
Why it matters
Small organisations rarely have time for elaborate investigation, and the five whys fits that reality. You can run it in twenty minutes around a table for almost any recurring problem: missed invoices, a failed AI pilot, a data leak, a delivery that went to the wrong address. It costs nothing but attention.
Its value is that it moves a team from "who forgot?" to "what in our process let this happen?" A recurring problem is almost never solved by telling someone to be more careful; it is solved by changing the step that made the mistake easy. The five whys pushes past the comfortable first answer to the change worth making.
Its danger is equal and opposite. Because it is so easy, teams treat its first tidy chain as the truth, stop at "because someone forgot", and miss the several other causes that were also in play. Used carelessly it produces false confidence, which is worse than no analysis at all.
How it works
Where the term came from
The technique is rooted in the Toyota Production System. It is often attributed to Sakichi Toyoda, founder of the wider Toyoda enterprise, and it was formalised inside Toyota by Taiichi Ohno, the architect of the production system. Ohno set it out in his book Toyota Production System: Beyond Large-Scale Production, first published in Japan in 1978 and issued in English by Productivity Press in 1988. His canonical example, on page 17, walks through a machine that stopped: why did the machine stop, because an overload blew the fuse; why the overload, because the bearing was not sufficiently lubricated; and so on down to a missing strainer that let metal scraps in. Without repeatedly asking why, Ohno noted, managers would simply replace the fuse and the failure would recur.
From Toyota the technique spread through lean manufacturing and Six Sigma, and then into software through Eric Ries's The Lean Startup (2011) and the incident post-mortem. Ohno himself stressed investigating the process, not the people, because in his view it is the process, not the person, that should carry controls to prevent human error.
How to run it well
Good practice is to anchor each step in a fact, not an opinion, and to gather a little evidence before accepting an answer. Rather than following a single line, allow more than one branch: a problem often has several contributing causes, and forcing them into one chain hides the others. Stop when you reach a cause you can actually change, and write the chain down so the reasoning is visible and can be challenged. If your answer points at an individual's mistake, keep going: why did no training, checklist or verification step catch it?
Where it misleads, and the alternatives
The technique has serious critics. Alan Card's 2017 paper in BMJ Quality and Safety argued that its popularity rests on pedigree and simplicity rather than evidence, and that it gives only a blinkered view of complex causal pathways, offering "an answer that is clear, simple and wrong". In software, John Allspaw's 2014 essay "The Infinite Hows" argued that asking "why" too easily slides into asking "who", and that asking "how" surfaces the conditions that made each step possible, drawing out multiple and diverse perspectives instead of one neat story. Practitioners often blend the five whys with a fishbone (Ishikawa) diagram, which lays out several categories of cause at once, or run several parallel chains rather than one.
The human-error trap and the tie to culture
The most common failure is to stop at "because someone made a mistake". That is a symptom, not a cause, and treating it as the answer both misses the systemic fix and quietly blames a person. This is where the technique meets just culture: the questioning must be safe, or people will steer the chain away from the truth. It also meets normalisation of deviance, because a well-run five whys often surfaces a shortcut the organisation had quietly come to accept.
Examples
A charity keeps missing supplier invoices. Why: they were not paid on time. Why: they were not entered into the system. Why: they arrived by email to one person who was on leave. Why: there is no shared inbox or cover. Why: nobody was made responsible for the process when the finance volunteer changed. The fixable cause is ownership and a shared inbox, not the person on leave. This is an illustrative scenario.
A software team of eight sees a failed AI pilot. Why: users stopped using the assistant. Why: its answers were often wrong for their cases. Why: it was given generic prompts and no examples. Why: nobody owned prompt quality. Why: the pilot was launched to hit a date, with no time set aside for tuning. Two branches appear, ownership and schedule pressure, and both deserve action; forcing a single chain would have hidden one of them.
A council department suffers a small data leak when a spreadsheet is emailed to the wrong recipient. Why: autocomplete filled the wrong address. Why: two contacts had similar names and there was no confirmation step. Why: the sending process had no check for external recipients. The fix is a warning on external sends, not a reprimand for the officer who clicked send.
Common misunderstandings
The first misconception is that you must ask exactly five times. Five is a guideline; you stop when you reach a cause you can act on, whether that is after three whys or eight.
The second is that the five whys is a full investigation ritual. It is not. It is a technique that may be used inside a blameless post-mortem, unlike the post-mortem itself, which is the wider review meeting with its own agenda, timeline and follow-up. The five whys is one tool on that table, not the table.
The third is that "someone forgot" is a valid root cause. Rather, human error is a symptom; a good chain keeps asking why the system allowed the error to matter.
The fourth is that a problem has a single root cause. Real incidents usually have several contributing causes, and a single linear chain can dangerously oversimplify them.
The fifth is that it suits every problem. For genuinely complex, tightly coupled systems, critics argue the technique is too shallow, and methods such as fishbone diagrams or the "how" question serve better.
Risks and boundaries
The technique's weaknesses are well documented. Its single linear chain invites confirmation bias: the facilitator's first guess shapes every subsequent answer, and the group converges on one tidy story that feels satisfying but may be wrong. Because it is quick and cheap, teams over-trust its findings and skip the evidence-gathering that would test them.
The live debate is about where it belongs at all. Card and others argue it should not be relied on for serious root-cause analysis in complex settings, keeping it as a teaching aid at most. Allspaw's "infinite hows" makes a related case for the software world. The pragmatic position is that the five whys is a useful first pass for simpler, recurring problems in a small organisation, provided it is run with multiple branches, real evidence and a stop rule, and provided nobody mistakes its neat chain for the whole truth.
What to do next
Use it for recurring, everyday problems, and keep it short: gather the people who saw the problem, write the chain on a shared surface, and insist on a fact at each step.
Ban "someone forgot" as a stopping point. Whenever an answer names a person, require the next why to ask what in the process let that error through.
Allow more than one branch. If two or three causes appear, follow each, and expect to leave with more than one change worth making.
Know when to reach for more. For a serious or complex incident, treat the five whys as a starting sketch and bring in a fuller method such as a fishbone diagram or a structured post-mortem, and make sure the conversation is safe enough that people tell the truth.
FAQs
Do I have to ask why exactly five times?
No. Five is a rough guide. Stop when you reach a cause you can change, whether that takes three whys or eight.
Where did the five whys come from?
The Toyota Production System. Taiichi Ohno formalised it and published the classic machine example in his 1988 book.
Can I use it for non-technical problems?
Yes. It works for missed invoices, process failures and many everyday recurring problems, not just machines or code.
Why is "someone forgot" a bad answer?
It is a symptom, not a cause. A good chain keeps asking why the system let that lapse cause harm.
What are the main criticisms?
That it forces one linear chain, invites confirmation bias, and oversimplifies complex incidents. Alan Card and John Allspaw are notable critics.
What can I use instead or alongside it?
Fishbone diagrams, multiple parallel chains, or asking "how" rather than "why" to surface conditions and several perspectives.
How does it relate to just culture?
The questioning must be safe, or people steer it away from the truth. Just culture keeps the analysis honest.