Most 5 Whys examples online end the same way, with someone asking why five times until the fifth answer turns out to be one neat fix. Real chains rarely go like that, because the first answer is often wrong and one why can have two true answers. Sometimes the chain even ends at the person who was asking the questions.
The method itself is simple: you ask why a problem happened, and then you ask why about each answer until you reach a cause you can fix. This guide works through eight chains from ordinary workplace problems like late laptops, long meetings and lost hires. Each one shows a single move that you can use on your own problems. Several of them show a chain going wrong, because that’s where most of the learning is.
What is the 5 Whys, and where did it come from?
The 5 Whys is a way of finding the root cause of a problem by asking “why” again and again, so that each answer becomes the subject of the next question. It’s one of the simplest problem-solving tools there is, since all you need is a problem and someone who knows the work.
The best-known example comes from Taiichi Ohno, the engineer behind the Toyota Production System. He described it in his book Toyota Production System: Beyond Large-Scale Production, which came out in English in 1988. The Lean Enterprise Institute’s entry on the 5 Whys sets out his chain about a machine that had stopped working. The machine stopped because an overload blew the fuse, and the overload happened because a bearing wasn’t lubricated well enough. The bearing was dry because the lubrication pump wasn’t pumping enough. The pump was weak because its shaft was worn, and the shaft was worn because there was no strainer to keep out metal scraps.
The Institute’s point about that chain is a practical one. Managers who don’t keep asking why would just replace the fuse or the pump. The failure would then come back. So you keep asking until you reach the root cause and remove it. In Ohno’s chain that cause is the missing strainer.
You’ll often read that the method was invented by Sakichi Toyoda, the founder of Toyota Industries. The Institute’s entry doesn’t say who came up with it, and the earliest written version we could check is Ohno’s. So we’ve treated Ohno’s book as the source and left the origin story open.
The number five isn’t a rule either, and the Institute says so plainly: “The specific number five is not the point.” Some chains reach a fixable cause in three whys and some need six or seven. So at each step, ask whether you’ve reached something you can change that would stop the problem from coming back. If you have, you can stop there.
How to run a 5 Whys
The method fits in six steps, and most of the skill is in steps two to four.
- Write a specific problem statement, because a vague problem gives you a vague chain. “Hiring is slow” could lead anywhere, but “three of our last five offers were declined” points at something you can look into. Our guide to writing a good problem statement covers this step in more depth.
- Ask why, and write the answer down as a fact that someone could check. “The form was sent late” can be checked against the date it arrived. “People don’t care about onboarding” can’t be checked at all, and a chain built on it won’t lead anywhere useful.
- Check each answer against something you can see before you ask the next why. This is the step people skip, because the first answer usually sounds right. But if that answer is wrong, every why that comes after it will be wrong too.
- Ask about the process rather than the person who was involved. “Why did Sam miss the deadline?” makes Sam defend himself, while “Why did the deadline get missed?” lets him tell you what got in the way. The wording matters because people who feel blamed tend to give the answer that protects them, which isn’t always the accurate one.
- Stop when you reach a cause that you or your team can act on. A deeper cause that nobody in the room controls might be interesting, but it won’t help you fix anything.
- Test the chain by reading it backwards with the word “therefore”. Start at the root cause and put “therefore” in front of each answer above it. If any step doesn’t follow from the one below it, a link is broken and you need to go back to that step.
Sometimes the cause is still a guess after a few whys, and you may need to test that guess before you go on. Our guide to troubleshooting skills shows how to turn a guess into something you can test.
8 worked 5 Whys examples from the workplace
All eight examples below are illustrative composites that we made up for this guide. The people and numbers are invented, but each chain follows the shape that real ones take. Each example shows one move, and the later ones are the chains that go wrong or end somewhere you didn’t expect.
1. New starters with no laptop on their first day
Alice runs people operations at a firm of about 300 people. Three of the last four new starters arrived to find no laptop and no system access, and each of them lost most of their first two days.
When Alice asked why, the first answer in the room was that IT is slow. It sounded right, because IT had been short of staff all year. But Alice checked the tickets before going any further, and they told a different story. IT had closed each ticket within two working days, but the tickets themselves had come in the day before each start date. So “IT is slow” was wrong, and the chain started again from what the tickets showed.
- Why did the new starters turn up to find no laptops waiting? The IT requests arrived just one day before they started.
- Why did the requests reach IT so late? Hiring managers send them, and they were sending them in the new starter’s first week.
- Why did the managers wait until that first week? The request form asks for a start date, and managers didn’t have one confirmed until the contract came back signed.
- Why didn’t the managers have the signed contract sooner? Signed contracts went to the recruiter’s inbox, and nobody told the manager when one arrived.
- Why was nobody told when the contract came back? No step in the process passes the signed contract on to anyone.
The move here is checking, and it’s easy to see what would have happened without it. If Alice had accepted “IT is slow”, the fix would have been to chase IT about tickets it was already handling on time. IT would have been annoyed and nothing would have changed, because IT wasn’t the delay. Pulling the ticket dates took a few minutes, and it changed the whole chain. That’s why you check each answer before you ask the next why, since a wrong answer at step one sends every later step the wrong way.
The fix was small: the recruiter now raises the IT request on the day the contract comes back signed. The next two starters had laptops waiting for them on their first morning.
2. The weekly team meeting that always runs over
Leo’s team meeting is booked for an hour, but most weeks it runs to 90 minutes. When he asked the team why, the first answer was “Because a couple of people talk too much.”
That answer might even be true, but it’s a dead end because the only fix it offers is telling two people to talk less. They’d feel singled out, and the meeting would probably still run over. So Leo changed the question, and instead of asking why people talk for so long he asked why the meeting has room for long discussions that nobody planned.
| Why? | Answer |
|---|---|
| Why does the meeting run over? | Two or three items turn into open-ended discussions. |
| Why do they turn into discussions? | They’re problems that nobody had thought about before the meeting started. |
| Why had nobody thought about them? | People add items to the agenda during the meeting itself. |
| Why do they add them then? | There’s no agenda beforehand, just a shared document that people open when they arrive. |
| Why is there no agenda beforehand? | Nobody owns the agenda, so it gets written live every week. |
A why about a person usually ends at someone’s personality, while a why about the process ends at something you can change. So when a chain lands on “people talk too much”, ask what it is about the setup that gives them room to. This also affects how honest the next chain will be. If the first chain a manager runs ends at someone’s name, the team learns what these sessions are really for. Our guide to psychological safety in teams explains why that matters so much.
Leo now closes the agenda the afternoon before, and anything added later waits a week unless it’s urgent. The meeting still runs over sometimes, but by a few minutes rather than half an hour.
3. Candidates turning down offers after the final interview
The first version of this problem was “We keep losing candidates,” and a chain that starts there goes nowhere. The first answer is usually that the market is tough, and nobody in the room can do anything about the market.
So Jess, the recruiting lead, narrowed the problem down by looking at the last nine people who had reached the final round. Four of them declined the offer, and all four did it within 48 hours of getting it. That’s a different problem, because it isn’t about attracting people at all. It’s about what happens between the final interview and the offer.
- Why did four of the nine decline within 48 hours? Each of them had accepted an offer from another company instead.
- Why did they choose the other offer over ours? Two of them said on the phone that the other company had moved faster.
- Why were our offers slower than theirs? Our offers went out eight to ten working days after the final interview.
- Why did each offer take that long to go out? Each offer needed sign-off from the finance director, who only reviews offers once a week.
- Why does the finance director only review offers once a week? The rule was set when the company hired a few people a year, and nobody had looked at it since.
The tighter problem statement did the work here, because it gave the chain real numbers to check. Offers inside an agreed salary band no longer wait for the weekly sign-off. But this chain only explains two of the four declines. The other two candidates didn’t give a reason, so Jess still doesn’t know what lost them.
4. A store that’s short-staffed every Saturday
Ryan manages a garden center that has been two or three people short every Saturday for the past two months.
When Ryan asked why Saturdays were short, he found two answers that were both true. Saturdays were short partly because staff swap Saturday shifts among themselves, and some of those swaps fall through. But two part-timers who used to work every Saturday had also left in the spring, and their replacements weren’t on the same hours. Both causes were real, so picking one would only have fixed half the problem. That’s why Ryan ran two separate chains, one for each cause.
The first chain followed the swaps, which fall through because people agree them in a group chat and nobody checks that the swap actually happened. Nobody checks because the scheduling tool doesn’t record swaps made in the chat, so Ryan’s copy still shows the original person. People swap in the chat because swapping in the tool needs manager approval, which they found slow.
The second chain followed the vacancies, and it started with why the leavers weren’t replaced on the same hours. The answer was that the new hires were on weekday contracts. They were on weekday contracts because the job ad had been copied from an older weekday vacancy. That happened because nobody checked which shifts the leavers had covered before the ad went up.
When one why has two true answers, run two chains. Picking the cause that looks bigger feels efficient, but the other cause keeps going in the background. Neither of Ryan’s chains needed five whys either, because each one reached a fixable cause at the third why. Swaps in the tool now go through without approval if both people are trained for the shift, and the next hire was advertised as a weekend contract.
5. The quarterly campaign that always launches late
Grace runs marketing for a small bank’s savings accounts. Her team has launched each of its last three quarterly campaigns one to two weeks late. Every campaign has to be reviewed by the compliance team before it can go out.
| Why? | Answer |
|---|---|
| Why do the campaigns launch late? | The compliance review takes longer than the plan allows for. |
| Why does it take longer? | The team sends the whole campaign about a week before launch. Last quarter compliance sent back 27 changes. |
| Why are there so many changes? | Claims in the copy need evidence that the team hasn’t gathered yet. A line like “our best rate in five years” needs the rate history behind it. |
| Why hasn’t the team gathered it? | Nobody on the team knows which claims compliance will query until the comments come back. |
The chain could easily keep going. The team doesn’t know because compliance has never written its rules down, and compliance hasn’t done that because the company treats approval as a final gate rather than a conversation. That may well be true, but nobody on Grace’s team can change how the company thinks about risk. A chain that ends there feels deep, yet it leaves the team with nothing to do.
So Grace stopped at the fourth answer, because that cause belongs to her own team. They asked compliance for a 30-minute walk-through of the comments on the last three campaigns, and they turned what they heard into a checklist. Most of the comments fell under a few rules. Any rate in an ad has to show the date it applies from. Any “best” or “better than” claim needs a dated comparison on file. Every customer quote also needs a signed consent form before it’s used.
It partly worked, since the next launch was three days late rather than two weeks. But compliance still found things the checklist had missed, because its rules changed more often than the team expected. That quarter a new rule asked for the minimum deposit to sit next to every advertised rate. The checklist now has an owner who updates it every quarter, and the team is still a few days late more often than not.
The move is to stop at the last cause your team can act on. Going deeper is tempting because it sounds more like a root cause. But a cause you can’t change doesn’t give you anything to do on Monday morning.
6. Assigned training stuck at low completion
Nadia is an L&D lead who assigned a short data protection course to 200 people with a six-week deadline. At week five only 38% had finished, and her first chain looked tidy.
- Why is completion so low with a week to go? Most people haven’t started the course yet.
- Why haven’t people started it? They don’t know that it’s been assigned to them.
- Why don’t they know about it? The reminder emails from the platform are going to spam.
- Why are those emails going to spam? They come from an outside learning platform that the email filter doesn’t trust.
Then Nadia read the chain backwards with “therefore” to see whether each link held. The emails go to spam, therefore people don’t know about the course, and that link holds. People don’t know about it, therefore they haven’t started. That link also holds, but only for the people who really didn’t know. So she checked who hadn’t started, and most of them had opened the launch email from their own manager. That email hadn’t gone to spam, which meant they knew about the course. So for most of the group the link between “they don’t know” and “they haven’t started” was broken.
She went back to step two and asked it again. Why haven’t people started if they know about the course? Because it takes 45 minutes in one sitting and can’t be paused. It can’t be paused because it was set up as a single module, and it was a single module because it had been built in a hurry from a slide deck.
Nadia split the course into three 15-minute parts that save progress as you go. She also sent the reminders from the HR team’s own mailbox, because the spam link was real for a smaller group. Completion reached 74% by the deadline, so a quarter of the group still hadn’t finished.
The “therefore” test catches a link that sounds right but doesn’t actually cause the step above it. These links slip in easily, because whoever answers each why usually has a theory already. Reading the chain backwards takes a minute, and it’s the cheapest check in the whole method.
7. Work that keeps coming back for rework
Every chain so far has asked why other people or other processes did something, but this one ends somewhere less comfortable.
Ethan leads a small design team, and about one piece of work in three comes back for a second round after he reviews it. He started the chain the way most managers would, by asking about the work.
- Why does the work keep coming back after I review it? It doesn’t match what I had in mind.
- Why doesn’t it match what I had in mind? The team made choices I wouldn’t have made about the layout and what to leave out.
- Why did the team make those choices? They didn’t know what I wanted from the piece.
- Why didn’t the team know what I wanted? My briefs say what the piece is for, but not who will read it or what that reader should do next.
- Why don’t my briefs say who the reader is? I write them in five minutes between meetings, and then I fill in the gaps when I review the work.
The fifth answer is about Ethan himself, and an honest chain is what brought him there. That’s what makes the 5 Whys useful when the manager is part of the problem, and it’s also why the method is so hard to run on yourself.
Most people protect themselves when a question points at them, and managers are no different. Ethan could easily have stopped at step three, because “they didn’t know what I wanted” still sounds like the team’s gap. So when you run a chain about your own team, ask the question of yourself first. At step three, “What did I give them to work from?” is a fair question to ask. It also shows the team that the chain isn’t hunting for someone to blame.
The chain could also have ended at “the designer didn’t follow the brief”. That’s a human error ending, and it feels finished even though it isn’t. A person who got something wrong usually had a reason, and that reason usually sits in the process.
Ethan now spends 15 minutes on each brief and adds two lines to it. One says who the piece is for, and the other says what they should do after reading it. The rework hasn’t gone away, but the second rounds are shorter now because they’re about details rather than direction.
That changes how the earlier examples read. Leo’s live agenda, Ryan’s approval step and the weekly sign-off rule in Jess’s chain were all set up by someone in charge, so most chains have a manager’s choice in them somewhere along the way.
8. Customer orders that bounce between three teams
Large customer orders at a wholesale supplier sometimes sit for days before they ship. Sarah is the operations manager, and she pulled the last 60 orders over $20,000. Eighteen of them had waited four working days or more before they left the warehouse. She then ran a 5 Whys, and the first two whys went smoothly. Large orders sit because they’re waiting for a credit check. They wait because finance checks every order over $20,000, and those requests come in by email.
Then the chain forked, because finance was slow for three reasons at once. Sales had sent 11 of the 18 slow orders without the customer’s account number. Finance only worked through that inbox on Tuesdays and Fridays. Operations also couldn’t see whether a check was still pending, so nobody chased it.
Each of those branches belonged to a different team, so Sarah could have run three more chains. But the problem was in the gaps between the teams rather than inside any one of them. Every fix needed someone in another function to change how they worked.
That’s the sign that the 5 Whys has done its job. It showed Sarah where the problem lives, but it can’t settle a problem that three functions share. She needed a way to list every cause in one place, and then a report that each team would sign up to.
That’s what Sarah did next. She listed the causes on a fishbone diagram with the three team leads. Together they wrote an 8D report that gave each of three changes an owner. The sales order form now won’t submit without an account number. Finance clears the credit inbox every morning. Each check also shows up as pending in the order system now, so operations can see it. Two months later, three of the next 50 large orders waited four days or more. The ones that still waited were mostly new customers, whose credit checks take longer anyway.
The rest of this guide covers where the 5 Whys runs out and what to use instead.
Where the 5 Whys breaks
The 5 Whys tends to break in five ways, and each one showed up in an example above. The method has its critics too. Alan Card published a critique of it in 2017 in BMJ Quality & Safety, a journal about patient safety and the quality of care. He gave it a blunt title: The problem with “5 whys”. The failure modes below are our own reading of the examples, not a summary of his paper.
The first is using one chain for a problem with several causes. Ryan’s Saturdays had two causes and Sarah’s orders had three, but a single chain picks one of them and quietly drops the rest. The Institute for Healthcare Improvement’s 5 Whys tool warns about this directly when it says “there may be multiple root causes of a problem.”
The second is a chain that ends at a person. “Human error” and “didn’t follow the process” feel like answers, but all they do is move the question. You still need to know why the mistake was easy to make and why nothing caught it. Ethan’s chain could have ended at a designer, and it ended at his briefs instead because he kept going.
The third failure is an answer that nobody checked against the evidence. Alice’s first answer was plausible and wrong, and Nadia’s chain held together until she read it backwards. A chain built on unchecked answers can look rigorous and still point at the wrong cause.
The fourth failure is stopping the chain in the wrong place. If you stop too early you fix a symptom, which is like replacing Ohno’s fuse. But if you go too far you end up at something like a company’s attitude to risk, which is where Grace’s chain was heading before she stopped it.
The last one is easy to miss, because a chain only knows what the people in the room know. The same IHI tool notes that “different people who see different parts of the system may answer the questions differently.” So if the person closest to the work isn’t there, the chain fills the gap with guesses that can sound exactly like facts.
5 Whys, fishbone or 8D: which should you use?
This is our rule of thumb, and it matches the one in our 8D guide. Use the 5 Whys when the cause is unknown but sits in one team, is contained and follows a single causal thread. Use a fishbone diagram when there are many possible causes and you need to see them all before you dig into one. Write an 8D report when more than one function has to change something for the fix to hold, or when someone outside the team will read the result.
| Situation | Tool | Why it fits |
|---|---|---|
| The cause is unknown, but it sits in one team and follows a single thread | 5 Whys | It’s quick, and the people closest to the work can run it in one sitting. |
| There are many possible causes and you don’t know which ones matter | Fishbone diagram | It lists the causes side by side before you drill into any of them. |
| More than one function has to change something, or someone outside the team will read the result | 8D report | It gives each fix an owner and records the evidence behind it. |
The tools also work together, so you can run a 5 Whys on the strongest branch of a fishbone. You can also run one inside the root-cause step of an 8D problem solving report, since that step needs a method and the 5 Whys is a common choice. Sarah’s orders met the 8D test because three functions had to change. Most of the other examples here didn’t, which is why a short chain was enough for them. Our guide to problem solving skills for managers covers the wider skill set behind all three tools.
Pick one problem that has come back more than once this month, and write it as a specific statement with a number in it. Then run the chain with the person closest to the work, and check each answer before you ask the next why.
The hardest part is often the first question, because it has to sound like it’s about the process and not about a person. Practice that opening question with Merlin in Slack or Microsoft Teams before you run the real thing. What you tell Merlin stays between you and Merlin, so you can try out the awkward versions first.