The Root Cause Fallacy: Hidden Causes

A tree needs many roots.

The system crashed at 3 AM. I ran Five Whys to find the root cause: it’s the database that ran out of memory. But that’s not a full story:

The database ran out of memory
AND monitoring failed to alert developers
AND the scaling policy didn’t work
AND the culprit query wasn’t optimised.

Many contributing causes led to failure.

The complexity of the situation needs good answers, not just simple ones.

Too much simplification is like saying: water causes drowning or gravity causes planes to crash. It’s somewhat true, but useless.

Two weeks ago, I published the article: Solve The Right Problem, presenting the Five Whys method, where by asking five “why?” we can get to the root cause. The article got great comments on Reddit, but one was perspective-shifting: Root cause is a fallacy. I’d presented Five Whys as a path to “the” root cause, but a complex failure rarely has just one cause. This is Part 2:

What is “why?”

Why doesn’t it work? Why is the server down?

The word “why” demands one answer, one reason, one thing to fix.

Simple explanations feel smart, elegant and right! But complex systems rarely fail for a single reason.

Brains are wired to look for causation, sometimes also where there is none (correlation vs causation).

CauseS

In “Solve the Right Problem”, I’ve pointed out, when describing Five Whys:

The main critique of this method focuses on depth, as for most of cases, just five iterations might not be enough. (...) The closer to the real issue we get, the better, as it allows us to find better solutions.

When running Five Whys, each “why?” has a single answer. Choosing just one option when many factors contribute is satisfying our brain’s need for simplicity, but it’s not helping us get to the truth.

Try inversion, by defining the problem in reverse:

Why is our product successful?
Why is our application working without problems?

There is no simple root cause of success. There are many contributing factors: luck, hard work, attention to detail, and a deep understanding of clients’ needs. It’s similar to failures: many things led to the undesired state.

Rate Contributions

How did each cause contribute?

3 AM database crash example breakdown:

• Database ran out of memory → high (breaking point)

• Missing monitoring → medium (would have caught it early)

• Broken scaling policy → high (could have prevented overflow)

• Suboptimal query → medium (accelerated memory consumption)

Running out of memory directly crashed the database, but other aspects shouldn’t be overlooked.

Five whys method can still help us uncover these root causes, but it’s worth looking at how each cause contributed to the failure. It’s a good starting point to think of improvements.

Summary

Next time you try to find “the root cause”. Pause and reflect on what combination of factors caused it, and don’t settle on just one. Rate their contribution, then fix based on impact.

Trees have many roots, as with success and failure. So look for multiple root causes.

Thanks for reading!
— Michał

---

Post Notes

Solve The Right Problem

Correlation Does Not Imply Causation

Discover Weekly — Shoutouts

Great articles which I’ve read recently:

• Give your engineers a kingdom by

  Anton Zaides

• The uncomfortable truth about job security in tech by

  Gilad Naor

• 6 Leadership Tactics That Feel Like Cheating (But Work Like Magic) by

  Gaurav Jain

Connect

LinkedIn | Substack DM | Mentoring | X | Bsky