Personally I (a developer) use it most as a metaphor for business people explaining why we need to schedule time in-sprint for work that isn't explicitly tied to a new feature.
We have debt, we need to service it. Repayments come in the form of developer time. If our debt is well-serviced it enables us to keep up a nice quick pace of feature development.
If a feature is politically important and our tech-debt is under control we can fast-track its implementation knowing that we'll have time to polish it up later and it isn't likely to break too much.
If our debt is too high we can't borrow anymore. Sorry, that super important feature that the board wants by end of sprint simply can't be done. We're at our credit limit and if we try and borrow more to get that done we'll go bankrupt (the product crashes and burns).
We have debt, we need to service it. Repayments come in the form of developer time. If our debt is well-serviced it enables us to keep up a nice quick pace of feature development.
If a feature is politically important and our tech-debt is under control we can fast-track its implementation knowing that we'll have time to polish it up later and it isn't likely to break too much.
If our debt is too high we can't borrow anymore. Sorry, that super important feature that the board wants by end of sprint simply can't be done. We're at our credit limit and if we try and borrow more to get that done we'll go bankrupt (the product crashes and burns).
All of this is the language of business