5 Whys: Find the Root Cause, Not Just the Symptom

WHY IT EXISTS Systems fail for complex reasons. Simply fixing the immediate symptom, like restarting a crashed service, doesn't prevent it from happening again. The 5 Whys technique was developed to provide a simple, structured way to dig deeper into the chain of events that led to a failure, allowing teams to fix the root cause permanently.

THE MENTAL MODEL Think of it like a doctor diagnosing a persistent cough. The cough is the symptom. Asking "why?" reveals lung inflammation. Asking "why?" again reveals an infection. A third "why?" might point to a weakened immune system. The real fix isn't cough syrup; it's addressing the underlying condition. The 5 Whys is a diagnostic tool for engineering problems that pushes past the initial "cough" to find the true systemic illness.

HOW IT WORKS Start with a clear problem statement. Ask "Why did this happen?" and record the answer. Then, use that answer as the basis for the next question: "Why did that happen?". Repeat this process, typically around five times, until you arrive at a fundamental process or system flaw. The number five is a guideline, not a strict rule; the goal is to reach a cause you can actually address, which is almost never "human error."

WHEN TO USE IT The 5 Whys is most effective for analyzing simple to moderately complex problems during incident postmortems or quality control reviews. It is a foundational tool for building a blameless culture, as it focuses inquiry on systems and processes rather than individuals. It requires no special software, only a collaborative mindset.

WHEN NOT TO USE IT For highly complex problems with multiple interacting causes, the 5 Whys can be too simplistic, as it tends to follow a single track of inquiry and may miss other contributing factors. It also fails if the team isn't committed to finding a true root cause and stops at a superficial answer.

ONE CANONICAL EXAMPLE Problem: The API is returning 500 errors. Why? The database connection pool was exhausted. Why? A new reporting service opened too many connections and didn't close them. Why? The service's connection logic didn't have a timeout or retry mechanism. Why? The standard database library used by the team doesn't include one by default. Why? There is no documented standard or pre-commit check for database connection handling. (This is the root cause—a process failure.)