How to run it
Write the problem as something observable. 'The build broke' is workable; 'quality is slipping' is not, because there is no single event to trace. If you cannot point at a specific occurrence, you are not ready for a Five Whys yet — you need data first.
Then answer each why with a cause you could show someone, not a motive you are guessing at. 'Because the config was wrong' is a cause. 'Because nobody cared' is a verdict, and the chain dies there — no one asks why of an accusation. When you notice an answer sliding toward character, rewrite it as a fact about the system: what was in place that allowed the wrong config to ship?
Stop when the next why stops teaching you anything, or when you reach something outside your control. Five is a habit that keeps people from stopping at two, not a quota — chains of three and of seven are both perfectly normal. What matters is that the last link names something you can actually change.
The countermeasure is the point
An analysis that ends at 'the root cause was insufficient training' has not finished. The last step is a countermeasure: a specific change to the system, with a way to tell whether it worked. Toyota's framing was deliberate about the word — a countermeasure is a response you expect to evaluate and revise, not a permanent solution you declare and forget.
A good test: if the same trigger happened again next month, would this change have stopped it, or would it depend on someone remembering to be careful? Countermeasures that rely on vigilance tend to decay. Ones that change a default, add a check the process cannot skip, or remove a step entirely tend to hold.
Where the technique falls down
The best-known criticism is that it produces a single chain. Real incidents usually have several contributing causes that only matter in combination, and a linear five-link chain quietly discards the others — which is why the answer you get can depend heavily on who happened to be in the room and which thread they picked. If your problem feels like it has several parents, map it wide with a fishbone first and then run the Five Whys down the branch you have evidence for.
The second failure is confirmation. It is easy to steer the chain toward the answer you already wanted, because each link only has to sound plausible to the people writing it. Ask at each step what evidence you have for that link, and mark the ones that are assumptions — a chain with two unverified links is a hypothesis, not a finding.
The third is stopping too early, usually at the first answer that assigns responsibility to a person. That answer feels like an ending because it is socially uncomfortable to push past it. Push past it anyway.
When to use it
It fits small, recent, specific problems best: a defect that reached a customer, a deployment that failed, a handoff that dropped something, a recurring irritation nobody has ever traced. It is quick enough to run in the meeting where the problem came up, which is most of its value — analysis that needs to be scheduled usually does not happen.
It fits poorly on large multi-cause failures, on anything statistical, and on problems where the disagreement is about goals rather than causes. Those need wider tools; a SWOT or a fishbone is a better opening move.