5 Whys — Root Cause Analysis

The 5 Whys is a simple but powerful root cause analysis technique where you ask "Why?" repeatedly (typically 5 times) until you reach the fundamental cause of a problem. Developed by Sakichi Toyoda and central to the Toyota Production System, it prevents the common failure of fixing symptoms rather than causes.

One-page infographic

Visual summary of 5 Whys — Root Cause Analysis · Free PDF

Download PDF

Why companies use it

·Simple enough that anyone can use it, without statistical training
·Frequently reveals systemic, management-level root causes that teams would not initially consider
·Fast — a proper 5 Whys can be completed in minutes for simple problems
·Used in 8D, CAPA, kaizen events, and incident investigations across all industries

What hiring managers look for

·How well a candidate uses 5 Whys in an interview reveals their problem-solving depth and comfort with root cause thinking
·They want engineers who instinctively ask "why" rather than reaching for the nearest fix
·Candidates who understand that 5 Whys often reveals process or system failures (not just human error) show maturity
·Using 5 Whys alongside fishbone and data analysis (not in isolation) shows proper tool selection

Typical interview questions

Walk me through a real example of a problem you solved using 5 Whys.

When is 5 Whys insufficient and you need a more rigorous approach like DMAIC?

How do you prevent 5 Whys from becoming blame-focused ("the operator did it wrong")?

What happens if different team members follow different "Why?" paths from the same starting problem?

What is the risk of applying 5 Whys to a complex problem with multiple contributing causes?

Common mistakes

·Stopping at a symptom — "Why did the machine fail? Because the bearing wore out" is not a root cause; keep asking why
·Blaming individuals — "Why did it happen? Because John forgot to check it" is a symptom of a system without mistake-proofing, not a root cause
·Assuming there is always one root cause — complex problems often have multiple parallel causes requiring a fishbone first
·Not validating the root cause with data before implementing a solution
·Using 5 Whys for problems that require statistical analysis — it is a qualitative tool, not a substitute for data

Real engineering example

Problem: a CNC machine produced 12 out-of-tolerance parts in one shift. Why? The tool was worn. Why was the tool worn? It exceeded its replacement interval. Why did it exceed the interval? The PM system did not track tool life for this machine. Why? The machine was added to the floor after the PM system was configured and was never added. Why? There was no onboarding checklist for new equipment additions. Root cause: no process for integrating new equipment into the maintenance management system. Fix: created a new equipment commissioning checklist.

Topics covered

5 Whysroot causeproblem solvingToyotaleanquality

Related interview guides

Manufacturing Engineer →Continuous Improvement Engineer →