5 Whys: Find the Root Cause, Not the Symptom
The 5 Whys technique finds a problem's root cause by repeatedly asking "Why?" to trace a cause-and-effect chain. Use it in post-mortems to understand system failures. The footgun is blaming people instead of asking why the process allowed the error.
WHY IT EXISTS: To solve problems permanently, you must fix the root cause, not just the immediate symptom. Many fixes address what's visible, but the 5 Whys provides a simple framework to dig deeper and find the systemic issue that allowed the problem to occur in the first place. This prevents the same class of problem from recurring.
THE MENTAL MODEL: Think of a problem as the top layer of soil. The first "Why?" digs up that layer. The answer is the next layer down. By asking "Why?" about each successive answer, you dig deeper until you hit bedrock—the foundational, root cause. It's an iterative technique to explore the cause-and-effect relationships behind an issue.
HOW IT WORKS: Start with a clear problem statement. Ask "Why did this happen?". Take the answer and ask "Why did that happen?". Repeat this process, directing each new "Why?" at the answer to the previous one. The "five" is a rule of thumb, not a strict requirement. You might find the root cause in three steps, or it might take seven. You stop when the answer points to a broken or missing process, not a person.
WHEN TO USE IT: The 5 Whys is most effective for simple to moderately complex problems where you need to understand a single chain of events. It's a staple of incident post-mortems, bug triage, and process improvement meetings. It's a great tool for teams to build a shared understanding of a failure without jumping to conclusions.
WHEN NOT TO USE IT: For complex problems with multiple interacting causes, the 5 Whys can be an oversimplification, leading you down a single, potentially misleading path. It's not a statistical tool; it doesn't prove causation, it just helps explore a logical sequence. If a problem has multiple, independent root causes, this technique may fail to uncover them all.
ONE CANONICAL EXAMPLE: Problem: The website is down. 1. Why? Because the database server is overloaded. 2. Why? Because one query is consuming all the CPU. 3. Why? Because it's performing a full table scan on a massive, unindexed table. 4. Why? Because a new feature was deployed that uses this query, and the table's index was missed during code review. 5. Why? Because our deployment checklist doesn't include a step for verifying database index coverage for new queries. The root cause is the flawed deployment process, and the fix is to update the checklist.
Read the original → en.wikipedia.org
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.