🎯 Quick Answer

What: A symptom is what a problem does to you (the line stops, the report is late, the batch fails). A root cause is why it does it. Root cause analysis, often run as a Five Whys, traces a symptom down to a cause you can actually change.

Why it matters: A problem you only silence comes back, because the cause is still there. A recurring problem is almost never a hard problem. It is an undiagnosed one, and you pay for it every time it returns.

How to apply: Take one clear symptom and keep asking why, one level at a time, until you reach something you can change (a process, a system, or a rule) rather than a person or another symptom. Verify each link against evidence before you fix it.

The payoff: You stop firefighting the same issue every quarter. You fix the cause once, and the symptom stops coming back.

The most satisfying thing a team can do is make a problem go away. It is also, often, the most expensive.

A machine keeps tripping, so we get faster at resetting it. A report keeps arriving late, so we start it earlier. A defect keeps slipping through, so we add a second inspection. The problem quiets down, everyone feels the relief of progress, and a month later it is back. None of those were the cause. They were the symptom, and we simply got very good at treating it.

I have watched this pattern play out in three industries that have never once compared notes, and it always looks the same. A symptom is what a problem does to you. A cause is why it does it. Treating the symptom feels like winning, because the pain stops for a while. But a problem you only silenced will always return, usually at a worse moment, and usually after you have stopped watching for it.

The recurring problem is the tell

Ask an operations team about a recurring problem and you will often hear how many times it has been fixed. That is the tell. A problem that has been solved three times has never actually been solved. It has been managed.

It is tempting to read a returning problem as bad luck, or a genuinely hard one, or a team that cannot execute. Usually it is none of those. A recurring problem is an undiagnosed one. The cost is not only the rework. It is the credibility a team spends fixing the same thing in public, again, while the real cause sits one or two questions deeper, untouched.

Keep asking why (but not exactly five times)

The discipline that reaches a cause is almost embarrassingly simple: keep asking why. Why did the machine trip? Why did that condition exist? Why was it allowed to? You keep going until you reach something you can actually change, rather than a symptom or a person. That is the root. Everything above it is just the problem wearing a disguise.

This is the Five Whys, and its name causes half its failures. Five is a guide, not a quota. Do not pad a chain to reach five, and do not stop at three if the cause is one why deeper. The goal is not a number of questions. It is a cause you can act on.

A few habits separate a real Five Whys from five guesses in a row:

The loudest place is rarely where the problem lives

The symptom is loud and it is local. It shows up on a specific machine, in a specific report, at a specific moment, and every instinct pulls you to fix it right there. The cause is usually quieter and further upstream, and it will not announce itself. You have to follow the problem back to it.

I once watched a team spend the better part of a year recovering, brilliantly, from the same equipment shutdown. They were measured on how fast they brought it back, and they were excellent at it. Nobody was measured on why it kept going down. When we finally traced it, the cause was an upstream condition several steps back from where the alarm went off. They fixed that, and the shutdowns stopped. The talent that had gone into recovering fast was finally free to go somewhere else.

The test of a real fix is boring but honest. If you solved the cause, the symptom does not come back. If it comes back, you treated the symptom. That test is also what protects the honest baseline you set out to improve, because an improvement only counts if the problem it fixed stays fixed.

If field notes like this are useful to you, I write more of them, and share the tools I build, in my newsletter.

Frequently asked questions

What is the difference between a symptom and a root cause?

A symptom is what a problem does (the observable effect: a late order, a failed batch, a tripped line). A root cause is why it happens, the underlying condition that, if removed, stops the symptom from recurring. Treating the symptom relieves the pain temporarily; removing the cause ends it.

What is the Five Whys?

It is a root cause analysis technique where you take a symptom and ask "why" repeatedly, one level at a time, until you reach a cause you can actually change. Despite the name, the goal is not exactly five questions. It is to get past surface explanations to something a team can act on.

Why do recurring problems keep coming back?

Because the cause was never removed. The team fixed what the problem was doing, not why it was doing it. A cause left in place will always find its way back to the surface, which is why a recurring problem is a sign of an undiagnosed one, not a hard one.

How do I know when to stop asking why?

Stop when you reach a cause you can change (a process, a system, or a rule) rather than a symptom or a person, and when evidence confirms that cause actually drives the problem. If your answer points at a person, ask one more why about the process that allowed it.

How is root cause analysis different from just fixing the problem?

"Fixing the problem" often means addressing the symptom so the pain stops now. Root cause analysis addresses why the symptom occurred so it does not recur. The difference shows up later: a symptom fix comes back, a cause fix does not.