Basically when you "move fast and break things" eventually all those broken things catches up to you

Technical debt is any technical decision you make where you'll certainly have to "pay for it" later. Folks here have pointed out that one version of this is in not following best practices and letting things get done in a lazy or hacky way that will need to be fixed later for the system to reliably operate correctly etc.

But there are a lot of other ways in which technical debt can occur. For example, if you organize your work in a way that neglects documentation, you're taking on technical debt for keeping your system working when there is turnover or promotions. Anyone coming in who has to now improve on or fix that system will have to make (sometimes wrong) guesses, try to figure it out by studying the system in painful detail, or just plain not know how it works and have to work around it, all of which takes way, way more time and resources than just having the people that originally did the work write down documentation.

Similarly, many people take on technical debt by being lazy in specifying how something is supposed to work in the first place. They believe that it doesn't really matter because they're trying to "move fast", but usually this means they move fast aimlessly, wasting a ton of time and resources because their thinking and communication is unclear. Very often this kind of person asks others to build a very general-purpose system or one that they can control without having to have a clear idea of what it's supposed to do, which is its own form of technical debt, as those systems are always overly complicated and difficult to understand.

Basically, I think technical debt is thought of as taking an easy option that makes it so you have to do even more work later, but in my experience the "easy" option isn't even easier, it just works around managers / leads that don't know what they want or how the problem domain functions. "Just fix it by X date" instead of "fix it properly" usually belies a lack of understanding of the problem in the first place and of failing to plan and check in properly on work as it was happening originally.

The other poster is correct, but less exaggerated is

"when you bring in a new change to a technical system, you need to allocate time and resources to cleaning up after yourself, cause shit is gonna be broken. Could be big obvious things (should be planned for, but shit happens), could be that you patched over something with a temporary fix and it needs something more robust, also could be fringe cases that you aren't gonna know about for a couple months/years. The point is that every change you make incurs some debt to pay back, and you need to account for it if you want your system to keep running smoothly/relatively smoothly ".

SV techbros sometimes come in with the "move fast and break things" mentality, which is ok-ish (don't be afraid to mess up if you're genuinely trying to make things better), but you need to keep your house in order. Otherwise you're just building a tower of cards that's gonna collapse all at once beyond repair cause you're just moving fast and breaking thinga without allocating the time to stabilize them.