Why Technical Debt Goes Unaddressed
The compound interest metaphor for technical debt is true but overused, and it has a problem: it is abstract. Stakeholders who allocate engineering budgets do not experience technical debt the way developers do. They see feature velocity declining without an obvious cause, incidents that engineering explains as "infrastructure issues," and a growing gap between what was promised and what was delivered.
To address technical debt, you need to make it measurable in terms stakeholders can act on. Here is how.
Measuring Velocity Trend
The most direct measure of technical debt cost is feature velocity over time. If your team delivered 12 features per sprint 18 months ago and delivers 5 features per sprint today with the same team size, the difference is the cost of technical debt expressed in engineering capacity.
Track story points or feature count per sprint over at least 6 months. If the trend is declining, plot it on a chart for your next stakeholder meeting. A declining velocity trend is not a team performance problem. It is compounding debt making the codebase harder to change. The difference between actual velocity and the baseline velocity from 18 months ago is the weekly cost of the debt in engineering hours.
Counting Manual Workarounds
Manual workarounds are hidden debt that most teams have not counted. The script that runs every Monday to fix data inconsistencies from a buggy integration. The deployment checklist that requires 15 manual steps because the CI/CD pipeline cannot handle the edge case in the payment service. The support team procedure for clearing a user's session when a known bug prevents login.
Ask your team to document every recurring manual task they perform that exists because of a technical limitation. Count the hours per week. Assign an hourly cost. This is concrete, measurable debt with a clearly calculable carrying cost.
Mean Time to Deploy
Measure how long it takes from a developer merging code to that code running in production. In a healthy system, this is minutes. In a system with significant infrastructure debt, it can be hours or days. Each hour of deployment delay is engineering capacity spent waiting rather than building.
Track this metric over time. MTDD (mean time to deploy) creep, where the number steadily increases over months as the deployment pipeline accumulates complexity and manual steps, is one of the most reliable indicators of infrastructure debt that is actively costing the business.
Cost of Incidents Caused by Debt
Some incidents are caused by technical debt: a lack of connection pool management causing a database connection exhaustion failure, a missing retry mechanism causing a data pipeline to silently drop records, a tightly coupled service causing cascading failures from a single component outage. These have a measurable cost: engineering time to diagnose and fix, plus the business cost of downtime or data loss.
Maintain a post-mortem log and tag incidents by root cause category. After 6 months, you can calculate what percentage of incident cost is attributable to technical debt versus unavoidable external failures. This is a number that lands with stakeholders.
Technical Debt Categories and Prioritization
Not all technical debt is equally expensive to carry. Prioritize by cost per week, not by engineering aesthetics:
- Infrastructure debt with high incident frequency and high recovery cost should be addressed first. The CI/CD pipeline that causes 2-hour deployment windows affects every deploy. The monitoring gap that means incidents run for 45 minutes before detection affects every production issue.
- Test debt in high-change areas should be addressed before or during a major feature development. The payment module with 8% test coverage that you are about to extend is higher priority than the notification module with 8% test coverage that has not changed in two years.
- Design debt in stable, rarely changing code can wait. A messy internal utilities module that works correctly and is rarely touched carries a low weekly cost.
- Documentation debt manifests as onboarding and context-switching costs. Measure by how long it takes new engineers to make their first meaningful contribution and multiply by your hiring frequency.
Presenting the Business Case
When presenting to stakeholders, translate every metric into one of two business terms: engineering capacity cost (hours per week multiplied by engineering hourly rate) or business risk cost (probability of incident multiplied by estimated incident cost). A 6-hour weekly velocity drag at $200/hour loaded engineering cost is $62,400 per year in capacity that is not delivering features. Present it that way.
FriendsBit has worked inside codebases at both ends of the debt spectrum, from clean systems with strong test coverage to legacy platforms where simple changes took weeks. If you need help quantifying the technical debt in your system or making the business case for addressing it, get in touch.