Product leadership keeps deprioritizing infrastructure tech debt work in favor of features, and the debt is now visibly slowing down every new feature. How do you actually change this dynamic?

The recurring failure is usually that tech debt gets pitched in engineering terms ("this code is messy," "we need to refactor") rather than in terms product leadership can actually weigh against feature value — the fix is translating the debt's cost into the same currency features are evaluated in: how much slower is feature delivery now because of this debt, quantified concretely, and framed as a trade-off leadership is already implicitly making every time they deprioritize it, whether they realize it or not.

The core communication gap is that "tech debt" as commonly pitched is an engineering-internal concept, while feature prioritization decisions are made by weighing business value against cost — if tech debt is never translated into that same cost/value language, it will structurally keep losing to features that are pitched in terms leadership can directly evaluate, regardless of how real or severe the debt actually is.

Quantify the debt's actual cost in delivery terms, not just describe it qualitatively: rather than "this system is a mess," measure and present something concrete — feature X took 3 weeks longer than estimated specifically because of workarounds needed for this debt; the team spends roughly N hours per sprint on debt-related firefighting instead of feature work; a specific recent incident, traceable to this debt, cost M hours of response and cleanup. Concrete, measured numbers are far more persuasive and actionable for a prioritization decision than a general sense that "the code is bad."

Frame it explicitly as a trade-off already being made, just implicitly and invisibly: leadership deprioritizing debt work isn't actually choosing "no cost, more features" — it's choosing to keep paying an ongoing, compounding cost (slower delivery, more incidents) in exchange for not investing engineering time now — making this trade-off explicit ("we can either invest 3 weeks now, or continue losing roughly 1 week per feature to this debt going forward, indefinitely") reframes the decision from "should we do unglamorous cleanup work" to "which cost do we want to keep paying," which is a fundamentally different, more evaluable question.

Show the compounding trajectory, not just the current state: debt that's actively getting worse (each new feature adds more to the same fragile foundation) has a different urgency than debt that's stable — demonstrating the trend (delivery velocity trending down over recent cycles, specifically attributable to this debt) makes the case for acting now rather than continuing to defer, versus a static "this has always been somewhat messy" framing that doesn't convey growing urgency.

Propose debt work framed in terms of its feature-delivery payoff, not as separate, competing work: rather than pitching "give us time to pay down debt" as a distinct line item competing against features, framing specific debt-reduction work as "this investment makes the next N features ship faster" ties it directly to the same value language features are evaluated in, making it easier for leadership to actually compare apples to apples rather than treating it as an entirely separate category of ask.

If leadership still deprioritizes it after an honest, well-quantified case, that may be a legitimate decision, not necessarily a failure to accept: sometimes, even with a clear cost laid out, the immediate feature pressure genuinely does outweigh the debt's cost for the business's actual current priorities — the goal of this approach isn't guaranteeing debt work always wins, it's ensuring the trade-off is actually being made deliberately and visibly, with real information, rather than debt losing by default because it was never presented in terms leadership could genuinely weigh.

• Tech debt pitched in engineering terms ("the code is messy") structurally loses to features pitched in business terms — translate the debt's cost into concrete delivery-speed and incident-cost terms leadership can actually weigh.
• Frame deprioritizing debt work as the trade-off it actually is (continuing to pay an ongoing, often compounding cost) rather than as a free choice with no downside.
• Show the debt's trajectory (getting worse over time) if applicable, since compounding debt has different urgency than stable debt, and this distinction matters for prioritization.
• Even a well-quantified case may still lose to feature pressure — the goal is ensuring the trade-off is made deliberately and visibly with real information, not guaranteeing debt work always wins.

• Martin Fowler: TechnicalDebt
• Google SRE Book: Eliminating Toil