Here's the most famous example of root cause analysis in the Lean world, from Taiichi Ohno's book on the Toyota Production System. You've seen it in training decks, conference talks, blog posts. I've shared it myself plenty of times. See if anything jumps out.
- Why did the machine stop? There was an overload and the fuse blew.
- Why was there an overload? The bearing was not sufficiently lubricated.
- Why was it not lubricated sufficiently? The lubrication pump was not pumping sufficiently.
- Why was it not pumping sufficiently? The shaft of the pump was worn and rattling.
- Why was the shaft worn out? There was no strainer attached and metal scrap got in.
Five whys. Clean, linear, satisfying. The strainer was missing, metal got in, the shaft wore out, the pump failed, the bearing seized, the fuse blew, the machine stopped. Case closed.
Except — count again.
How Many Whys Is That, Actually?
Look at the first question and answer. “Why did the machine stop?” gets the answer: there was an overload and the fuse blew. But that's two things packed together. The fuse blew because there was an overload. The overload happened because of insufficient lubrication. If you unpack it, the chain really starts:
- Why did the machine stop? The fuse blew.
- Why did the fuse blow? There was an overload.
- Why was there an overload? The bearing was not sufficiently lubricated.
And the same thing happens at the other end. “Why was the shaft worn out? There was no strainer attached and metal scrap got in.” That's also two things:
- Why was the shaft worn out? Metal scrap got in.
- Why did metal scrap get in? There was no strainer attached.
Ohno compressed steps at both ends of the chain. Unpack the whole thing honestly and you're looking at seven whys, not five. The most cited “5 Whys” example in all of Lean management isn't actually five whys.
This is a small thing, but I think it's a telling one. The number five was partly an artifact of how Ohno chose to phrase his answers, not a reflection of how many causal links there actually were. Even he couldn't stay inside the arbitrary boundary — because the boundary was never the point.
I've taken to calling this approach “the many whys” instead of the 5 Whys, and I wrote about the reasons why back in 2015. Tracey Richardson, who learned problem-solving firsthand as a group leader at Toyota Motor Manufacturing Kentucky, made a similar point in a piece for the Lean Enterprise Institute. She wrote that the “5 Why” label is meant to encourage you to ask why more than once or twice, to dig below the surface. The actual number is not the point.
Art Smalley, another former Toyota person, has noted that Ohno used the number five simply because that's how many it took in that particular case at the Kamigo plant. Could have been three. Could have been six. The number stuck as a label, and people turned the label into a rule.
Restating The Seven Whys
- Why did the machine stop?
The fuse blew. - Why did the fuse blow?
There was an overload. - Why was there an overload?
The bearing was not sufficiently lubricated. - Why was it not lubricated sufficiently?
The lubrication pump was not pumping sufficiently. - Why was it not pumping sufficiently?
The shaft of the pump was worn and rattling. - Why was the shaft worn out?
Metal scrap got in. - Why did metal scrap get in?
There was no strainer attached.
Where the Chain Stops — and Why It Shouldn't
The counting thing is interesting, but the bigger issue is where Ohno's example ends. “There was no strainer attached and metal scrap got in.” OK. So we attach a strainer. Problem contained.
But why was there no strainer?
Was it left off in the original machine design? Did someone remove it during a repair? Was there no standard work specifying it needed to be there? Was there a strainer that broke, and no one had a process to check for that?
Those are the questions that move you from a technical fix to a systemic one. Attaching a strainer is containment. Understanding why the strainer was missing — that's where the learning lives.
I raised this same point in my book Measures of Success, where I used a Toyota website version of this example (which is slightly different — a robot instead of a machine, a filter instead of a strainer). In that version, I continued the chain:
- Why is there no filter on the pump? Because a team member removed it.
- Why did the team member remove it? They needed it to fix a different robot, and the stockroom had no filters available.
- Why were there no filters in the stockroom? Because the reorder point inventory level was set too low.
Now you're in the management system. Now you're talking about inventory policies, spare parts planning, the conditions that made it rational for someone to pull a filter off one machine to fix another. That's a different kind of countermeasure than “put the filter back.”
Tracey Richardson offered a useful test for when to stop: you've gone far enough when you can form a countermeasure that addresses the root cause and all the symptoms up the chain. And you've gone too far when you've changed the context of the problem entirely. She illustrated this with an alarm clock example — “Why was I late for work?” — that eventually reaches “the Earth rotates.” At that point you've left the realm of countermeasures and entered cosmology.
The Art of the Right Depth
Jeff Liker made a similar point when he joined me on Episode 498 of the Lean Blog Interviews Podcast. If you keep asking why long enough, you end up at something outside your control — product development made a bad design choice, or the supplier changed their spec. That's too far. You want to land on what Jeff calls a “controllable cause that will make an impact.”
I've joked about this before, including in that same conversation with Jeff. If you ask why too many times, you eventually end up blaming Congress. Jeff extended the joke — you could trace it back to how minerals are extracted from the earth, or to human evolution and our genetic weaknesses. I said somehow you'd end up blaming a meteor strike from hundreds of millions of years ago.
That's absurd, but it makes the point. You don't want to stop too early and end up with a technical patch. You don't want to go so far that you're shaking your fist at the jet stream. The right depth is where you can actually change something, and where that change prevents the problem from recurring.
A Different Kind of Question
I was curious how my AI Lean Coach would evaluate Ohno's original chain. The coach's analysis tracked with what I've been saying — it noted the strengths (staying in the process, not blaming a person, pointing to observable conditions) and flagged the same gap.
But it also posed a question I think is worth thinking about: “Why was it possible for a machine to run without a strainer?”
That's a different kind of question than “why was there no strainer?” It's asking about the system that allowed the absence to go unnoticed. It pushes into process design, mistake proofing, standardization, and how work gets checked. That's the territory where Lean thinking wants the learning to go.
Jeff Liker described this as central to the real purpose of the 5 Whys. He sees it as a coaching process, not just a technical one. The goal is to get the person to think beyond their first impression — and the first impression is often to cast blame. The whys, done well, pull you away from “who screwed up?” and toward “what allowed this to happen?”
The Number Doesn't Matter
Ohno said to ask why five times “about every matter.” He also recommended going to see the actual situation rather than brainstorming in a conference room. The number was a guideline. Sometimes, three whys gets you to a useful countermeasure. Sometimes you need eight. What matters is whether you've reached a cause you can act on, and whether that action prevents the problem from recurring.
In this case, attaching a strainer prevents metal scrap from clogging the pump. That's useful. But understanding why the strainer was missing and making sure it can't be missing again — that's the deeper win.
Even Ohno's famous example leaves room for one more why. I think he'd be OK with that.
