What’s a realistic starting debt budget for an enterprise product team?

If you’re already feeling pain (incidents, slow delivery), start at **20% capacity** for product teams and **40%** for platform/SRE. Then revisit quarterly using MTTR, change failure rate, and lead time trends. If leaders can’t tolerate 20%, they’re already paying it in outages—just off the books.

How do we stop debt work from turning into endless refactoring?

Require an **interest signal**, an **expected outcome**, and a **sunset date** for every debt epic. If you can’t say what improves (MTTR, CI time, spend, audit findings), it’s probably aesthetic refactoring. If it doesn’t pay back by the sunset date, re-scope or kill it.

How do we measure ROI when benefits are risk reduction?

Use proxy metrics executives recognize: days on unsupported runtimes, count of critical CVEs open > X days, audit findings, and incident frequency tied to known weak points. Pair each with a target (e.g., “unsupported runtime days → 0 this quarter”) so progress is visible.

Does this work with AI-generated code and ‘vibe coding’ workflows?

Yes—arguably it’s more important. AI-generated code often increases maintainability and delivery debt (hard-to-test modules, inconsistent patterns). Treat cleanup as debt epics with characterization tests, measurable outcomes (change failure rate, lead time), and a tight sunset date. That’s how you avoid permanent ‘AI sludge’ in the codebase.

Culture · Dec 21, 2025 · 8 minute read

The Debt Budget That Stopped Our Roadmap From Lying to Us

Technical debt doesn’t kill teams. Pretending it’s “free” does. Here’s how to budget it like a real enterprise, measure ROI without theater, and build rituals leaders actually stick to.

Back to all posts

The Debt Budget That Stopped Our Roadmap From Lying to Us

Key takeaways

Implementation checklist