Find the Root

Your kitchen sink keeps clogging. You snake it. Two months later it clogs again. You buy a stronger snake. Three months later, same thing. The drain isn’t the problem. The grease trap was never installed. Most people read that story as “keep digging.” The real insight is different: you know you’ve found the root when the fix is small and slightly uncomfortable. That’s the signal. Not certainty, not an algorithm. A small fix pointing at something you’ve been protecting.

There’s a distinction most people collapse. A contributing factor describes this event. A root cause describes how the system works. “The hire who left” describes this event. “One person’s exit was enough to move the number” describes the system. Both feel like explanations. Only one tells you what to change. The test is whether the answer changes category, or just changes level of detail.

Two axes help you locate where you are. The first is answer shape: does your explanation look like the problem, or does it look different? “I’m late because I had back-to-backs” is the same shape as “I’m late.” Both describe the event. “I book my calendar without buffer” is a different shape entirely. That’s the system. When the answer changes shape, you’re getting somewhere. The second axis is fix character: does your proposed fix add something, or remove what’s generating the problem? Complex new processes are usually symptoms dressed as solutions. The grease trap fix isn’t a better snake. It’s the thing that should have been there from the start.

The first answer that sounds reasonable is almost never the root. It’s the loudest symptom. Name it and keep going.

Ask why until the answer stops describing this situation and starts describing a default. “The vendor missed the deadline” is this situation. “We don’t build in buffer for external dependencies” is a default.

When you land on the root, the fix will feel too simple. That simplicity is a feature. You’re not adding complexity, you’re removing what was generating the problem.

Root causes are uncomfortable because they point at decisions you made. Habits you’ve kept, defaults you’ve been protecting. The discomfort is directional information, not a reason to stop.

This compounds quietly. The person who keeps digging stops getting hit by the same problem in new packaging. Their decisions age well. They look slow in the moment and fast over a year.

Before you act, run these. Has some version of this happened before? If yes, what did you do last time, and why is it back? Does your proposed fix add something, or remove what’s generating the problem? If you fixed what you’re about to fix, could the same result arrive through a different path? Is there discomfort in the fix, and if so, what default is it pointing at?

One limit worth naming: sometimes you can’t fix the root in the time available. A contributing factor can be the right place to act when you need to stop the bleeding now. The mistake is treating that triage as the solution. Fixing the contributing factor buys you time. It doesn’t replace finding what actually generated the problem.

Symptoms beg for activity. Causes ask for honesty. Stay with the question until the answer changes category.