What percentage of engineering capacity should we allocate to tech debt?

Start with 15% per team for two quarters. If your SLOs are red, build times exceed 30 minutes, or incidents are rising, move to 20–25%. Keep defects and P0 incidents separate from this budget.

How do we handle urgent security patches or EOL upgrades?

Treat them as risk-class debt and pre-approve a standard change path with CAB. If a date cliff is within the quarter, escalate capacity or deprioritize feature scope. Don’t borrow from next quarter’s debt budget unless you plan to pay it back with interest.

What metrics convince the CFO?

Quantify developer-hours saved (CI, lead time), incident-hours avoided (MTTR, incident rate), and cloud run-rate reductions (CUR). Convert to dollars with conservative loaded rates and show the before/after graph. Tie all savings to tags and tickets for audit.

We tried “Tech Debt Fridays.” It fizzled. What’s different here?

Fridays fail because they’re optional and unplanned. A budgeted portfolio with intake, triage, and ROI tracking is part of the plan, not a hobby. It survives reorgs and holidays because leaders defend it and Finance sees the returns.

How does this work with SAFe/PI planning?

Allocate the debt capacity inside each team’s PI plan, tag features that enable piggyback debt reductions, and expose register items on program boards. Keep the weekly triage to protect the allocation between PIs.

Culture · Oct 9, 2025 · 10 minute read

Stop Treating Tech Debt as Charity Work: Budget It and Prove the ROI

What’s worked for me in real enterprises: concrete rituals, leadership behaviors, and numbers your CFO will respect. No fairy dust, just repeatable mechanics.

Back to all posts

Stop Treating Tech Debt as Charity Work: Budget It and Prove the ROI

Key takeaways

Implementation checklist