Technical debt is the most undermanaged cost in most engineering organizations. It appears in backlogs, in engineering estimates, in the slow tail of every release cycle. It does not appear in the portfolio review, which is why it is never funded until it becomes a crisis.
The intervention is straightforward: treat technical debt reduction as a program. Name it. Scope it. Assign it an owner and a milestone. Put it in the portfolio review next to the feature work. That is the only way it gets the resource conversations it deserves.
The business case is not technical. Engineering leaders already know the debt is real. The audience for the business case is the product and business leadership that controls the roadmap. For them, the argument is: this debt is adding N weeks to every feature the team ships in this area. Reducing it buys back N weeks per quarter, which is worth more than the features I delay to do it.
Quantify the debt in units leadership understands. Not lines of code or test coverage percentages. Weeks of engineering time lost to workarounds and incident response. Cost of the incidents themselves. Velocity compared to teams without the debt. Those are the numbers that produce budget conversations.
At Roku, I made the case for three months of focused payment infrastructure work as a program, not as backlog. It was approved because the framing was correct: the alternative was not shipping the debt fix, it was continuing to pay the debt tax on every quarter that followed. Framed that way, the investment was obvious.