“Why can’t we ship faster?” is a question most engineering managers hear weekly. The honest answer is usually some combination of hiring, scope creep, and tech debt. Of those three, tech debt is the one EMs control most directly — and the one product partners understand least. Negotiating debt-pay-down work without losing trust or the team is a core EM skill.
What product hears when you say “tech debt”
To product, “tech debt” often sounds like:
- “Engineering wants to rewrite something for fun”
- “Engineering wants to use a new framework”
- “Engineering doesn’t want to ship features”
This is not because product is dim. It is because they have been burned. Many “tech debt” sprints have produced nothing visible. EMs who keep using the term unmodified are starting from negative trust.
Reframe: debt is a velocity tax
Translate every debt request into business language:
- “Our deploy pipeline takes 90 minutes; halving it gives every engineer 2 extra ship-days a quarter”
- “Test flake rate is 8%; eliminating the top three flakes recovers 4 person-weeks of investigation per quarter”
- “Our database has no indexes for query X; query latency went up 3x in three months and is on track to page within six weeks”
You are not asking for time to clean up. You are presenting a quantified velocity loss with a quantified fix.
The 80/20 budget
The most defensible model: 80% feature work, 20% engineering health. Some quarters will be 100/0 because of a launch; some will be 60/40 because debt has compounded. The average over a year should be 80/20.
Document the budget at planning time. When product asks for 110% feature work in a sprint, you have a clear conversation: “We can do that, but we draw down the health budget; here is what we will defer and the cost in a quarter.”
Distinguish kinds of debt
- Velocity debt: slow build, slow tests, flaky CI. Highest leverage; easiest to justify.
- Reliability debt: known fragile components, missing monitoring. Justify with incidents and on-call hours.
- Security debt: aging dependencies, unpatched libraries. Justify with risk frameworks; compliance often makes this non-negotiable.
- Architectural debt: the big rewrite. Hardest to justify; often deferable; sometimes you have to ship the new alongside the old.
How to make the ask
- Bring numbers. “Cycle time has increased 40% this quarter” beats “code is messy.”
- Tie to a roadmap goal. “Without this fix, we cannot hit the Q3 launch.”
- Show the alternative. “If we do not fix X now, the next 3 features in this area will each take 30% longer.”
- Present a scoped plan, not a vague “we want to clean up.”
- Promise a measurable outcome and report against it after.
Reporting wins
The most common EM mistake on debt is ship-and-forget. Always close the loop with product and leadership:
- “We invested 2 sprints in CI this quarter. Build time went from 23 min to 8 min. We expect 3 weeks of recovered engineering time per quarter going forward.”
- “After the auth library upgrade, we eliminated three security advisory tickets and reduced login-related on-call pages by 60%.”
- Bake these into your QBR. Repeated wins build credit for the next ask.
The conversations you cannot win
- “We have 6 weeks to ship for board demo.” Take the debt, plan to repay it.
- “The CEO wants this rewrite stopped.” Escalate to your manager; do not litigate alone.
- “Sales promised this customer in two weeks.” Triage the request, not the debt budget.
What separates senior EMs from staff/director
Junior EMs ask for debt time and feel guilty when denied. Senior EMs frame debt as risk and quantify it. Staff/Director EMs build a recurring health budget into the planning cycle so the conversation is not a per-sprint negotiation.
Frequently Asked Questions
What if my team feels overwhelmed by debt and product is not budging?
Document. Bring the team’s own data — survey results, cycle-time numbers, on-call pages. Take it up the chain together with your manager. If the org genuinely will not invest in health, that is a leadership signal you should weigh.
How do I prevent debt in the first place?
Definition of done that includes monitoring, tests, docs. Cap concurrent in-flight work. Reward good cleanup PRs publicly. None of this prevents debt; all of it slows accumulation.
Should I have a recurring “tech debt” sprint?
Bad framing. Bake the work into the regular planning cadence as part of the 80/20 budget. A separate “debt sprint” creates a fiction that the rest of the time is debt-free.