When to Run Tech Debt Interest
Five engineering moments when the compound cost number actually changes scheduling.
Tech debt is invisible until you make it visible. These five moments mean run the math and attach it to the ticket.
Engineering teams defer tech debt because it has no deadline. Attaching a compounded cost number gives it one. Run the math at these five moments and debt repayment stops losing to feature work by default.
Quick answer
Tech debt is invisible until you make it visible. These five moments mean run the math and attach it to the ticket.
Key points
- ▸ Before accepting any hack or shortcut: estimate the clean-fix hours and the postponed payoff. The gap is the "interest rate" you're agreeing to.
- ▸ When estimating a refactor: compounded cost at current month tells you what the fix is already worth. Compare to the cost at wait+6 to argue for scheduling.
- ▸ Quarterly planning: run on the top 5 known debts. Sort by payoff-at-end-of-quarter. Prioritize the ones compounding fastest.
- ▸ After a major feature lands on legacy code: velocity just spiked. Debt in that area is compounding faster — rerun and reschedule.
- ▸ Post-incident review: if tech debt contributed to an incident, quantify it. The payoff hours plus the incident cost tell the real story.
- ▸ Before handoff to a new team or contractor: unfixed debt compounds faster under unfamiliar hands. Either fix before handoff or explicitly budget for it.
Examples
- Accept-hack triggerProposal: 2hr hack vs 8hr clean fix. 12 months later at 8%/mo: hack is now 20hr payoff. Net time saved by hack: 2 - 20 = -18 hours. Unless velocity is low, pay the 8 now.
- Quarterly-planning triggerTop 5 debts compounded at end-of-quarter: 8, 22, 45, 60, 140 hours. The 140-hour one is a rewrite risk. Scheduling that one this quarter prevents it from becoming a 300-hour project next year.
- Post-incident triggerOutage traced to known-bad auth module. Payoff hours modeled at 30 six months ago — now 60 plus $X incident impact. Next sprint blocks off the refactor.
When to use which tool
- Tech Debt InterestRun at each trigger. Attach the number to the ticket — it's the only thing that beats feature pressure.Quantify the compounding hours to fix a shortcut as the codebase grows on top of it. Maintenance heatmap.
- Hire vs AutomateWhen evaluating whether to hire an engineer specifically for debt repayment, combine both tools.Should you hire a human at $X/hr or pay $Y/mo for a SaaS/automation stack? Efficiency bar comparison.
Related
- Tech Debt InterestQuantify the compounding hours to fix a shortcut as the codebase grows on top of it. Maintenance heatmap.
- Hire vs AutomateShould you hire a human at $X/hr or pay $Y/mo for a SaaS/automation stack? Efficiency bar comparison.
- What Tech Debt Interest CalculatesThe hours it will take to fix a shortcut in 6, 12, or 18 months — compounded by everything built on top of it.
- Five Tech Debt Interest MistakesThe errors that make compounded-cost math look exaggerated or irrelevant.
- What Hire vs Automate CalculatesThe monthly cost gap between hiring a human and buying the SaaS stack that replaces them.
Frequently asked questions
› How do I get product to prioritize debt? How-to
Turn debt into dollars or customer impact. Payoff hours × loaded engineer rate + expected incident cost = a number product leadership can weigh against feature work.
› Should every hack get this treatment? Trust & accuracy
No — only the hacks that touch actively-developed code or customer-facing paths. One-off scripts and dead code don't compound meaningfully.
› How should I use a decision framework in real life? How-to
Use a decision framework to expose the tradeoff, not to outsource the decision. Write down the inputs, compare the output with your constraints, then ask what would change the answer. The strongest use is scenario testing: base case, conservative case, and failure case.
› Is this financial, legal, or tax advice? Trust & accuracy
No, this is not legal, financial, tax, medical, or professional advice unless the page explicitly says that use case is supported. It organizes assumptions so you can inspect them. Verify high-stakes choices with qualified people who can review facts, contracts, regulations, and downside risk.
› What assumption matters most in a decision model? Edge case
The most important assumption is usually the one you are least certain about and most emotionally attached to. Change that input first. If the recommendation flips after a small change, the decision is fragile and needs more evidence before you treat the model as useful.