five-whys

name: five-whys description: Uncover root causes by iteratively asking why a problem occurred, moving from symptoms to underlying system failures

Five Whys

Overview

Developed by Sakichi Toyoda and Taiichi Ohno at Toyota, the Five Whys is a root cause analysis technique that asks "why?" five times (or until reaching root cause) to move from problem symptoms to underlying system failures. Each answer forms the basis of the next "why?" The method reveals that surface problems (machine stopped) often trace to systemic issues (no maintenance strainer).

When to Use

Recurring problems that keep coming back despite fixes
Symptoms being treated instead of root causes
Need to move from blame to systemic understanding
Team jumping to solutions before understanding problem
Expensive failures requiring investigation
Simple problems where heavy analysis frameworks are overkill

The Process

Step 1: Define the Problem Clearly

Write a specific, observable problem statement. Avoid vague language. Bad: "Quality is poor." Good: "Product X failed QA inspection 3 times this week due to misaligned components."

Example: "The website went down for 2 hours on Tuesday afternoon, affecting 10,000 users."

Step 2: Assemble People Close to the Work

Gather those directly involved in the process—they have the detailed knowledge. Don't rely solely on management perspectives removed from day-to-day reality.

Example: Include the on-call engineer who responded, the developer who deployed, and the QA tester who reviewed the change.

Step 3: Ask "Why?" and Document Answers

Ask why the problem occurred. Each answer becomes the input for the next "why?" Don't accept vague answers—push for specific, verifiable causes.

Example:

Problem: Website went down
Why? Database connection pool exhausted
Why? Connection leak in new user authentication code
Why? Code review didn't catch resource management bug
Why? Code reviewers lack training on connection pooling patterns
Why? No onboarding process for distributed systems concepts

Step 4: Stop at the Root Cause

Continue asking until reaching a root cause you can act on. Signs you've hit root: answer is a process gap, missing system, or design flaw—not a person or one-time event.

Example: Root cause is "No onboarding process for distributed systems concepts," not "Developer made a mistake" (blame) or "Connection leaked" (symptom).

Step 5: Implement System-Level Countermeasures

Fix the root cause, not the symptom. Verify the fix prevents recurrence, not just the specific instance.

Example: Countermeasure: Create distributed systems onboarding with connection pooling best practices, add automated tests for resource leaks, update code review checklist. Result: No further connection pool failures.

Classic Taiichi Ohno Example

Problem: Machine stopped working

Why? Overload, fuse blew
Why? Bearing not sufficiently lubricated
Why? Lubrication pump not pumping sufficiently
Why? Pump shaft worn and rattling
Why? No strainer attached, metal scraps got in

Root Cause: Missing strainer (design/process flaw) Countermeasure: Install strainer on all lubrication pumps

Example Application

Situation: E-commerce company experiences spike in customer service complaints about late deliveries.

Application:

Why are deliveries late? Warehouse picking delays
Why are picks delayed? Inventory locations incorrect in system
Why are locations incorrect? Returns not scanned to proper shelf
Why aren't returns scanned? Scanners frequently dead or missing
Why are scanners dead? No charging station in returns area

Root Cause: Missing infrastructure (charging station), not "lazy workers"

Countermeasure: Install 5 charging stations in returns area, add scanner battery checks to opening checklist, train returns team on scan importance

Outcome: Late deliveries drop 60%, complaints fall 75%, warehouse productivity increases 20%.

Anti-Patterns

❌ Stopping at blame ("Because Bob made a mistake")—root causes are systemic
❌ Accepting vague answers ("Bad communication")—push for specifics
❌ Treating 5 as magic number—stop when you hit root, might be 3 or 7
❌ Using technique for complex problems with multiple causes (use fishbone instead)
❌ Implementing fixes for symptoms (earlier whys) instead of root cause
❌ Conducting Five Whys alone—need diverse perspectives

root-cause-analysis
fishbone-diagram
systems-thinking
feedback-loops