How do I make the case to pay down technical debt?

You manage tech debt, and the hard part is not the fixing; it is convincing others to spend time on it when new features are always shouting louder. That is a real and constant tension. Debt is invisible until it breaks something, and it is hard to argue for the invisible. The mistake is arguing in technical terms to people who think in business terms. Saying the code is messy does not move them. Showing that a messy area is slowing every new feature, or risking an outage that costs customers, does. Translate the debt into the language of time, money, and risk that decision-makers already care about. Pick your worst area of debt and, before your next planning meeting, tie it to something concrete: how much slower it makes the team, or what it could cost if it fails. Bring that, not a complaint about quality. When the cost of not paying is made visible, the case makes itself.