Why haven’t they done this already?

One of the most dangerous questions you can ask when you walk into an unfamiliar company is: why the hell are they doing it this way?

It’s also one of the most useful questions on earth. What separates the disaster from the breakthrough is what you do in the next five minutes.

When an advisor or a senior hire is brought in from the outside, they’re hired to see the things the internal team has gone blind to. And if you’ve been doing this for a couple of decades, you’re gonna spot problems everywhere. The deployment process is broken. The sales team is structured upside down. There’s a critical spreadsheet that should obviously be an automated database, and there’s custom internal software that should have been bought off the shelf five years ago.

You walked into the building holding a hammer, and suddenly the whole place looks full of nails.

So over the years, I’ve trained myself to pause and ask a second question before I swing: why haven’t they done this already?

And I mean that as a completely honest, non-judgmental inquiry. Maybe a team already tried to fix it three years ago and failed. Maybe that ugly, manual hack is handling an edge case that only shows up twice a year but costs a quarter-million dollars when it’s missed. Or maybe everyone in leadership agrees with your diagnosis, but the fix has correctly sat at number seventeen on their priority list behind keeping the main revenue engine alive.

Sometimes the answer really is that nobody got around to it. I’ve just learned to arrive at that conclusion dead last.

When the mess is genuinely a mess

Years ago, I got brought into WagJag, a Canadian e-commerce business competing during the peak of the Groupon boom. The underlying technology was in brutally rough shape. Nothing was modular, so trying to scale the business simply meant scaling the chaos. The team spent months restructuring the engineering organization and rebuilding massive chunks of the core transaction flow.

It was only later that I discovered how the architecture got there in the first place. The original platform had been bought from a seventeen-year-old kid who’d built it over a weekend for a coding contest.

Which is wild, and it explained literally everything downstream. Features had been piled onto a high school project, then more features were glued on top of those, and nobody had ever stopped to reset the foundations. If that original developer had walked away early on, the company would’ve been completely screwed. Everyone on the executive team knew it.

Understanding the origin story made total sense of the architecture. The platform was still a mess, and intervening was necessary. But there’s a diagnostic question I’d push much harder today: even if this system has to be rewritten eventually, does it have to be rewritten this quarter? I conflated “broken” with “urgent,” and they aren’t the same thing.

Broken and important are two completely different lists

Give me three weeks inside almost any mid-market company, and I can easily hand the CEO a list of twenty operational fires.

Two of those twenty are absolute bangers. They represent pure enterprise leverage. The other eighteen are legitimate problems that happen not to matter right now, and the entire skill is telling them apart before you start burning capital.

Every engineering refactor and operational overhaul competes for the exact same people and the exact same hours. Spending six months rewriting an internal platform is six months your best people didn’t spend pursuing a commercial opportunity worth five million dollars. That opportunity cost never prints on an income statement, which is why it gets ignored in transformation plans.

The ugly parts might be holding the roof up

I saw the opposite side of this dynamic at Jive Software, back when they were building enterprise collaboration platforms. The core codebase was legacy Java, and there was no shortage of engineers demanding a total ground-up rewrite.

Except parts of that system, particularly the security and permissions models, had been engineered with solutions so clever they looked like magic from the outside.

The company eventually attempted a massive rewrite anyway, and the new build simply couldn’t reproduce the nuanced edge cases the legacy system had accumulated over a decade. Ten years of code clutter is also ten years of customer edge cases, regulatory exceptions, and patches for real-world scenarios everyone in the current meeting room has forgotten. Some of it is dead weight. Some of it is scar tissue. But some of it is literally holding the roof up. The entire job is knowing which is which before you swing the sledgehammer.

So these days, when someone casually tells me it’d be faster to just rewrite a legacy system from scratch, I go quiet. The idea that a blank slate is easier is mostly nonsense. Show me the complete catalog of what the old machine actually handles first.

The question I ask constantly

When I’m walking through a business, I ask the front-line people the same question over and over: what do you think?

Here I am, brought in as the outside expert supposed to have all the answers, and I’m spending half my time asking the engineer who’s been there four years to poke holes in my theories. I’m hunting for their counterexample. I want the single piece of evidence that destroys my working model, because I’d much rather have my thesis break in week one than in month six after burning the client’s money.

The level of evidence you need depends on how reversible the decision is. A low-risk operational tweak can be decided over lunch. A nine-month system overhaul that consumes your engineering bandwidth requires an enormous burden of proof. You’re gambling with somebody else’s balance sheet and somebody else’s time.

That discipline used to come naturally because capital constraints enforced it. Decades ago, proposing a platform rewrite meant asking for a budget and twenty engineers, so somebody had to defend the bet to the board. Today, a small team armed with modern AI can spin up a convincing prototype in a few days. The friction of starting a build has dropped to zero, but the cost of understanding what has to survive hasn’t moved an inch.

When you walk into a business holding a hammer, you’re always going to see nails. Some of them need to be driven home. Some aren’t worth the swing. And some of them are the only things keeping the walls upright.