"Technical Debt" is a surprisingly self-explanatory term. I have used it to great success with my management team when arguing for time for refactoring, code reviews, and other non-user facing work.
Exactly. technical debt is a great tool for explaining to non-technical management why you'd want to invent time in refactoring, reviews etc that have no obvious tangible result in the finished product (short version: it's a drag factor makes it harder to add features and keep the bug count down later).
It's also a good tool to allow the management to do what management does best: take the technical information and make management/financial decisions based on it, on how much investment can be made now.
It turns a binary either/or choice: devs saying "Our code is bad, we need to rewrite" into a quantitative one: "How much technical debt do we have? Is it increasing? Can we reduce it?".
