Editorial Note: Technical debt gets talked about constantly but measured almost never. Michael Sun argues that treating it as a vague metaphor is why it never gets prioritized — and offers concrete frameworks for quantifying it the way you would quantify financial debt.
The Metaphor Is Holding You Back
Ward Cunningham coined “technical debt” in 1992 to explain to business stakeholders why shipping fast creates future costs. It was a useful communication tool. But somewhere over the past three decades, the metaphor became a crutch. Developers wave their hands, say “technical debt,” and expect the room to understand the urgency. The room does not, because the metaphor lacks precision.
When a CFO says “we have debt,” they can tell you the principal amount, the interest rate, the payment schedule, and the consequences of default. When a tech lead says “we have technical debt,” they usually cannot tell you any equivalent measure. They can point at code that feels bad, systems that seem fragile, and processes that are slow — but they cannot put numbers on the impact or the cost of remediation.
This is why technical debt rarely gets prioritized. It is not that business stakeholders do not care. It is that “we have a lot of technical debt” is not actionable information. “This debt costs us 15 engineering hours per week and the remediation requires 3 weeks of focused work” is actionable. The difference is measurement.
What Technical Debt Actually Is (and Is Not)
Before measuring technical debt, you need a clear definition. Not everything that frustrates developers is technical debt. A useful framework distinguishes three categories:
Deliberate debt: Conscious decisions to ship faster by deferring quality. “We know this caching layer should use Redis, but we are using an in-memory cache to hit the launch date. We will migrate after launch.” This is the original meaning of Cunningham’s metaphor — a known shortcut with a planned repayment.
Accidental debt: Design decisions that were reasonable at the time but became problematic as requirements evolved. Your monolith was the right architecture when you had 3 endpoints. Now you have 200 endpoints, and the single deployment pipeline takes 45 minutes. Nobody made a bad decision — the context changed.
Bit rot: Degradation from neglect. Dependencies that have not been updated in two years. Tests that were disabled “temporarily” and never re-enabled. Documentation that describes a system that no longer exists. This is the interest accruing on debt nobody is tracking.
What is not technical debt: code you do not like, patterns you would not have chosen, technologies that are not your preference. “We should rewrite this in Rust” is not a debt statement — it is a preference. Technical debt has a measurable cost. Aesthetic disagreements do not.
Measuring the Principal: What You Owe
The principal of technical debt is the estimated effort required to bring a system to its ideal state. Measuring it requires breaking the debt into specific, estimable items.
The Debt Register
Create a living document — a spreadsheet, a Notion database, a dedicated Jira board — that catalogs every known piece of technical debt. Each entry should include:
- Description: What the debt is, specifically. Not “messy code in the auth module” but “the authentication service has no separation between session management and user validation, causing all tests to require a full database setup.”
- Location: Which files, services, or systems are affected.
- Estimated remediation effort: Person-days to fix. This does not need to be precise — a t-shirt size (S/M/L/XL) is better than no estimate.
- Category: Deliberate, accidental, or bit rot.
- Date identified: When the debt was first recognized.
- Owner: Who is responsible for tracking and eventually remediating this item.
The act of cataloging debt is itself valuable. Teams that maintain a debt register make better prioritization decisions because they can see the full picture rather than responding to whatever feels most painful this week.
Quantifying Effort
For estimation, I recommend a simple three-point scale based on your team’s capacity:
- Small: 1-3 person-days. Can be fixed in a single sprint alongside feature work.
- Medium: 1-2 person-weeks. Requires dedicated allocation but not a full project.
- Large: 1+ person-months. Requires project-level planning, likely a dedicated team or sprint.
Sum these estimates across your debt register and you have a rough principal amount expressed in engineering time. A team with 40 person-weeks of accumulated debt has a very different strategic picture than a team with 4 person-weeks.
Measuring the Interest: What It Costs You
The interest on technical debt is the ongoing cost of not fixing it. This is where most teams fail at measurement — they track the debt but not its carrying cost. Interest manifests in several measurable ways:
Velocity Tax
How much slower does your team move because of existing debt? The most practical way to measure this is to track, for each sprint or cycle, how much time was spent on work directly attributable to technical debt: workarounds, debugging fragile systems, onboarding friction caused by complexity, deployment delays from poor infrastructure.
If your team consistently spends 20% of each sprint fighting fires caused by known debt, that is your interest rate. A 5-person team losing 20% of capacity is losing one full engineer’s output — permanently — until the debt is addressed.
Incident Correlation
Track which production incidents are caused by or exacerbated by known technical debt. If your on-call rotation generates 10 incidents per month and 4 of them trace back to documented debt items, you have a concrete measure of the debt’s operational impact. Multiply incident count by average resolution time and you have hours lost per month.
Lead Time Impact
Measure how long it takes to ship a typical feature, and how much of that time is attributable to navigating around debt. If deploying a simple API endpoint takes 3 days instead of half a day because the deployment pipeline is brittle and the test suite is unreliable, the delta is your interest payment on infrastructure debt.
The Debt Ratio: A Metric That Matters
Combine principal and interest into a debt ratio that leadership can understand:
Technical Debt Ratio = Weekly interest cost / Total team capacity
If your team has 200 person-hours of capacity per week and spends 30 person-hours on debt-related work, your debt ratio is 15%. This single number communicates the urgency better than any qualitative description.
In my experience, teams with a debt ratio below 10% can manage debt opportunistically — fixing items as they encounter them. Teams between 10-25% need deliberate allocation — reserving a portion of each sprint for debt reduction. Teams above 25% are in crisis — the debt is compounding faster than they can address it, and feature velocity will continue to degrade until they make debt reduction a primary focus.
Prioritizing Repayment
Not all debt is worth fixing. Just as financial debt can be strategically useful, technical debt is sometimes worth carrying. The question is not “should we fix this” but “what is the return on fixing this versus building something new?”
The Interest-to-Principal Framework
For each debt item, calculate the ratio of weekly interest cost to remediation effort:
Priority Score = Weekly interest hours / Remediation person-days
A debt item that costs 5 hours per week and takes 3 person-days to fix has a priority score of 1.67. An item that costs 2 hours per week but takes 20 person-days to fix has a score of 0.1. The first item pays back its investment in less than a week. The second takes months. Prioritize accordingly.
This framework also identifies debt that should not be fixed. If a messy module costs the team 15 minutes per week and would take 2 weeks to rewrite, the payback period is over 2 years. Unless you have other reasons to fix it — security, scaling needs — it is rational to carry that debt.
The Allocation Model
Once you have prioritized your debt, you need a sustainable allocation model. The most effective approach I have seen is a fixed percentage allocation:
- Healthy teams (debt ratio under 10%): Allocate 10% of sprint capacity to debt reduction. Fix items opportunistically when working in related areas.
- Strained teams (debt ratio 10-25%): Allocate 20% of sprint capacity. One engineer per sprint should be dedicated to debt work.
- Critical teams (debt ratio above 25%): Allocate 30-50% of capacity until the ratio drops below 20%. This requires executive buy-in, which is why having the numbers matters.
Selling It to Stakeholders
The financial framing works because business stakeholders already understand debt. When you say “our technical debt ratio is 22%, which means we are losing one full engineer’s output to interest payments every week, and the three highest-priority items can be fixed in 8 person-days and would recover 12 hours per week,” you are speaking a language that executives understand.
Compare this to “we have a lot of tech debt and need time to fix it.” The first statement gets budget approval. The second gets a polite nod and no action.
Key Takeaways
- Maintain a debt register that catalogs every known piece of technical debt with specific descriptions, locations, effort estimates, and owners. Vague awareness is not management.
- Measure your interest rate — the weekly cost of carrying existing debt in engineering hours lost to workarounds, incidents, and slowdowns.
- Calculate your debt ratio (weekly interest / total capacity) and use it to determine the appropriate allocation strategy: 10% for healthy teams, 20% for strained, 30-50% for critical.
- Prioritize repayment by ROI, not by severity or annoyance. Fix the items with the highest ratio of weekly interest cost to remediation effort first.
- Present debt in financial terms to stakeholders. Numbers get budgets. Metaphors get sympathetic nods.