Blog / software
Technical debt, explained for owners
What developers mean by technical debt, how to budget for paying it down, and when carrying some debt is the right business call.
At some point a developer will tell you the project is slow because of "technical debt," and you will nod, and neither of you will be sure the other understood. This post is the translation.
I have spent twenty years around software teams, and I have watched this one phrase cause more owner-developer friction than any other. It deserves a plain explanation.
The building you already own
Forget the finance metaphor for a second. Think about a commercial building.
When you renovate a building, there are two kinds of work: the work the tenant sees, and the work behind the walls. A landlord under pressure can keep doing tenant-visible work (paint, fixtures, signage) while skipping the behind-the-walls work: the roof membrane, the aging panel, the plumbing that was "fine for now" three renovations ago.
The building keeps functioning. Rent keeps coming in. But every skipped repair makes the next renovation harder, because the new work sits on top of the old shortcuts. Eventually a simple job triggers a cascade: you cannot touch the wall without dealing with the wiring, and you cannot deal with the wiring without the panel. A two-week job becomes a two-month job, and nobody can point to a single decision that caused it.
That is technical debt. Software built under deadline pressure accumulates skipped behind-the-walls work: shortcuts in how data is stored, old libraries nobody upgraded, code that works but that only one departed developer understood. Each shortcut was individually reasonable. The pile is the problem.
The tell is the same in both worlds: estimates get worse. When "add a field to this form" comes back as a three-week quote, you are not being gouged. You are paying interest.
Debt is a tool, not a sin
Here is what a lot of technical-debt writing gets wrong: debt is not always bad. Businesses borrow money on purpose, because getting to market this quarter can be worth more than clean finances.
The same is true in software. Taking on technical debt to hit a real deadline, land a defining customer, or test whether a product is worth building at all can be exactly the right call. If the product fails, the shortcuts cost you nothing. Debt on a building you demolish was free money.
The debt that kills projects is the accidental kind: nobody decided to borrow, nobody tracked what was borrowed, and nobody budgeted the interest. Same as deferred maintenance on a building where nobody has walked the roof in ten years.
So the owner question is not "do we have technical debt?" Every real system does. The question is whether it was taken on deliberately and whether anyone is managing it.
How to budget paydown
You do not pay off a building's deferred maintenance in one heroic year, and you should not try it with software either. Big-bang rewrites are how migrations go wrong.
What works is boring: a standing allocation. Somewhere between 10 and 20 percent of development time, every cycle, goes to behind-the-walls work. The team chooses targets based on where the friction is worst, ideally the parts of the system you change most often. Paying down debt in code nobody touches is renovating a floor with no tenants.
Two rules make this stick. First, the allocation is not negotiable when things get busy, because things are always busy, and a paydown budget that yields to every deadline is not a budget. Second, ask the team to state each item in business terms: "this makes invoice changes take days instead of weeks" is fundable; "this code is ugly" is not.
If you cannot spare any capacity at all for this work, that is itself important information about your situation, the same way it would be for a landlord who cannot afford a roof inspection.
Questions that keep you honest
You do not need to read code to govern this. Ask your team, or your vendor, a few questions twice a year. Where in the system are estimates consistently worst, and why? What are we deferring on purpose right now? What breaks most often, and is that the same area? If our most senior developer left, what would nobody understand?
Vague answers are an answer. A team that cannot name its debt is not managing it, and the same logic I apply to keeping what you already have applies here: understanding the system you own is worth more than replacing it.
If you suspect your software carries more debt than anyone is admitting, and estimates or outages are starting to say so, I do independent fixed-fee assessments of exactly this. Start at my assessment page and tell me what you are seeing.