Five Whys: From Symptom to Root Cause

Why it exists

Systems fail. Often, the immediate cause, like a crashed server, is just a symptom of a deeper problem, like unmonitored disk space. Fixing only the symptom guarantees the problem will return. The Five Whys is a structured method to find and fix the true root cause, preventing future failures.

The mental model

Think of it as a guided conversation to peel back the layers of an issue. You start with the surface-level problem and repeatedly ask "Why?" until you uncover a fundamental process or system flaw. The goal is always to find a broken process, not a person to blame. It's the engineering equivalent of a child's persistent "why," but aimed at systemic improvement.

How it works

Start with a clear problem statement, like "The payment gateway returned 500 errors for 15 minutes." Then, ask "Why did that happen?" Take the answer and ask "Why?" again. The number five is a guideline, not a rigid rule. You stop asking why when you identify a root cause that is a process failure you can actually fix. The final answer should not be a person's name but a process that can be improved.

When to use it

The technique is most effective for simple to moderately complex problems, especially in post-mortems or incident reviews. Use it when you suspect a recurring issue has a deeper cause than what's immediately obvious. It's a great tool for teams to build a shared understanding of a failure and agree on a high-leverage fix.

When not to use it

For highly complex failures with multiple, interacting causes, Five Whys can be too simplistic. It can lead you down a single, linear path of inquiry, missing other contributing factors. In these cases, a more formal method like a fault tree analysis is better. Also, avoid it in a culture of blame, as it will quickly devolve into a witch hunt.

One canonical example

The problem is the website was down. First, why? The database server crashed. Second, why? The database process ran out of memory. Third, why? A specific query consumed all available memory. Fourth, why? The query performed a full table scan on a massive, unindexed table. Fifth, why? The developer who wrote the code was unaware of the performance implications, and our deployment process lacks a mandatory review by a senior engineer to check for database performance issues. The root cause is a process failure: we need a better code review and pre-deployment checklist.