How big should our technical debt budget be?

Start at 15–20% of engineering capacity per sprint. If you’re running hot (MTTR > 1h, change fail rate > 15%, error budgets burning), bump to 25–35% for two quarters and review. Pair with 1–2 quarterly debt epics funded like product features.

How do we prevent engineers from relabeling features as debt?

Define a taxonomy, require a brief Debt RFC for anything >2 days, and have EM/PM co-approve. Audits during the monthly portfolio review catch drift.

What if product refuses to give time to debt?

Make it a leadership policy tied to SLOs and risk. When error budgets burn, features freeze. Put PMs in the monthly portfolio review so they see the ROI.

How do we quantify ROI credibly?

Automate DORA and SLO metrics, quantify incident minutes saved, and track cloud and licensing cost reductions. Use a simple model, show baselines, and report over 30/60/90 days.

We have a lot of AI-generated code. Where do we start?

Run CodeQL and Sonar to identify duplication and low maintainability hotspots, create a weekly ‘AI cleanup’ lane, and enforce quality gates in CI. Tie cleanup to observed bugs and incident patterns for immediate ROI.

Can we do this without adding headcount?

Yes. Use a fixed capacity budget, automate detection (Renovate/Dependabot, Sonar, CodeQL), and be disciplined about quarterly investments. You’ll reinvest the time you save.

Culture · Nov 22, 2025 · 10 minute read

The Tech Debt Budget Your CFO Won’t Kill: Turning Cleanup into ROI Your Board Can Read

Stop negotiating debt work sprint by sprint. Set a real budget, measure returns like a portfolio, and make it part of how you lead—not a side quest engineers beg for.

Back to all posts

The Tech Debt Budget Your CFO Won’t Kill: Turning Cleanup into ROI Your Board Can Read

Key takeaways

Implementation checklist