By Vaibhav Verma
Technical debt is abstract until it's quantified.
You tell your CEO: "We have too much technical debt." They ask: "How much does it cost?" You don't know. You give a vague answer. They approve nothing.
Here's how to quantify debt and make the case for fixing it.
The Framework
Cost of Debt = Time Spent Managing Debt * Engineer Cost per Hour * Opportunity Cost
Let's work through a real example.
Example: A 30-Person Engineering Team
Step 1: Measure Time Spent on Debt
Have your engineers track time for 2-4 weeks. Not obsessively. Just rough estimates.
"How much time this week did you spend on:
- Feature work
- Bug fixes
- Technical debt reduction
- Infrastructure/process
- Interruptions/firefighting"
Based on 2 weeks of data, a 30-person team looks like:
- Feature work: 50%
- Bug fixes: 15%
- Technical debt: 20%
- Infrastructure: 10%
- Firefighting: 5%
That means: 20% of 30 engineers = 6 full-time equivalents (FTE) are working on debt.
Step 2: Calculate Annual Cost
6 FTE * $150,000 annual all-in cost = $900,000 per year on technical debt.
Note: use all-in cost (salary + benefits + overhead), not salary.
Step 3: Calculate Opportunity Cost
6 FTE could be building features instead. Your product team could ship 40 features per quarter with that capacity.
Instead, they're shipping 35 features per quarter because 6 engineers are tied up in debt.
That 5 feature gap has business impact. Depends on your model:
- If each feature generates $100K in annual value: 5 features * $100K = $500K in lost revenue
- If each feature improves retention by 0.5%: 5 features * 0.5% * customer base * ARPU
For this team, let's assume: $400K in lost revenue from features you can't build.
Step 4: Total Debt Cost
Direct cost: $900,000 per year Opportunity cost: $400,000 per year Total: $1,300,000 per year
That's the cost of technical debt to your company.
The Payoff Case
Now you make the investment case:
"If we spend 3 months (12 engineer-weeks) refactoring our database layer, we free up 1 FTE permanently. Here's the ROI:
Cost: 12 engineer-weeks * 3 engineers * $2,880 per week = $103,680 Benefit: 1 FTE * $150,000 * 5 years = $750,000 Benefit: Can ship 6 additional features next year = $600K in value Total benefit: $1,350,000
Payback period: 7 weeks. ROI: 1,200% over 5 years."
That's board-ready math.
Common Numbers
Based on typical engineering teams:
- Monolithic architecture: 25-35% of time on debt
- Modular architecture: 15-20% of time on debt
- No test coverage: 30-40% of time on debt (includes rework and firefighting)
- Good test coverage: 10-15% of time on debt
- Single-person knowledge silos: 15-25% of time on debt
- Distributed knowledge: 5-10% of time on debt
If your numbers are lower, you're either very healthy or not measuring accurately.
Why This Matters
When you can quantify debt in dollars, you can make investment decisions.
$1M per year in debt cost is too much. Spend $200K on refactoring and reduce it to $500K/year. That's a $300K/year win.
Without quantification, debt is abstract. You can't make business decisions on abstract problems.
The Hard Part: Causation
The tricky part is proving causation. "Our database is slow, so we can't build features" is true. But proving it quantitatively is hard.
Approach:
-
Identify the constraint. "Our payment system is monolithic, making it hard to add new payment providers."
-
Estimate the impact. "Each payment provider we add should take 1 week. Currently takes 3 weeks because of the monolith. That's a 2-week cost per feature."
-
Estimate frequency. "We plan to add 3 payment providers next year. That's 6 weeks of additional cost."
-
Calculate the value. "Each provider generates $50K in annual value. 3 providers = $150K. But we lose $150K in revenue because the work is too expensive."
-
Calculate the fix cost. "Rearchitecting the payment system: 8 weeks, 2 engineers = $30K."
-
Make the case. "We invest $30K now, free up $150K in revenue next year. Payback: 2.4 weeks. Do it."
Tools to Help
With Glue, you can visualize technical debt across your codebase. Which systems are complex? Where's the architectural constraint? What's slowing down your team?
Visibility into debt types and locations makes quantification easier.
The Bottom Line
Technical debt costs real money. Quantify it. Make the investment case. Fix the high-cost debt.
Here's the formula for any engineering leader:
"We're spending $X on technical debt annually. We can reduce it by $Y by investing $Z. Payback period is N weeks. Let's do it."
Repeat quarterly. Fix the highest-ROI debt first. Watch your team's velocity increase.
Frequently Asked Questions
What if our engineers won't track time? Then ask them to estimate. "In a typical week, what % of your time goes to debt?" Get estimates from 5-10 engineers and average. Not perfect, but good enough for business decisions.
What if debt is spread across many small things? Then you probably have 25-40% of your time on debt. You don't need to quantify each small thing. Make the aggregate case: "Our engineers report 25-30% of time on debt management. At our cost structure, that's $X per year. We should invest in reducing it." Start with the biggest bottlenecks.
How do we measure opportunity cost of lost features? Based on your metrics. ARR per feature? Customer lifetime value per new feature? Churn reduction per feature? Use whatever metric you track. If you don't track it, that's a bigger problem than technical debt.