Foundation · 11 min
The difference between what hurts and what caused it
After this you can
- state the difference between a symptom and a root cause for a problem in my own work.
Assumes you have done Work is a process, and somebody is waiting at the end of it.
The problem
A distribution centre had a pallet fall from a racking bay. The investigation concluded: "operator did not check the load was square before lifting". The fix was a toolbox talk and a signed acknowledgement from every driver. Eleven weeks later another pallet fell. The second investigation found that the shrink-wrap machine had been running two wraps short since a settings change in March, so every pallet leaving the wrapping station was under-secured. Both investigations were accurate. Only one of them found something you could change.
The idea
A symptom is what you notice. A cause is what produced it. They are almost never the same thing, and the whole discipline of improvement rests on being able to tell them apart.
This sounds obvious and is genuinely difficult, for three reasons.
Symptoms are what get reported. Nobody files a ticket saying "the shrink-wrap settings changed in March". They report a fallen pallet, a late delivery, a wrong invoice. The reporting system is made of symptoms, so the improvement backlog fills up with them.
Symptoms are urgent and causes are not. The pallet has to be cleared up now. The wrapping machine has been wrong since March and will still be wrong tomorrow. Urgency reliably wins, which is why organisations can spend years treating the same symptom.
A symptom can be re-described until it sounds like a cause. "The pallet fell because it was not secure" says nothing at all — it restates the fact in causal grammar. This is the most common failure, and it is invisible unless you test for it.
The test
Two questions, and a real cause has to pass both.
1. Does it point at something you can change? "Operator did not check the load" points at a person and offers you a talking-to. "The wrapping machine applies two wraps fewer than the standard" points at a machine setting and offers you a change. If your candidate cause is a person or an attitude, you have almost certainly stopped early — people work inside a system, and the system decides what is easy for them to do.
2. Would removing it prevent recurrence? Ask the question backwards: if this had not been true, would the problem still have happened? Reverse the wrapping change and the pallets are secure. Deliver the toolbox talk and the pallets are still under-wrapped — the driver's checking was never what was missing.
The backwards test is the useful half. It is easy to build a chain of statements that each sound reasonable going forwards and collapse instantly when you read them in reverse.
Symptoms are still worth measuring
None of this makes symptoms useless. They are how you know a problem exists, how you size it, and how you tell whether a fix worked. What they cannot do is tell you what to change.
The order matters: measure the symptom, find the cause, change the cause, watch the symptom. A team that skips to changing things is usually changing symptoms, and the symptom always comes back — often with a new toolbox talk attached.
Worked example
Take a problem small enough to see all of at once: the office coffee machine keeps stopping mid-cycle.
| Statement | Symptom or cause? | Why |
|---|---|---|
| The machine stops mid-cycle | Symptom | It is what you notice. It is also the thing to measure. |
| It stops because it fails | Neither | Restates the symptom in causal grammar. Says nothing. |
| The overload cut-out trips | Symptom | Closer to the machine, still something you observe rather than something you can change. |
| Nobody cleans the machine properly | Blame | Points at people. Fails test 1 — there is nothing here to change except an attitude. |
| There is no filter on the pump intake, so grounds reach the bearing | Cause | Passes both tests: it points at a part you can fit, and if it were not true the bearing would not wear. |
Look at what happened between rows four and five. Both describe the same situation. The fourth blames a person for not doing something; the fifth describes a part that was never fitted. Only the fifth suggests anything you could actually do — and it costs a few pounds.
Now apply the backwards test to the blame version. If somebody had cleaned it more often, would the problem have happened? Later, perhaps. But grounds still reach an unfiltered intake, the bearing still wears, and the cut-out still trips. "Nobody cleans it properly" is a description of how fast the symptom arrives, not of what produces it.
And notice what the measurement is for. You still want the count of mid-cycle stops per week. Not to find the cause — it will never tell you that — but to know how big the problem is and whether the change worked. If stops per week does not fall after you fit the filter, your cause was wrong, and finding that out is exactly what the measure is for.
Dataset: ds-coffee-machine — the same data loads in the tool below, so you can reproduce every figure here yourself.
Your turn
The 5 Whys tool applies the backwards test at every link. It will not let you add the next why until you have confirmed that the reversal reads sensibly.
- Work the coffee machine chain through. Notice the tool asking you to read each link backwards before it accepts it — that is the second test, applied mechanically.
- Try ending a chain on "because the operator forgot". The tool accepts it — it cannot know whether you are right — but it raises a notice against that link and asks the follow-up question: what about the work made forgetting easy? Answering that, rather than stopping, is the whole of test 1.
- Try a chain from your own work. Stop when a link fails the backwards test — that is the point where your understanding actually ends, and it is usually earlier than expected.
Five is not a magic number. Stop when you reach something you can change and whose removal would prevent recurrence. Sometimes that is three whys; sometimes seven.
5 Whys Chain
practiceWhen to stop
Not at five. Five is a rule of thumb — some chains end at three, some need seven. Stop when the cause is something you can change, and changing it would stop the effect.
A good chain usually ends at a design decision, not at a person. If yours ends at someone’s behaviour, it stopped one why early.
Source: Ohno (1988), Toyota Production System — “by repeating why five times, the nature of the problem as well as its solution becomes clear.”
Check yourself
No hints. Wrong answers are explained, not softened.
An investigation into a late shipment concludes: 'the shipment was late because it was not despatched on time'. What is wrong with this?
Two candidate causes for repeated data-entry errors: (A) 'staff are rushing', (B) 'the form's date field accepts any text and is validated only at month end'. Which is workable, and what makes it so?
After fixing a cause, the symptom measure does not improve. What does this tell you?
Worth remembering
What are the two tests a candidate root cause must pass?
It points at something you can change, and removing it would prevent recurrence. Read the chain backwards to test the second one.
Why do improvement backlogs fill up with symptoms?
Symptoms are what get reported — nobody files a ticket about a settings change. Symptoms are also urgent, and causes are not, so urgency wins.
If a candidate cause names a person or an attitude, what does that indicate?
That the chain stopped early. People work inside a system that decides what is easy to do; the changeable thing is nearly always one link further on.
Can you do this now?
Rate yourself honestly. We compare your rating with how you actually answered — the gap is more useful than either number alone.
I can state the difference between a symptom and a root cause for a problem in my own work.
Your rating is recorded alongside your drill results. Neither alone marks the competency as met.