Technical debt: how to explain it to someone who signs the cheque

As a speed tax, not a code smell. Take a small, comparable change and compare how long it took a year ago against how long it takes now. When 'add a field to the order' goes from two days to two weeks, you have a number a CFO understands. Code-quality dashboards produce numbers nobody outside engineering can act on; delivery slowdown produces one everybody can.

Stop saying the code is messy — that is not a business case. Translate it into three things a board already budgets for: delivery speed, outage risk and hiring cost. The last one usually closes it. Nobody good wants to maintain a codebase they cannot set up in an afternoon, so if your best developer leaves and cannot be replaced, the debt has stopped being an engineering problem and become an existential one.

Usually not, and we will say so even when the project would be ours to run. A three-month cleanup with no visible outcome gets cancelled in month two, when something urgent appears and nothing shippable has come out of it. Attach the cleanup to the feature that touches that code anyway. It gets funded because the feature is funded, and it gets tested by real usage instead of by hope.

No. The ugly module nobody has touched in three years, that never breaks, is fine — leave it alone. Interest only hurts where you keep borrowing, so repay debt in the code you are still actively working in. Rewriting stable code that nobody reads buys you nothing except the risk of breaking something that currently works. Ugly and untouched is a perfectly acceptable end state.