What
Five Whys (originating from Toyota) is a root cause analysis technique where you iterate "why?" until you reach a systemic, actionable root cause. Each answer becomes the subject of the next "why?" — for example: Bug in prod → why? → test missed it → why? → no test for this path → why? → developer didn't know the path existed → why? → no onboarding doc → why? → we never wrote it. Root cause: missing documentation process.
Fix the root, not the symptom — patching the bug without fixing the process guarantees recurrence. The number 5 is a heuristic, not a law. Stop when you reach something you can actually change. Watch for multiple branches — one "why" may have two answers, diagram both.
When to Use
Use Five Whys during incident post-mortems, debugging sessions, process improvement, and any time you need to find the underlying systemic cause of a problem rather than treating surface symptoms.
How
- State the problem clearly.
- Ask "why did this happen?" and write down the answer.
- For each answer, ask "why?" again.
- Repeat until you reach a systemic cause you can actually change.
- Document the chain and implement corrective actions at the root level, not the symptom level.
- Beware stopping at the first visible cause ("it was a bug") and calling it done.