Engineering Manager's Guide to Tech Debt

Focus on outcome metrics, not activity metrics. Track deployment frequency, change fail rate, and debt resolution velocity at the team level -- not individual commit counts or lines of code. Use automated tooling like SonarQube or CodeClimate to surface trends without requiring developers to self-report. Run anonymous quarterly satisfaction surveys. The goal is visibility into system health, not surveillance of individual contributors. When developers see that metrics are used to improve their working conditions rather than judge them, they become allies in measurement.

The widely used starting point is 15-20% of sprint capacity allocated to debt reduction and maintenance. There is no published tier table that tells you the right number for your team, so treat that figure as a starting allocation and adjust it against your own baseline: raise it while you are paying down severe debt, lower it once the friction is gone. Start by measuring your current implicit debt spend -- the time lost to workarounds, slow builds, and incident response. Many teams discover they are already spending far more on debt-related work than they realize, just invisibly. Making the allocation explicit gives you control over where that time goes instead of letting it be consumed by firefighting. See Measuring Tech Debt for how to establish that baseline.

Treat debt reduction as a first-class work item, not an afterthought. Include debt stories in sprint planning alongside feature stories. Use the Boy Scout Rule for opportunistic fixes during feature work. For larger efforts, negotiate with product: "If we spend 2 sprints on the checkout module, the next 5 features in that area will ship 3x faster." Frame it as an investment with measurable returns, not a tax on delivery. Track velocity before and after debt sprints to prove the investment pays off -- this data becomes your ammunition for future allocations.

Generally no. Dedicated debt teams create two problems: (1) The rest of the organization stops feeling responsible for code quality because "that is the debt team's job," and (2) the debt team lacks context on how code is actually used in production. Instead, embed debt reduction into every team's workflow. Each team owns the debt in their domain. For cross-cutting concerns like dependency upgrades or infrastructure modernization, form temporary working groups with members from affected teams. This spreads knowledge and keeps everyone invested in quality.

Resistance usually comes from one of three places: past trauma where quality initiatives were punitive, legitimate time pressure where they genuinely cannot afford the overhead, or lack of understanding about why it matters. For trauma, start small and show that this time is different -- quick wins that visibly improve their daily experience. For time pressure, reduce scope rather than cutting quality. For understanding gaps, show the data: "Your team spends 40% of time on incidents. Teams with lower debt spend 15%. That difference is 10 hours per week per engineer." Make the case personal and practical.

Show 5 metrics maximum -- executives tune out after that. Lead with (1) deployment frequency trend showing improvement, (2) change fail rate to demonstrate quality gains, and (3) feature velocity to prove debt reduction accelerates delivery. Add (4) developer satisfaction scores to show team health, and (5) cost savings or revenue impact for the financial story. Always show quarter-over-quarter trends with your baseline highlighted. Include one specific example: "We reduced checkout bugs by 80%, saving $6K per month in support costs." Concrete stories make abstract metrics memorable.