The Difference Between Root Cause and First Explanation
Most investigations stop at the first plausible answer. The difference between teams that keep fixing the same problems and teams that solve them permanently is how many times they ask 'why' — and whether they reach structural causes or stop at symptoms.
Every operation investigates failures. Few fix them permanently.
The investigation starts well. Something went wrong — a missed deadline, a customer complaint, a quality escape, a process breakdown. A team convenes. Questions are asked. An explanation emerges. The team moves to action. The case is closed.
Three months later, the same type of failure happens again. Different details, same pattern. The previous fix addressed the symptom, not the cause.
This is the gap between root cause and first explanation. Most investigations reach an answer that explains what happened. Fewer reach an answer that explains why it was possible — and what to change so it cannot happen again.
The test of a root cause
If fixing it would prevent recurrence, it is a root cause. If the same type of failure can still occur through a different path, you found a symptom or a proximate trigger — not the root.
Why investigations stop too early
The pattern is predictable: teams find a plausible explanation and stop.
Research confirms this tendency. A study of 350 decision-making processes at medium to large companies found that more than half failed to achieve desired results, often because perceived time pressure caused people to pay insufficient attention to examining problems from all angles and exploring their complexities . Teams jump to solving before they have fully understood what they are solving.
This is not laziness. It is human. When a plausible explanation appears, the urge to move to action is strong. The problem feels understood. The team wants to fix it and move on. But the first explanation that makes sense is rarely the deepest one.
Plausible is not the same as root
The first explanation usually describes what happened. The root cause describes what allowed it to happen. One explains the failure; the other explains why the failure was waiting to occur.
Three levels of investigation depth
Effective investigations move through layers. Each layer answers a different question, and stopping at any layer produces a different quality of fix.
Three Levels of Investigation
Click each level to explore what you find there
The symptom is what you see first: the error, the complaint, the missed deadline, the defect. It is the manifestation of a problem, not the problem itself. Most investigations start here — but too many also stop here.
- •What went wrong?
- •When did it happen?
- •Who noticed it?
- •What was the immediate impact?
A description of the failure event itself.
Fixes address the visible issue but leave the underlying cause intact. The problem recurs — often in a different form.
The proximate cause is the direct trigger of the symptom: the action, omission, or condition that immediately preceded the failure. It answers 'why did this specific thing happen?' — but not why that trigger was possible in the first place.
- •What action or inaction caused this?
- •What condition allowed the failure?
- •Who was involved and what did they do?
- •What should have happened instead?
The immediate reason the failure occurred — often a human error, equipment fault, or missed step.
Fixes address the trigger but not what made the trigger possible. Similar failures occur through different triggers.
The structural cause is the systemic condition that made the proximate cause possible: the missing process, the unclear ownership, the inadequate training, the design flaw, the incentive misalignment. It answers 'why was this failure waiting to happen?'
- •What allowed the trigger to exist?
- •Why didn't our systems catch this earlier?
- •What process, design, or structure made this possible?
- •Where else might the same gap exist?
A systemic gap that, if addressed, prevents not just this failure but similar ones.
Fixes create lasting change. The problem does not recur because the conditions that allowed it no longer exist.
Tap the progress bar or cards above to navigate between investigation levels
The Harvard Business Review describes this as the "iceberg model" — a framework that guides teams through layers of causation: surface-level events, the behavioural patterns that drive them, underlying systematic structures, and established mental models . Most investigations stop at the surface. The durable fixes come from reaching the structure.
The human error trap
Human error is where most investigations stall.
Someone made a mistake. The investigation finds the mistake, assigns responsibility, and moves to corrective action: training, a reminder, a process update, perhaps a consequence. The team feels they have found the cause. Case closed.
But "human error" is almost never a root cause. It is a symptom. The structural questions remain unanswered:
- What allowed the error to be possible?
- What should have caught it before impact?
- Why was the system designed so that this error could cause this failure?
- Where else might the same gap exist?
The rule for human error
When you find a human error, you have found where the failure occurred — not why it was possible. The investigation continues by asking what allowed the error to happen and what failed to catch it before it mattered.
The questioning discipline
Reaching structural causes requires a simple discipline: keep asking why.
The "five whys" technique is well known but often misapplied. The goal is not to ask "why" exactly five times. The goal is to keep asking until you reach a cause that is within your control to change, that would have prevented the failure, and that explains why this failure was waiting to happen.
A practical test: if your answer is about a person's action or decision, ask what allowed that action to produce this outcome. If your answer is about a missing step, ask why the step was missing — or why its absence was not detected. If your answer is about a process gap, ask how the gap came to exist and why it persisted.
Stop when you reach something you can change that would make this category of failure less likely — not just this specific instance.
Over 50%
of decision processes in one study failed to achieve desired results — often because teams examined problems insufficiently before solving
When teams stop at first explanations, problems recur.
Evidence standards that prevent shallow answers
Reaching structural causes also requires evidence discipline. A root cause is not a hypothesis — it is a verified explanation.
Good investigation practice:
Test the cause-effect chain. For each link in your reasoning, ask: does this cause explain this effect? If not, the chain is broken.
Check for necessity. Ask: if this cause had not been present, would the failure have occurred? If the answer is yes, you have not found a necessary cause.
Check for sufficiency. Ask: if only this cause were present, would it have been enough to produce the failure? If not, there are contributing factors you have not identified.
Verify, do not assume. Confirm each step with evidence — data, logs, observations, interviews — not just logical inference.
The verification test
Before declaring a root cause, ask: "If we had fixed this before the failure, would the failure have been prevented?" If you cannot answer yes with confidence, keep investigating.
A practical diagnostic
How deep do your investigations typically go? The assessment below helps identify where your team's investigation habits produce durable fixes — and where they may be stopping too early.
Investigation Depth Assessment
Question 1 of 5
When an incident occurs, how many times does your team typically ask "why" before declaring a root cause?
Building the habit
Reaching structural causes is a discipline, not a talent. It can be built.
Start with one additional why. When you reach an explanation that feels sufficient, ask "why was this possible?" one more time. That single habit often reveals the layer most investigations miss.
Make human error a trigger, not a conclusion. When the investigation finds a person's mistake, treat it as a signal to investigate further — not as the end of the investigation.
Track recurrence. If the same category of problem returns within 12 months, the previous investigation did not reach root cause. Use recurrence as feedback on investigation quality.
Separate understanding from action. Resist the pressure to move to fixes before the investigation is complete. The cost of a thorough investigation is small compared to the cost of fixing the same problem repeatedly.
The compounding benefit
Structural fixes prevent not just this failure but similar ones. Over time, teams that reach root causes have fewer recurring problems, less rework, and more capacity for improvement instead of firefighting.
Final thoughts
The difference between teams that solve problems permanently and teams that keep fixing the same issues is not resources or capability. It is investigation depth.
Root cause investigations that work:
- Keep asking why until they reach structural factors
- Treat human error as a starting point, not an endpoint
- Verify causes with evidence, not just logic
- Test whether the proposed cause would have prevented recurrence
- Track whether fixes actually prevent the problem category
The discipline is simple. The habit is what matters.
How deep do your investigations typically go? When you find a human error, do you stop — or do you ask what made the error possible?
Sources
- Harvard Business Review. To Solve a Tough Problem, Reframe It. January–February 2024.Julia Binder and Michael D. Watkins; includes reference to Paul Nutt's study of 350 decision-making processes at medium to large companies, which found more than half failed to achieve desired results because teams devoted too little effort to examining problems before solving them.View source
- Harvard Business Review. To Solve a Tough Problem, Reframe It. January–February 2024.The iceberg model guides teams through layers of causation: surface-level events, the behavioural patterns that drive them, underlying systematic structures, and established mental models.View source
Ready to improve your service operations?
We design and operate integrated operating models for organisations ready to compound efficiency. Let's discuss yours.