I agree with pmjordan's answer, but thought I'd add an example: Your company's product log messages of some kind into a database. The developers were lazy, and put everything in one table with the classic "key, value" SQL antipattern. Subsequently, it was discovered that values weren't enough, you sometimes needed arrays of values (or hashes of values, or ...), so a (probably crappy) serialization format was written for the values so they could be arrays.
Suppose now you were hired in to this position and you actually do a lot about databases. Now, your company gets a call one day from your biggest customer that while they've been putting up with your product getting slower and slower over time (without telling you of course), it's finally gotten to the point where "queries take over an hour and we really need them in less than 5 minutes"/"our daily reporting process now requires more than a day to complete" (which means the system clogs up with nothing but reporting processes, eventually)/"we've been sued and the court has mandated that we turn over some data by next week and we compute it'll take two months"/"the CEO just tried a query that took an hour and now he wants to cancel the contract"... or so on, you get the idea.
This critical problem comes back down to you, and you realize that the only way to fix it is to entirely restructure the databases using better practices. Conceptually, this is trivial. However, since every single part of the system is built around this data system (and of course, there's no abstraction, everything uses the key/value store directly), the combination of the amount of time it would take to write the new schema, modify every program file in source control to use this new schema, write the migration script, and potentially even the time to run the migration script for the customer (during which time they will be off-line, which could be days, and which could be anything from unacceptable to impossible), oh, and testing, don't forget testing, could in fact be longer than your company can survive with a pissed-off major customer.
And if one customer is pissy now, it means every single other customer you have is a ticking time bomb.
(Everything in this message comes from things I've seen more than once in my professional career, except the hypothetical about getting sued (thank goodness). I'm not providing details because there are thousands of companies that could fill in the above!)
Your technical debt margin just got called. You couldn't cover it. It wasn't even your technical debt, but who cares? Buh-bye!
Suppose now you were hired in to this position and you actually do a lot about databases. Now, your company gets a call one day from your biggest customer that while they've been putting up with your product getting slower and slower over time (without telling you of course), it's finally gotten to the point where "queries take over an hour and we really need them in less than 5 minutes"/"our daily reporting process now requires more than a day to complete" (which means the system clogs up with nothing but reporting processes, eventually)/"we've been sued and the court has mandated that we turn over some data by next week and we compute it'll take two months"/"the CEO just tried a query that took an hour and now he wants to cancel the contract"... or so on, you get the idea.
This critical problem comes back down to you, and you realize that the only way to fix it is to entirely restructure the databases using better practices. Conceptually, this is trivial. However, since every single part of the system is built around this data system (and of course, there's no abstraction, everything uses the key/value store directly), the combination of the amount of time it would take to write the new schema, modify every program file in source control to use this new schema, write the migration script, and potentially even the time to run the migration script for the customer (during which time they will be off-line, which could be days, and which could be anything from unacceptable to impossible), oh, and testing, don't forget testing, could in fact be longer than your company can survive with a pissed-off major customer.
And if one customer is pissy now, it means every single other customer you have is a ticking time bomb.
(Everything in this message comes from things I've seen more than once in my professional career, except the hypothetical about getting sued (thank goodness). I'm not providing details because there are thousands of companies that could fill in the above!)
Your technical debt margin just got called. You couldn't cover it. It wasn't even your technical debt, but who cares? Buh-bye!