Build a technical debt triage framework

Technical Debt Has an Interest Rate — Treat It Like a Loan

"Tech debt sprint" is a losing frame — it asks for permission, and permission gets denied quarter after quarter. Atlassian's agile estimation writing and The Pragmatic Engineer's research both argue that tech debt should be treated like financial debt: every piece has an interest rate (how much it slows every future ship in the affected area) and a principal (the one-time cost to fix). Compounding debt — where the interest rate grows quarterly — is the dangerous kind.

How the Build a technical debt triage framework Prompt Works

The prompt builds a debt inventory with interest rate, frequency, and compounding flags, then computes quarterly cost per item so the team can argue for repayment on ROI grounds. The 20% running allocation rule replaces the doomed "debt sprint" pattern; the exception to 30% for high-interest items gives the team flexibility without asking for permission each quarter.

When to Use It

• Feature velocity is declining in one part of the codebase.
• Engineering is spending increasing time on on-call without rising complexity.
• A "debt sprint" proposal is stuck in leadership review.
• A platform rewrite is being debated and debt numbers would inform it.
• New engineers take 3+ weeks to become productive.

Common Pitfalls

• Asking for a debt sprint. Permission gets denied. Build repayment into the running allocation.
• Paying low-interest debt first. Low-interest debt feels satisfying to clean up but does not change delivery velocity.
• Treating all debt equally. Compounding debt is categorically worse than flat debt. Prioritize accordingly.

Sources

• Agile Estimation — Atlassian
• The Pragmatic Engineer — Gergely Orosz
• The Pragmatic Engineer Newsletter — Gergely Orosz
• Embracing Agile — Harvard Business Review