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.

You rarely need to say no outright. Frame debt work as enabling faster feature delivery. Instead of "we can't build Feature X because we need to refactor," say "we can deliver Feature X in 4 weeks, or we can spend 1 week improving the foundation and then deliver Feature X in 2 weeks -- plus every future feature in that area ships faster." Make it a trade-off conversation with data, not a confrontation.

Stop using technical terms. Never say "refactor," "code smell," or "design patterns." Instead, translate to business outcomes: "Our deployments take 3 hours instead of 20 minutes because of accumulated shortcuts." "We had 4 production incidents last month that were all caused by the same fragile subsystem." "New features in Module X take 3x longer than Module Y because of accumulated complexity." Numbers and incidents speak louder than jargon.

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.