The Problem Isn't the Employee. It's Your Fourth "Why."

If a late shipment, a missed deadline, or a customer complaint happened last month, it will probably happen again next month, to a different employee, for the same reason, unless something about how the work gets done actually changes. Most small business owners never get that far. A problem surfaces, someone explains what happened, the explanation sounds reasonable, and everyone moves on. The explanation is almost never the real cause. It’s just the first plausible one.

The fix isn’t a new hire, a new tool, or a stern conversation. It’s a fifteen-minute habit called the 5 Whys: ask “why” about the answer you just got, and keep asking until you land on something you can actually redesign.¹

Why the First Answer Is Never the Real One

Sakichi Toyoda built this into what became the Toyota Production System, and Taiichi Ohno called it the basis of Toyota’s entire approach to problem-solving.² The logic is not complicated: state the problem in one specific sentence, ask why it happened, ask why about that answer, and keep going. There’s nothing magic about the number five. You stop when the answer describes a process, a template, or a missing owner, not a person or a one-time accident.¹

Here’s the practical test, borrowed from federal quality-improvement guidance: if you fixed the thing this answer describes, would the problem still come back? If yes, you’re not done. You’re still standing on a symptom.³

Small business owner and consultant David Jenyns puts a number on it: don’t let yourself decide on a fix until you’ve asked “why” at least four times.¹ The first two answers almost always land on an individual. Push past them and you usually land on one of three things: no documented process, a broken or missing template, or nobody clearly responsible for catching the problem before it reaches the customer.¹

State the Problem, Not the Frustration

A problem is a specific, checkable gap between what’s happening and what should be happening. It is not a feeling about what’s happening. “It takes too long for orders to ship” is a complaint, not a problem statement, because there’s nothing in it to ask “why” about yet. Turn it around and make it your first move instead of your finish line: state the fact, then force an actual answer as part of writing it down. “Orders are averaging four days to ship. Here’s why: the packing list doesn’t print until someone manually checks the queue.” Now you have a real first why, something specific enough to keep pushing on.

Strip the emotion out while you’re at it. “Nobody around here takes shipping seriously” and “it’s always a disaster” describe how you feel, not what’s happening, and they do two things at once: they point the first why at a person before the session has even started, and they hand the group a feeling to argue about instead of a mechanism to trace. If a word in your problem statement describes how you feel rather than something you could point to on a report, cut it.

Run It in Fifteen Minutes

A typical chain looks like this. Problem: orders are shipped late. Why? We don’t start packing until the day after the order comes in. Why? We only check the order queue once a day. Why? No one owns watching it. Why? We never wrote a fulfillment process when we set up online ordering. That last answer is fixable: a documented workflow with a named owner. “Staff need to work faster” was never going to fix anything, because it wasn’t the real cause.³

Seven Ways to Derail Your Own Session

A 5 Whys session can go wrong without anyone noticing, because it still feels productive. Watch for these:

• Listing symptoms instead of following one thread. If the group starts generating a list of everything wrong with the process, that’s a different exercise. Pick one answer, ask why about that specific answer, and follow it all the way down before circling back to anything else.
• Landing on a person’s name. “Because Maria forgot” or “because the new hire didn’t know” ends the session on someone to blame, not something to fix. If an answer names a person, ask one more why: what let that person’s mistake reach the customer with nothing catching it?
• Steering toward the system you already wanted. If you walked in planning to hire someone or buy new software, it’s easy to stop asking “why” the moment an answer supports that plan. The whys are supposed to find the cause, not build a case for a decision you’d already made.
• Treating the original problem as the answer. “Orders are late because orders are late,” restated in different words, isn’t a first why, it’s the group refusing to start. Each why has to add new information, not repeat the problem statement back.
• Using a word instead of an explanation. “We’re understaffed.” “We’re too busy.” These sound like causes, but they don’t point at anything you can change on a Tuesday. Ask why you’re understaffed, and you’ll usually find a specific hiring delay, a schedule gap, or a process that breaks under load, something you can actually act on.
• Staying vague enough to sound true of anything. “Communication broke down” or “we need better processes” would fit almost any problem in the business, which means it doesn’t really explain this one. If the answer would work word-for-word in a different session about a different problem, it’s too generic to be the root cause.
• Assuming one chain explains the whole problem. A former Toyota managing director, Teruyuki Minoura, pointed out that different people running the same session often land on different “root causes,” and that a single line of questioning can miss causes sitting outside whoever’s in the room.² If the team can’t agree on the chain, or if fixing the one cause you found doesn’t stop the problem, run it again with someone who saw a different angle.

Pair every root cause you do find, of any of these kinds, with a one-page checklist or SOP, not just a verbal agreement, so the fix survives past the meeting where you found it.³ Use this for the problems that keep repeating: late orders, the same billing error, the same kind of customer complaint. It’s the wrong tool for a genuinely one-off event or a strategic question like “should we open a second location.” Save it for the failures your business keeps having, on a schedule (two or three short sessions a month is enough) and immediately after anything that costs you real money or a real client.¹

Key Takeaways

Key Frameworks:

• 5 Whys: repeatedly asking “why” about the previous answer until you reach a process, template, or ownership gap instead of a person or a one-off.
• The recurrence test: before you commit to a fix, ask whether the problem would still happen again if this particular answer got corrected.

Try It: Pick one problem that happened twice in the last month. Write it as one specific sentence, then ask “why” four times with whoever was closest to it. Write down the one fix, the one owner, and the date you’ll check whether it worked.