A CTO recently asked me how to convince their CPO and CEO to prioritise paying down technical debt. My answer was to stop calling it that. “Technical debt” is one of the most counterproductive metaphors in our industry, not because the underlying problems aren’t real, but because the term itself is actively working against you in every conversation where it matters most.
Consider your own relationship with debt. A mortgage is leverage. You carry it for decades because the asset (hopefully) appreciates faster than the interest compounds. A business loan is fuel for growth. Credit card debt is something you probably want to get rid of ASAP. Each form of debt carries a different risk profile, a different emotional response, and a different implied course of action. When you tell an executive that your team needs to “pay down technical debt,” you have no idea which of these mental models they’re applying to what you’ve just said. Some people are comfortable carrying debt strategically. Others have a visceral aversion to it. In some cultures, debt of any kind carries a stigma, and in others it’s seen as a desirable tool. You’re using a term that triggers an unpredictable and highly personal response… and then wondering why you can’t get alignment on the priority.
The ambiguity compounds when you consider that “technical debt” can mean many different things. The term covers everything from an engineer’s aesthetic preference for a different technology stack through to a system that will not survive the next twelve months (or days) of growth. Those are not the same problem. They don’t warrant the same response. Yet we’ve dumped them into a single opaque bucket and handed it to executives who have no way to distinguish between a desire to modernise and an existential risk to the business. This lack of specificity erodes trust. If everything is technical debt, then nothing is urgent, and requests to address it start to sound like engineers wanting time to think and tinker.
The fundamental problem, though, is that paying down technical debt is a net-negative pitch. You’re asking for weeks or months of engineering capacity and the outcome is that the system continues to do what it did before. Perhaps it’s more resilient. Perhaps it scales further. But there is no new revenue, no new customers, no measurable business metric that moves upward. You are asking people whose job is to allocate resources toward positive outcomes to invest in something that, at best, maintains the status quo. That doesn’t make good business sense, and an engaged executive will challenge you on it.
There’s a better way to frame this, and it starts with a better name. What you’re dealing with is a velocity tax. Every executive understands tax. It’s unambiguously something you want to reduce. It’s not a lump sum you pay off in a single project, but a drag on everything you deliver. That legacy authentication system your team spends thirty percent of every sprint working around isn’t technical debt. It’s a thirty percent velocity tax on every feature that touches authentication. It’s thirty cents in every dollar being spent on something that does not directly deliver the business outcome. That’s a number an executive can act on. It directly quantifies the impact on the thing they care about most: the speed, cost, and efficiency at which the business can deliver value.
The shift in framing should extend to how you approach the work itself. Going to your CEO, CPO, Director, etc, and asking for four weeks to pay down technical debt is the wrong approach. Instead, understand where you want to get to, map the incremental steps required to arrive there, and then attach those steps to the delivery work already on your roadmap. You’re not pausing to fix things in isolation. You’re ensuring that as you build the next feature, future iterations to that feature and its surrounding systems require only incremental effort without the overhead your team is currently burdened with. Sprint by sprint, you’re reducing the velocity tax, and you’re doing it in the context of delivering real business outcomes rather than asking the business to stop while engineering tends to its own concerns.
Stop saying technical debt. Start quantifying the velocity tax — the friction, the overhead, the drag on every delivery. Don’t ask for time to fix things in isolation. Show how you’re systematically reducing the tax rate on everything your team ships. Your executives don’t need to understand your architecture. They need to understand that every feature is taking longer and costing more than it should, and that you have a plan to change that, embedded in the work you’re already doing. Ship faster. Reduce the cost of change. Protect margins at scale. That’s not a tech debt conversation. That’s a growth conversation conducted by a senior technology leader.
