ask why

Debugging your own code is like solving a murder where you are the investigator, the murderer, and the victim.

Leading your own organization isn't that different.

In my prior role, I often sat in meetings where someone was walking through a problem and I would simply ask: why?

They'd explain. I'd ask why again. They'd go deeper. I'd ask again. It became a bit of a joke after a while, but I meant it every time. I genuinely didn't understand why the process was the process, why the system was the system, why the form had seven fields and not four, why the approval chain ran through three people who all admitted they didn't fully understand what they were approving.

I wanted to trace it back to a real decision. One made by a real person, for a reason that made sense in some specific moment.

Most problem-solving in organizations skips this step entirely.

Someone surfaces an issue and the room immediately starts generating solutions. Options get debated. Owners get assigned. Work gets scheduled. And somewhere underneath all of it, the actual cause sits untouched, because nobody stopped long enough to find it.

Jumping to solutions before understanding the problem doesn't make you faster, it makes you busier. There's a difference. I hate busy.

What I kept finding when I asked why enough times was that the room would eventually go quiet with genuine recognition that nobody could locate the original decision, or often even the problem it solved. The reason had fully decayed. The practice was still running on momentum, consuming time and people and attention, because repeating the story of why you do it this way is easier than asking whether you should.

That quiet is worth sitting with. It means you've found the edge of your map.

Most processes exist for decent reasons. Some of the answers you find at the bottom of the why chain will be legitimate, and you'll leave them alone.

But some won't. The only way to tell the difference is to keep asking until you hit something real, something you can evaluate on its merits instead of its tenure.

If the answer is still "that's how we do it here," you haven't hit bottom yet.