There are two ways to talk about technical debt. The first: “the code is a mess, we need to rewrite everything.” That one goes nowhere, because no executive has ever signed a check for “cleaner” code.
The second: “here is how much this debt costs us every month, and here is the return if we pay it down.” That one moves the needle, because it speaks the language of the people who decide the budget.
The gap between those two framings is exactly what separates a developer from a developer people listen to. Let’s see how to move from the first to the second.
Technical debt is not a dirty word
The debt metaphor is excellent, as long as you take it seriously. Taking on debt is not a mistake: sometimes it is the best possible decision. You take on technical debt to ship faster, test an idea, capture a market before a competitor. It is a rational choice.
The problem is not the debt. The problem is the interest you pay without realizing it, and the debt you took on without deciding to.
Why “we need to rewrite everything” never works
When a developer asks for three months to rewrite a working system, here is what the business hears: “three months with no new features, no value for the customer, a risk of breaking everything, to end up in the same place.”
Framed that way, the refusal is logical. The fault is not on the business side: it is in how the topic was presented. A budget was requested without showing either the cost of the problem or the expected return. Nobody invests blind.
Step 1: measure, make the invisible visible
The real obstacle is that technical debt is invisible on a standard dashboard. It does not show up in revenue, nor in the number of closed tickets. So you have to surface it with concrete indicators:
- Lead time: how long between “we decide to build this feature” and “it is in production”? If it grows at constant scope, debt is slowing you down.
- Deployment failure rate: how many releases cause an incident or a rollback?
- Workaround time: how many hours a week does the team spend working around a known problem instead of creating value?
- Fear zones: the parts of the codebase nobody wants to touch. Ask the team, they know them by heart.
These numbers turn a gut feeling (“it is a mess”) into a measurable fact (“our lead time has doubled in a year”).
Step 2: price it, translate into money and time
Once the debt is measured, you have to convert it into the one unit everyone understands: cost.
Take a simple example. A team of five developers spends, say, 20% of its time fighting an identified debt: workarounds, recurring bugs, features that take three times longer than planned.
- 20% of five developers is the equivalent of one full-time developer.
- Over a year, that is a full loaded salary poured into paying interest, without ever touching the principal.
Suddenly the conversation shifts. We are no longer talking about “messy code,” we are talking about a very real annual expense line. And against an annual cost, a one-off investment to reduce it becomes a business decision like any other.
Step 3: negotiate, talk risk and opportunity cost
With numbers in hand, the negotiation changes nature. Three levers work particularly well:
Opportunity cost. “As long as we do not address this, every new feature costs 30% more. Investing now means accelerating everything that comes after.”
Risk. Some debts do not just slow you down, they threaten you. An unmaintained dependency, a security hole, a single point of failure. Here the argument is no longer speed but the probability of a costly incident.
Increment, not big bang. Rather than demanding a three month freeze, propose a recurring budget: for example 15 to 20% of team capacity dedicated continuously to debt reduction. That is infinitely easier to accept, and far less risky, than a big rewrite.
A simple framework for prioritizing
Not all debts are equal. I sort them on two axes: impact (how much it costs us or threatens us) and effort (how much it costs to fix).
| Low effort | High effort | |
|---|---|---|
| High impact | Do it now | Plan and break it down |
| Low impact | Opportunistic, when passing by | Ignore, and own the choice to ignore |
The most important quadrant is the last one: deciding not to pay down a debt is a perfectly valid decision, as long as it is conscious and owned. Dangerous debt is the debt you suffer without ever having chosen it.
When debt is the right choice
To close, a counterpoint. Wanting zero technical debt is as naive as wanting zero financial debt in a company. A startup searching for its market is right to take on technical debt to move fast: nobody cares about the code quality of a product nobody uses.
Maturity is not about avoiding debt. It is about knowing when to take it on, making it visible, and paying it back at the right time. Exactly like financial debt.
It is precisely that shift, from “the code is messy” to “here is our debt strategy,” that separates a developer from a trusted business partner.