The technical debt that costs a company years is rarely a technical problem.
It is a product decision nobody wanted to make. It got left in the code to make itself.
Some debt is exactly what the word says. A rushed implementation. A test suite skipped under deadline. A dependency three versions behind. That kind you can estimate and pay down, and teams mostly do. It is annoying. It is not dangerous.
The debt that costs you years is different. It looks like an engineering mess. It is an unmade product decision that found a quiet place to live.
Here is why the disguise works.
When engineers hit a mess, they name it from their own world. Debt. The word sounds like engineering. Something you estimate, schedule, and pay down over time. It does not sound like a decision about who the product is for.
That is the trick. Once the mess has a technical name, it belongs to engineering. The product question underneath it belongs to nobody.
A team once asked me to plan a refactor of their billing module. Every change broke something two steps away. They wanted a clean-up plan.
I asked a different question. How many customers are billed the standard way?
Nobody knew. We counted. It was under twenty percent.
Every other customer had an exception. Sales had asked for each one. Someone had approved each one, because there was a deal on the table. Key accounts get special terms and that is normal. But most of these were not key accounts.
The code was not tangled because the engineers were careless. Every exception was reasonable on the day it was asked for. Nobody was adding them up. The refactor was a request to clean up a total that nobody had been watching.
A second team had a feature that broke often. Fixing it was a named part of someone's week. In the tracker it was maintenance.
One customer used it. They had refused to move to the new version. They did not want to update. They did not want to retrain anyone. They wanted things to stay as they were.
So the old path stayed alive, and every release had to keep working for it. The label said maintenance. The real question was whether anyone would have the conversation with that customer.
Nobody would. Engineering carried it instead.
A third team called one of their integrations legacy. Everyone used the word. It was legacy the way weather is weather. A condition you route around and stop seeing.
I asked who had checked whether it could go. Nobody had. Not engineering, not product, not sales.
That is the part worth sitting with. Removing it needed a phone call. Ask the few customers still on it whether they actually use it. Offer them the newer feature. Some of them would have shrugged and said fine.
Nobody made that call. Not because it was hard. Because it was nobody's job to pick up the phone.
So I gave it to someone. One person, named, whose work included asking whether a thing could go, and making the call to find out. Not a committee. Not a quarterly review. A name against the question.
It worked, and it was not free. The job only functions if that person can decide and then defend the decision. Something gets removed, and someone is unhappy about it, usually whoever promised it to a customer in the first place.
Which means I have to back them. Not quietly, and not afterwards. In the room, at the time, in front of the person who is angry.
That is the price, and it is not a line in a budget. It is personal, and it comes back every time.
Three teams. Three technical words. Refactor. Maintenance. Legacy.
Under each one sat a product decision nobody had made. It lived in the code because the code was the one place it could sit without anyone feeling responsible for it.
This is the missing question from the first issue, and now you know the costume it usually wears. The question rarely turns up in a strategy meeting with a strategy label on it. It turns up in the engineering backlog, dressed as a task. A task has an owner. A decision does not.
Once you see it this way, the debt stops being the interesting part. The debt is a symptom.
The real event is that the label on a piece of the product and its value have come apart. The team calls it a feature after the market has left it. The team calls it core when it serves one account. The name and the worth stopped pointing at the same thing.
That coming apart is not random. There is a pattern to how a label and a value drift, and the pattern is where I go next.
Cases in this series are composites. The patterns are real, the companies are not.
The full Core and Bloat™ method, four boxes and all, sits at dirkbauer.com/core-and-bloat.html.