Management debt is when you create social or organizational policies that solve the immediate problem but will create morale, personnel, or legal issues later. The concept comes from an a16z essay:

https://a16z.com/2012/01/19/management-debt/

Other examples might include tolerating an aggressive status-based "brogrammer" culture, institutionalizing long working hours, or instituting gatekeepers that can block launches to avoid specific issues that have bitten you in the past.

I've worked at two startups that were killed by technical debt, and founded one. The way it usually manifests is that the startup fails to get to product/market fit before the complexity of its codebase prevents any further progress. These failures usually happen early in the startup's lifecycle (before many people have heard about them) and are often chalked up to failure to find a market, but the reality is often that if they could've iterated in days instead of months they would've found a winning product. Frequently a competitor started a few years later comes in with a simpler approach, leveraging building blocks that have already gotten mainstream vetting, and takes the market. (For more prominent examples, there's projects like General Magic, Apple Copland, Windows Longhorn, Chandler, and Friendster.)

That’s because when technical debt kills a company, they attribute it to something irrelevant. Imagine Wikipedia, for example, and the great “Wikipedia has Cancer” post[1]. You might conclude, if Wikipedia fails, that it couldn’t secure enough funding, even if a significant amount of time and money was spent on dealing with operational issues that shouldn’t exist. In my experience with Mediawiki and scaling up a wiki, I feel that it suffers intolerably from technical debt, even being state of the art as far as wikis go.

Here’s a good example. Many modern websites have task queues to perform background tasks. So, too, does Mediawiki. You may assume it uses RabbitMQ or another queueing software, but nope, it stores the queue in MySQL (acceptable) and by default it runs cronjobs at the end of requests (less acceptable.) As your wiki grows, these jobs take longer and longer and happen more and more. Suddenly you are wondering why pages hang and you always run out of PHP FPM workers.

Then you look at the stack traces and it makes more sense... so you go to configure cronjobs. Except, there’s not really a great fix. You can tune the parameters so that the queue effectively never progresses, but then you have to run the jobs manually - which is fine, but there’s no task running daemon or anything. Actual cronjobs work but are catastrophic for responsiveness. So... one of the recommended solutions is a shell script that loops and runs the runJobs.php file repeatedly. This solution works, but from an operations standpoint it’s not a wonderful solution. You probably want at least some visibility into what’s going on, and bash scripting is hardly the best platform for that kind of thing.

Of course, this is just one microcosm of Mediawiki, you can run into one technical debt related issue per day and you’d not run out for years.

[1]: https://en.m.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost...

Companies with high technical debt don't die suddenly they are prevented from adding new features. What kills the company is a change in the world that the system cannot adapt to because the debt.

> I agree financial debt can kill a company. I'm not familiar with what management debt is.

> But I don't know of any companies that were killed by technical debt.

I would imagine the failures of those companies are attributed to other causes. Is it hard to imagine a company with a low bus factor being in an unrecoverable state if a key person leaves? The time it takes to get a new person up to speed could cause the business to cede ground to a competitor, just as a for instance.

Technical debt doesn't (usually) cause "quick death" to companies.

I think a good analogy is that technical debt is like having a poor diet - if you don't fix it you end up with diabetes and other issues. Sure they're treatable, but it becomes harder and harder to continue innovating.

When all is said and done, you don't know for sure if that poor diet was what lead to a companies demise - but there's no way it helped them.

It's not the prima facie cause but a lot of issues can be traced back to technical debt. Being out maneuvered by a competitor and just losing customers can be because it was too difficult to produce new features due to technical debt.

Take a look at Knight Capital for a case study -- tl;dr, they deployed an update that accidentally triggered a blind spot in their trading system which had been inactive for almost a decade. By the time their engineers were able to stop it, Knight was on the hook for several billion dollars' worth of trades and had to close their positions for a loss of almost half a billion dollars. From my understanding they ended up merging with another firm to cover their losses so while they weren't entirely "killed", they were still severely kneecapped by tech debt.