We keep ignoring tech debt because the business wants new features. How can I support continuous improvement by getting stakeholders to care about technical debt? I know that if we don't fix it, we will slow down, but I can't prove it with our current reporting. Are there metrics that specifically highlight the cost of technical debt to the business?
Technical debt is quantified by tracking defect density per component, measuring the increase in cycle time for identical feature types over time, and calculating the financial cost of escaped defects versus initial development investment.
3 answers
Stop calling it technical debt. The business doesn't understand debt; they understand interest payments. When you frame it as a backlog of features, you are just an obstacle. When you frame it as a tax on every future feature, you become a partner in risk management.
You want metrics? Forget story points. Those are purely internal velocity measures and they mean nothing to a VP of Sales. Instead, track these three indicators:
- Defect Density per Component: Highlight the areas of the codebase that are constantly breaking.
- Cycle Time Degradation: Show how long a story took to move through the pipe six months ago versus today.
- Escaped Defects: Quantify the cost of support and hotfixes compared to the initial development cost.
If a feature today takes twice as long to build as it did last year because the code is a house of cards, show them the delta. Don't frame it as fixing broken code. Frame it as increasing the velocity of the organization. If you cannot explain why the feature is late using these numbers, you haven't identified the debt; you have just identified a messy codebase. Stop asking for permission to refactor and start reporting on the rising cost of delivery.
Your frustration is shared by every engineering team that has failed to articulate value in business terms. To secure stakeholder buy-in, you must shift the conversation from technical maintenance to risk mitigation and delivery predictability. Stakeholders fear the unknown, so you need to provide transparency into the 'hidden' costs of your current development state.
I recommend implementing a Capacity Allocation model. This requires a formal agreement where a fixed percentage of every sprint—say 20 percent—is explicitly reserved for non-functional requirements and technical refinement. If stakeholders refuse this, document the opportunity cost of every major production outage or delayed release cycle caused by systemic complexity. By explicitly labeling these incidents as results of technical debt, you create a tangible feedback loop that even the most feature-obsessed product owner cannot ignore.
Furthermore, conduct a Developer Experience (DevEx) survey. If your team is frustrated and slowing down, their turnover will cost the business more than any refactoring project ever could. Retaining talent and maintaining a steady flow of value are direct business objectives. When you link code quality to talent retention and predictable time-to-market, you move the conversation from 'fixing code' to 'protecting the business asset' which is a much easier sell in the boardroom.
Let us be real: you are asking for permission to do your job. The business wants features, and you are currently giving them features while ignoring the foundations. Of course they will push for more features—you have not given them a reason to do otherwise.
You need to instrument your delivery pipeline. If you do not have data, you are just another engineer complaining about code quality. Start by tracking your Lead Time for Changes and your Change Failure Rate. These are two of the Four DORA metrics that correlate directly with organizational performance. If your Change Failure Rate is climbing because your technical debt is causing regressions, you have a financial argument. Every time you have to roll back or patch, that is money burned that could have been spent on the new features they actually want.
Stop asking for a dedicated sprint to fix everything. It will never happen. Instead, weave refactoring into the definition of done for every single feature ticket. If the code quality of the module is too low to implement the feature safely, that is an increase in the estimate. Be transparent about why a simple feature is now taking ten days instead of three. Let the stakeholders choose the risk, but make sure they see the price tag clearly before they approve the work. You do not need their blessing to maintain high standards; you just need to be honest about the cost of shortcuts.
This is a really helpful perspective, Dhruv. I’ve been struggling to explain this to my manager, and framing it as a tax on future features makes me feel much less overwhelmed.