Why haven’t they done this already?

One of the most dangerous questions you can ask walking into a new company is: why the hell are they doing it this way?

It’s also one of the most useful. What separates the two is what you do in the next five minutes.

When you’re brought in as a consultant, an executive, an expert, you’re supposed to see what the people inside can’t. That’s most of why you’re there. And if you’ve been doing this a while, you’ll see plenty. The process is broken. The architecture is a mess. The team is structured wrong, nobody’s measuring the right thing, there’s a spreadsheet that should obviously be software, and there’s software that should obviously have been bought instead of built.

You walked in holding a hammer. The building is full of nails.

Most of what I get paid for is the nails I leave alone. Leaving a thing alone is a decision, and it never looks like one, which is why it’s the easiest call to skip and the hardest to defend.

So I’ve learned to ask a second question before I swing.

Why haven’t they done this already?

I mean that as a real question. Assume you’re not the first smart person to walk into this room.

Maybe somebody tried it. Maybe there’s a constraint nobody has mentioned yet. Maybe the ugly process is handling an exception that shows up twice a year and costs a fortune when it’s missed. Maybe the terrible piece of software is terrible and replacing it still costs more than living with it. Or maybe everyone in the building agrees with you, and it has correctly sat at number 17 on the list for two years.

Sometimes the answer really is that nobody fixed it. That happens more than it should. I’ve just learned to arrive there last.

Sometimes the mess really is a mess

Years ago I got involved with WagJag, a Canadian company competing in the Groupon era.

The technology was in rough shape. A lot of JavaScript running on Node, testing that wasn’t terrible, and an architecture nowhere near what a growing company needed. Adding functionality kept getting harder. Nothing was modular in any useful way, so scaling the technology meant scaling the mess.

A few of us came in with enough miles on both legacy systems and newer architectures to start pulling it apart. We restructured the team around higher-volume data engineering and began rebuilding significant pieces of the platform. It ate months.

Only later did I understand how the system got there.

The original product had been bought from a 17-year-old who had written it for a contest. Which is wild, and it explains everything downstream of it. It went into production. Things got added. Then things got added to those things. Eventually a team was built around it, and the original developer stayed central to all of it with enormous freedom to keep working his way. Nobody ever reset the architecture or took control of it.

By the time we arrived, almost nobody could hold the whole thing in their head. If the original developer had walked, they were screwed, and everybody knew it.

Once I knew that history, the architecture made a lot more sense. It was still bad.

The history explained the fence without justifying it. The system was genuinely capping the business, and every patch was manufacturing two more problems. We needed to intervene, and we did.

But there’s a question I’d ask now that I didn’t push hard enough then. Even if this has to be rewritten, does it have to be rewritten this quarter? Those are two different questions, and I ran them together.

Wrong and important are two different lists

Almost everything inside a company is wrong in some way. Give me a few weeks in your business and I’ll hand you twenty things I’d change.

Two of those twenty are bangers. The other eighteen are real problems that happen not to matter this year, and the hard part is telling them apart.

Every improvement is competing for the same money, the same people, the same hours. Six months rebuilding a platform is six months those engineers spent not going after the thing worth five million. That’s opportunity cost, and it’s the line most reliably left out of a transformation plan, because it never shows up on anybody’s budget.

So the question worth asking is whether making this better is the best available use of what you’ve got. Can we make it better? Obviously. You can always make it better.

Sometimes the answer is yes, go. And sometimes a thing is objectively bad and still deserves to be left exactly where it is.

The ugly parts might be load-bearing

I saw the other side of this at Jive Software.

Jive built enterprise social software, roughly the idea of putting something like Facebook inside a company. The product had been around for years. Open source, mostly Java, with other technologies layered around it and on top of it as time went on.

There were plenty of reasons to want to replace it. There were also parts of that system that had become extraordinarily sophisticated. Security was one. Some of it had been written in ways that were clever enough to look like magic from outside, and reading the outside of the system told you very little about what it was actually doing.

Jive eventually attempted a major rewrite.

