At Salesken, we had a 'tech debt' label in Jira with 200+ tickets. When our board asked how much technical debt we had, I couldn't give them a number. That experience taught me that unmeasured debt is invisible debt.
By Vaibhav Verma
The best tools for managing technical debt in 2026 include SonarQube (static analysis), CodeScene (behavioral code analysis), Stepsize (debt tracking in IDE), Glue (AI-powered codebase intelligence), and CodeClimate (maintainability scoring). But tools alone don't solve the problem — you need a framework for translating technical debt into dollar costs that leadership understands. The most effective approach is measuring debt through three lenses: incident cost (MTTR × engineer hourly rate × frequency), velocity drag (percentage of sprint capacity consumed by debt-related work), and opportunity cost (features delayed by fragile code).
An engineering leader I know keeps a spreadsheet of every serious incident at her company. Incident name, severity, resolution time, affected module, which engineer worked on it. She doesn't do this because she's obsessive. She does it because she's trying to answer a question her CFO asked: "How much is this technical debt actually costing us?"
That's the question most engineering teams can't answer. They know they have debt. They know it causes problems. But when their CFO asks for a dollar number, they say "it's complicated" and the conversation stalls.
The conversation stalls because engineers and business leaders speak different languages. Engineers talk in code smells and coupling and technical debt ratios. Leaders think in costs. The question "should we refactor this module?" is a business question dressed up in technical language. The real question is: "Will the return on this work exceed its cost?"
If you can answer that, your CTO stops needing to convince your CFO. The math does it.
Three Categories of Debt Cost
Technical debt costs money in three ways. Measure these and you've quantified your debt problem.
First, the velocity tax. This is the cost of features shipping slower than they should. In a clean, well-understood module, a feature takes a certain amount of time. In a messy module with high coupling and unclear boundaries, the same feature takes longer. The difference is the velocity tax.
A real example: a team I worked with tracked this carefully. In their "clean" API service, a feature typically took five days of engineering time. In their "payments" service, a similar-complexity feature took three weeks. Same team. Same company. The difference was entirely architectural debt.
Multiply five-day features: 10 features a quarter in the clean service is 50 days of engineering time. Multiply three-week features: 10 features a quarter in the messy service is 150 days of engineering time. That's 100 days of difference. On a 15-person team, that's almost a quarter of your engineering capacity taxed by debt.
At a fully-loaded engineering cost of $200K per year ($10K per week), that's $200K in lost productivity per year. For a $500K refactoring project that took four weeks, you'd pay back the cost in lost velocity alone within a year.
Second, the incident cost. Technical debt concentrates risk. Messy modules are the ones where incidents happen. They're the ones where bugs hide. They're the ones where incident resolution takes forever because nobody understands what's happening.
Track incidents by module. You'll find that 60-70% of your serious incidents come from 15-20% of your codebase. That concentration isn't random. It's because those modules are the ones with the highest technical debt.
Now price an incident. The cost is not zero. There's the engineer time to diagnose and fix it. There's the customer impact - for B2B companies, this might be SLA penalties or account risk. There's the context-switching cost for whoever else is pulled in. For a SaaS company with $10M ARR, a one-hour outage can cost $5K-$15K in SLA penalties and customer churn.
A 60-person fintech company tracked this: they had an average of three serious production incidents a month. 40% of them happened in the same three modules - the modules with the highest technical debt. The average incident took 240 minutes to resolve. In a clean module, similar incidents took 60 minutes. The debt was costing them 180 minutes per incident, times 12 incidents a year, times 3 modules equals 5,400 minutes of engineer time. That's 90 engineer-hours. At full-loaded cost, that's $36K a year. Plus SLA penalties, which were another $50K-$100K a year. So debt in those three modules was costing them $86K-$136K a year in incident response and penalties.
Third, the attrition risk. This is the hardest to quantify but the most consequential.
Engineers leave bad codebases. It's not the only reason they leave, but it's a significant one. The replacement cost for a senior engineer is 6-12 months of salary plus 8-12 weeks of lost productivity for the rest of the team as they onboard the replacement. A senior engineer making $200K costs you $300K-$400K to replace.
If technical debt causes you to lose one extra senior engineer a year you wouldn't have lost otherwise, that's $300K-$400K that debt is costing you. In a team of 30 people, the odds that debt is contributing to losing one person a year is very high.
The Calculation
Here's the framework to quantify your debt:
First, estimate your velocity tax. Pick two modules: one you're happy with, one you're not. Track how long features take in each module. Assume the difference is debt cost. Multiply that difference by the number of features you ship in the messy module per year. Multiply by your fully-loaded engineering cost ($150K-250K per engineer per year).
Second, estimate your incident cost. Use three numbers: (a) your average incident resolution time, (b) your average cost per incident in SLA penalties or customer impact, and (c) the percentage of incidents that happen in your highest-debt modules. Multiply: (c) * (a) * engineer_cost_per_hour + (b).
Third, estimate attrition risk. Look at your last two years of attrition. Estimate what percentage was directly caused by technical debt - engineers will often say this explicitly in exit interviews. Multiply that percentage by your average senior engineer replacement cost. That's your annual attrition cost from debt.
Add them up. That's your annual technical debt cost.
A Concrete Example
A 50-person company with $10M ARR does the math:
Velocity tax: Two modules. Features in the clean API module take 8 days. Features in the messy billing module take 18 days. Difference: 10 days. They ship 12 features a year in the billing module. Cost per engineer-day: $2,000 (200K salary / 100 working days). Cost: 12 * 10 * 2000 = $240,000 per year.
Incident cost: Average incident resolution time is 180 minutes (3 hours engineer time). Incidents in the billing module take 240 minutes (4 hours) on average. Difference: 1 hour. They have 24 serious incidents a year. 50% happen in the billing module. Cost: 12 * 1 hour * $150/hour + 12 * $8,000 SLA penalties = $1,800 + 96,000 = $97,800 per year.
Attrition risk: They've lost 8 people in the last two years. Exit interviews suggest 2-3 were substantially motivated by technical debt frustration. Cost: 2.5 * $350,000 replacement cost = $875,000 per year.
Total annual technical debt cost: $240,000 + $97,800 + $875,000 = $1,212,800 per year.
Now, a four-week refactoring project that costs $160,000 in engineering time pays for itself in less than two months. It's insanely ROI-positive. And yet most teams don't do it because they can't see the math.
Why Most Teams Don't Do This Calculation
They don't do it because incident cost and attrition cost require connecting dots that don't obviously connect. An engineer leaving? There are a thousand reasons. An incident taking long? Okay, but how much of that is the code vs. the complexity of the issue?
The move is to not perfect the calculation but to do it roughly and conservatively. Underestimate the impact. Even with conservative numbers, the ROI on debt paydown is almost always positive. The velocity tax alone is usually enough.
The Board Conversation
When you can point to "$1.2M in annual debt cost," the board conversation changes. It's not "should we refactor?" It's "should we spend $200K to save $1.2M?" The answer is obvious.
Frequently Asked Questions
Q: What are the best tools for managing technical debt?
A: The best tools for managing technical debt include SonarQube (static analysis for code quality and security hotspots), CodeScene (behavioral code analysis that identifies hotspots by change frequency), Glue (engineering intelligence connecting debt to dollar cost via velocity tax, incident cost, and attrition risk), Stepsize (debt tracking integrated into your IDE and issue tracker), and CodeClimate (automated code review with maintainability scores). The key insight is that no single tool captures the full cost — technical debt's real expense comes from three sources: the velocity tax (slower feature delivery), incident cost (longer resolution times), and attrition risk (engineers leaving due to frustration). The best approach combines automated detection with a quarterly dollar-cost calculation.
Q: We don't track incidents well enough to do this calculation. How do we start?
Start simple. For the next month, ask every engineer after a production incident: "What percentage of your resolution time was spent understanding the system vs. fixing the actual bug?" Track that percentage by module. You'll immediately see which modules are opaque.
Q: Some incidents just take a long time because the problem is hard, not because of debt.
True. But hard problems in hard-to-understand code take even longer. The comparison between resolution time in a clean module vs. a messy module isolates for the debt cost specifically.
Q: How often should we recalculate this?
Once a quarter is probably right. This is your quarterly justification for debt paydown in your engineering budget. If your debt cost is $1M+ a year, you budget refactoring work accordingly.
Related Reading
- Technical Debt: The Complete Guide for Engineering Leaders
- Code Refactoring: The Complete Guide to Improving Your Codebase
- DORA Metrics: The Complete Guide for Engineering Leaders
- Software Productivity: What It Really Means and How to Measure It
- Code Quality Metrics: What Actually Matters
- Cycle Time: Definition, Formula, and Why It Matters