The Myth of the One True Root Cause

Ask most investigation teams to name the root cause of an event, and they'll give you one. A single line. A single factor. Something you could point to and say, "that's what caused this."

It's a satisfying answer. It's also, in most cases involving real people doing real work, not an accurate one.

Why We Reach for a Single Cause

Looking for one root cause isn't a character flaw. It's how a lot of investigation methodology was built. Find the cause, fix the cause, close the record. It works well for simple mechanical failures: a seal degrades, a part wears out, a single component fails and the chain of events is short and linear.

But most events involving people, procedures, and organizational conditions aren't that simple. They're the product of several factors that each played a role, none of which would have caused the event on its own.

Sidney Dekker put this well in The Field Guide to Understanding Human Error: pushing a well-defended system past its limits takes a large number of contributing factors, each necessary and only jointly sufficient. There's no single cause behind that kind of failure, and no single cause behind avoiding it either.

Necessary, But Not Sufficient

Here's the distinction that changes how an investigation should be run: a factor can be necessary to an event without being sufficient to cause it.

Take a familiar scenario. An operator misses a step during a changeover. On its own, that's a near-miss at worst; there's usually a check built in to catch it. But that day, the check was also skipped because the second operator was pulled to help on another line. On its own, that's also not enough; the automated alarm should have flagged the deviation. But the alarm threshold had been widened months earlier after a run of false positives, so it didn't trigger until the batch was already out of range.

None of those three factors alone caused the event. Each one was necessary. Together, they were sufficient. Take any single one away and the outcome likely changes. Remove the alarm threshold change and the deviation gets caught. Remove the staffing pull and the second check happens. Remove neither and the event might still have occurred, just differently.

What "Root Cause" Language Costs You

When an investigation concludes with a single root cause, it usually means the team found the factor that was easiest to isolate, not the full set of conditions that had to align for the event to happen. Everything else that contributed gets left out of the report, which means it gets left out of the corrective action plan too.

That's how you end up fixing the alarm threshold and calling it done, while the staffing pattern that pulled a second operator away from a critical check stays exactly as it was. The next event won't look identical. It'll just find a different combination of the same underlying conditions.

Mapping Instead of Naming

The alternative to naming a root cause is mapping the conditions that combined to produce the event. This isn't more complicated for the sake of complexity. It's complicated because the event actually was.

A useful test while investigating: for each factor you've identified, ask whether removing it, and only it, would have prevented the event or changed its outcome. If the answer is yes, it belongs in the finding. If several factors pass that test, you don't have several suspects competing for the title of root cause. You have several conditions that were each doing real work, and each one deserves its own corrective action.

Multiple Causes Means Multiple Fixes

This has a direct, practical consequence for corrective action planning. If three conditions were each necessary and only jointly sufficient, a single corrective action addressing one of them won't prevent recurrence. It'll just narrow the odds slightly, until the same conditions line up again in a slightly different order.

Real prevention means addressing each factor that was doing real work: the check, the staffing pattern, the alarm threshold, whatever the specific set turns out to be. It's more corrective actions to write and track. It's also the only version that reflects what actually happened, and how it happened.

There's a practical upside here too, one that gets missed when a team is locked onto a single root cause. If you've identified three necessary factors instead of one, you have three points of leverage instead of one. Say the staffing gap is the hardest fix. It touches headcount, scheduling, maybe a union agreement, and it's not getting solved this quarter. Under a single-root-cause model, that's where the investigation stalls; the "real" fix is out of reach, so the record sits open or closes with something weak. Under a multiple-factors model, the team can still act. Tighten the alarm threshold back down. Add a redundant check that doesn't depend on a second operator being available. Neither one solves the staffing problem, but together they meaningfully reduce the odds of recurrence while the harder fix works its way through the queue.

Naming a single root cause can back a team into an all-or-nothing position: fix the one thing, or the investigation didn't accomplish anything. Naming the full set of contributing factors gives the team options, and options are what let an investigation produce real risk reduction now instead of waiting on the one fix that may never be practical.

Let Go of the One True Cause

There's a reason "root cause" as a phrase persists even when it doesn't match reality: it's simpler to write, simpler to present, and simpler to close. But simple isn't the goal. Accurate is.

The next time an investigation converges on a single cause, it's worth pausing to ask what else had to be true for that cause to produce this outcome. Usually, there's more than one answer. Finding all of them is the difference between a report that reads well and a fix that actually holds.

--

Want the full framework for mapping how multiple factors combine into an event? Beyond Human Error is open now. Start the course.