This is where rewrites get interesting. When you look at a ten-year-old system you see ten years of accumulated mess. You’re also looking at ten years of accumulated decisions. Customer requirements. Edge cases. Security rules. Integrations. Strange behaviours somebody out there depends on. Workarounds for problems everyone has forgotten about.

Some of it is dead. Some of it is scar tissue. Some of it is holding the roof up. Telling them apart is the entire job.

The rewrite couldn’t reproduce enough of what the old system had accumulated.

Which is why I go quiet now when somebody tells me it would be easier to rewrite it. Sometimes it is. Mostly it’s nonsense. Tell me what it does first.

“What do you think?”

I ask people this constantly, and I’ve wondered whether it makes me sound wishy-washy. I’m the one brought in to have the answer, and here I am asking the guy who’s been here four years what he thinks.

I’m after his counterexample. I’m hoping he knows one thing that breaks my model of the problem, because I’d rather it break in week one than in month four.

That gets harder the more you’re treated as the expert. People get reluctant to disagree with you at exactly the point where you need them to.

It’s also why I reason out loud. I’ll form a theory, follow it, ask questions, hit something that doesn’t fit, back up, try another direction. Why did that happen? And why did that happen? Digging and digging and digging until the thing underneath stops moving.

Someone watching that sees uncertainty. They’re right. It is uncertainty.

Uncertainty and indecision are two different states. What I’m doing is letting people watch the model get built and giving them chances to break it. Productive uncertainty. As long as you’re testing, hunting counterexamples, trying things, you’re hard to get stuck. Either you move closer to an answer or you kill one. Both count.

Eventually you know enough to act. Enough is a much lower bar than everything, and it’s the only one you’ll ever clear.

How much counts as enough depends on what happens when you’re wrong. A cheap, reversible decision can be made in ten minutes. A six-month rewrite that swallows most of an engineering organization earns a far higher burden of proof. You’re spending somebody else’s money and somebody else’s year.

Some risk is the job. Scale the thinking to the cost of being wrong.

Does the thing work yet?

A small version of this came up with a client recently.

They were building an AI product and weren’t happy with how it performed. They had Claude Opus. They were looking at GPT-6. Then another model. They were also worried about latency.

My question was simpler. Does the thing work yet?

Not really.

Then stop. Leave the model stack alone. Stop worrying that it takes thirty seconds, because nobody is sitting there waiting on it. Go find out why the product isn’t producing the result you need. A wrong answer in ten seconds is still a wrong answer.

That’s the smallest version of the move. Stop, and go find out why the thing doesn’t work before you spend a dollar making it fail faster.

Stopping used to be easier, because the cost decided for you. Twenty years ago, proposing a rewrite meant asking for a team and a year, and the expense forced a conversation. Somebody had to stand up and defend it. Now one person and a model can produce something that looks remarkably like a replacement in a week, and nothing forces the conversation at all.

The cost of starting a rewrite has fallen much faster than the cost of understanding what has to survive it. So the restraint has to come from somewhere else now, and the only place left is you.

Before you swing it

I’ve been in rewrites that had to happen. I’ve seen systems where one more patch was just buying tomorrow a worse day. And you rarely get six months to study a company before you decide anything, so you form the hypothesis fast and act on incomplete information. That part is the job.

What I do before changing something is make an assumption and then try to disprove it, out loud, with the people who live there.

Why is it this way?

Why hasn’t somebody already done what I’m about to propose?

What problem am I actually solving?

What evidence would tell me I’m wrong?

Does this matter more than the other things those people could be doing?

What happens if I’m wrong?

And if I’m replacing something: what has to still be true when I’m finished?

None of that eliminates the uncertainty. Nothing does. It earns you the right to intervene, which is a different thing, and the only thing on offer. More often than anybody wants to hear, it earns you the right to leave the thing alone for another year.

Because you walk into an unfamiliar business holding a hammer, and you are going to see nails.

Some of them need hammering. Some aren’t worth the swing. And some of them are holding the building together.