The Tech Lead's Guide to Managing Debt

The widely accepted target is 15-20% of each sprint. That gives you roughly one day per week per developer focused on debt. Start with 10% if your organization is resistant, and increase once you can show measurable improvements in velocity and incident rates. Never go to zero -- debt compounds when ignored, and catching up later costs exponentially more.

Yes, with a clear label. Keeping debt in a separate backlog makes it invisible and easy to deprioritize forever. When debt items sit alongside features, they compete for attention on merit. Tag them clearly (e.g., "type:debt") so you can filter and report on them, but let them participate in the same prioritization process. The exception is security debt, which should have its own fast-track process.

You cannot eliminate new debt entirely -- and you should not try. Some debt is intentional and strategic. Focus on preventing accidental debt through three mechanisms: code review standards that catch common patterns, automated linting and static analysis in your CI pipeline, and a team agreement on what "done" means (including test coverage and documentation). When someone does take a shortcut intentionally, require them to log it as a debt item with a remediation plan.

Escalate when debt crosses from engineering inconvenience into business risk. Specific triggers: security vulnerabilities in customer-facing systems, debt causing missed delivery commitments (not a one-time slip but a pattern), team attrition driven by frustration with legacy code, or a dependency reaching end-of-life with no migration plan. Bring data, not complaints: incident trends, velocity charts, and cost projections. Leadership responds to risk and dollars, not frustration.