I've thought a lot about why technical debt seems to be such a hard concept for non-engineers to grasp; certainly given how few business people or managers seem to understand it, it clearly must be difficult. I think it's because A) it only affects a truly long-lived, stateful process, like a software (or many other types of engineering process) where the output of one phase is the input to the next phase and B) there just aren't that many sorts of processes that occur in ordinary life.

Sure, in any field you can screw up in such a way that it hurts you in the future by damaging your reputation or annoying your customers, or make bad technical investments that turn out to cost you. But in engineering disciplines, doing your core activity (engineering) poorly can hurt your ability to keep doing your core activity (engineering) in the future.

If you're in sales and you cut corners with one client, it doesn't make your phone calls take longer. If you're in a restaurant and you cook things too fast or cut corners on ingredients, it doesn't make your future cooking take longer. If you're a doctor and you're too hasty and mis-diagnose a patient, it doesn't make your future surgeries and checkups take longer. But in software, if you're too hasty adding feature A, it does make your future features take longer to develop. And that's because in software, your future features are built on the previous ones, whereas with sales, cooking, or medicine the duration of any given prospect/customer/patient is relatively short-lived and finite.

That's my best theory as to why it's so hard for non-engineers to understand.