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

we're a small startup, and technical debt conversations are perpetually deprioritized in favor of new features. it's a common story, i know. but it's starting to really hurt: our deployment pipeline is fragile, debugging is slow, and we're seeing more incidents directly caused by outdated code or shoddy architecture. i've tried advocating for dedicated 'tech debt sprints' but they usually get cut. i'm looking for more effective ways to quantify the impact of technical debt and get buy-in from product and leadership. simply saying 'it's bad' isn't cutting it. i've thought about tracking wasted engineering time, linking specific incidents to technical debt, or proposing a 20% time budget for engineers to tackle debt. what are your best strategies for navigating these conversations and actually getting resources allocated to address technical debt? have you found success bundling debt reduction work with new features, or presenting it as a direct blocker to business goals?