It’s mostly a software development term. Bugs are the most obvious kind of tech debt. They have to be fixed or a product will slowly become unusable over time, so when you release something with bugs you’re incurring “debt” they must be “paid” later by fixing them. A lot of tech debt also involves corner cutting and bad design decisions that are hard to explain briefly.

Implementing a software feature takes a certain amount of time, and time translates pretty directly to money. Sometimes, you may need to meet a deadline or run out of budget, so you end up implementing the feature at a lower quality or without completing the usual checks or constructing it in such a way that nothing else can be built on top.

This allows you to meet the time/money constraints, but it will come back to haunt you, either making the implementation of future features more costly, or requiring the mess you left behind to be cleaned up, before trying to build on top.
As such, it feels a lot like you’re taking up ‘technical debt’, which you’ll have to pay for later.

Months and years of “eh, good enough” finally catching up with you

It’s the cleaning up of code by making it easier to read or rewriting something in a less convoluted way. Originally you just wanted it to be done quick so you coded it in a sloppy way. Now you have “debt” that needs to be fixed. You don’t really gain anything by cleaning it, so it wastes your time instead of implementing something new.

Technical debt means how much work it takes to update legacy solution to a modern solution. E.g. each time a new C++ standard is used, all code written with the old standard should be checked. The work time needed to do this is paying up the technical dept.

Now, if you are lazy, and didn’t clean up the code, used the easy and sloppy solution, next time you have twice the work to be done. So the dept gets worse, if you do nothing.