Navigating technical debt conversations: how to prioritize and get buy-in

Technical debt is the silent killer in many organizations. At work, we're constantly battling to prioritize it against new features, and more often than not, the features win. This leads to increasing developer friction, more bugs, and slower delivery times. We've started trying to quantify the impact of our tech debt. For example, by tracking wasted developer time on known brittle modules or linking specific incident causes to debt areas. It's hard to put an exact number on it, but showing that `X` hours per week are lost due to a messy payment processing module helps make the case. We've also experimented with a '20% time' allocation for engineers to tackle debt, but that often gets eaten by urgent feature work. One tactic that's had some success is bundling debt reduction into feature work. If we're touching a legacy service for a new feature, we build in refactoring and modernization as part of that project scope. It's not ideal, but it's better than nothing. How do others effectively champion tech debt initiatives and get leadership to allocate resources?