For most of my early career I talked about technical debt as if it were a moral failing, something sloppy teams accumulated and disciplined teams virtuously avoided. That framing is not just wrong, it actively harms the conversations that engineering most needs to have with the rest of the business. It turns a strategic discussion into a confession, and confessions do not get budget.
Reframing debt as a business decision changed how my teams talk to leadership, how leadership funds remediation, and how engineers feel about the shortcuts they take under pressure. Here is the reframe in full.
Debt is a tool, not a sin
The original metaphor is financial, and we should take it far more seriously than we usually do. In finance, debt is not inherently bad. Sometimes you take on debt deliberately because the speed or leverage it buys is worth the interest you will pay later. A mortgage is debt. So is the capital that lets a business grow faster than its cash flow alone would allow.
Technical debt works the same way. Shipping a slightly hacky integration to win a make-or-break customer can be exactly the right call. The failure is not taking on the debt. The failure is taking it on unconsciously, never writing it down, and then being surprised by the interest payments later when everything in that part of the system takes three times as long as it should.
The two kinds people constantly conflate
Most unproductive debt conversations happen because two very different things share one name.
- Deliberate debt: a known shortcut, taken consciously for a real reason, with at least a rough plan to repay it. This is healthy and often wise.
- Accidental debt: mess that accumulated because nobody understood the system, or had the time to do it right, or noticed it forming. This is the kind that actually hurts.
Treating deliberate and accidental debt as the same thing is why the conversation goes nowhere. One needs tracking and a payoff plan; the other needs a change to how you work.
When an engineer says "we have a lot of technical debt," my first question is always: which kind, and which of it did we choose? The answer reshapes the entire discussion.
How I frame it to the business
Non-technical stakeholders do not respond to "the code is messy." Why would they? It is not their code, and "messy" sounds like an aesthetic complaint from people who care about aesthetics they cannot see. They respond to consequences, expressed in their language.
So I translate. This debt means every new feature in this area takes thirty percent longer to ship. This debt means we carry a real and growing risk of an outage during the next peak load event. This debt means onboarding a new engineer to this service takes a month instead of a week. Now it is a business trade-off they can weigh against revenue and risk, not an engineering grievance they can safely ignore.
Making the cost visible and honest
Engineering's job is not to demand debt repayment as if it were owed. It is to make the cost of not repaying it visible, quantified, and honest. I keep a living register of significant debt items, each with an estimate of what it is costing us and what it would cost to fix. That register turns "trust me, we need to refactor" into "here is the interest we are paying and here is the principal."
The honesty part matters. If you cry wolf about debt that is not actually slowing anyone down, you spend credibility you will need when the debt is real. I would rather underclaim and be believed than overclaim and be tuned out.
Paying it down without a grand project
Big "refactoring quarters" rarely get approved, and when they do they often fail, because they front-load all the risk and back-load all the value, and something more urgent always interrupts them. I strongly prefer a steady allocation: a fixed slice of every cycle, perhaps fifteen or twenty percent, spent on the highest-interest debt, chosen by the engineers closest to the pain.
It is boring. It does not make a heroic story. And it compounds, which is exactly what you want from anything financial. A small, relentless payment against the highest-interest debt beats a dramatic one-time paydown that never quite happens.
Conclusion: a shift that pays off
When you frame technical debt as a business decision, two good things happen at once. Engineers stop feeling vaguely guilty about the pragmatic shortcuts that good engineering sometimes requires, and the business starts treating remediation as an investment with a return rather than a tax with no upside. That shift in framing is worth more, over the life of a system, than any individual refactor you could name.