The problem with technical debt is, in my experience anyway, that decisions have such a delayed impact that it's difficult for a group of people to understand cost and benefit. To work with the example you gave: You can tell that losing 60% of engineering staff didn't have a negative short term impact. How about 5-10 years later? How fast can the org move at that time vs if they had more staffing and less technical debt?

The whole idea behind the concept is that it _can_ be a good business decision to reduce spending (i.e. new features) and focus on paying off your (technical) debt for a while. It might as well be more important to make progress in the short term, no matter the cost. But the important point is that it's not a technical decision, it's a business decision. And the whole metaphor of technical debt is just one way of moving the conversation to that level.

If you had said ”tech debt typically isn’t as big a deal as engineers think it is” I would’ve agreed with you, but ”tech debt isn’t a thing” is hyperbole to such a degree that it stops being helpful, never mind true. I realize that the former is not as pithy. And I think you agree, given your last paragraph.

For example, I’ve seen companies where tech debt has made them unable to meet the moment and fail, whereas if they could’ve delivered something better, quicker, they might have had a lot of success.

Neither of these points argue that tech debt isn't a thing, just that it's impact is poorly understood.

Companies have plenty of real debt, but still grow. Accumulation of tech debt might be a necessary cost much like servicing financial debt.

Now the question really is - what is the interest rate of your tech debt? And that's harder to know.

Not being able to use the shiniest version of everything isn't tech debt, it's brownfield development or maintenance mode. Using deprecated versions (beyond LTS), ignoring security advisories, and not replacing unmaintaned OSS packages are. It's a bit facile to reduce all of that to developers just being juvenile divas.

In some cases, tech debt is as small a threat to business continuity as IT security is. That is, it isn't a problem till it's suddenly a massive problem. In other cases, it causes development cost to slowly increase over time, at which point it depends whether the organisation/cash flow can bear it. Your proverbial moat, or perhaps corporate momentum.

I would question whether incurring tech debt is generally really part of a greater strategy at the organisational level. It's a symptom of myopia. In any place I've worked, it wasn't a balancing act, but rather being willfully ignorant about the application lifecycle, technology, security implications and knock-on effects. No one said "let's move fast and fix 'er up later". At least not in earnest.

This is hyperbole and based upon anecdotal evidence.

As a counterpoint I've been part of a company that "failed" due to overwhelming tech debt. I was one of the "lucky" few that was kept on after the redundancies in what was a shell of the former company (50 employees down to 10).

I should have left with everyone else but I had only just started at the company 3 months prior and didn't want to look like a job hopper.

Bologna. I've seen monstrous tech debt all over my Fortune 250, and it's pushing us further and further away from competitiveness and profitability. And it's not just the approach to software. They're also sabotaging long-term strategic viability by only hiring product engineers who are fresh grads from overseas, who never stay in one position long enough to develop or pass on institutional knowledge. Unfortunately/fortunately, it's a business that is ultimately doomed in the face of newer technologies that WILL, eventually, take over our market, so I guess it won't matter. However, I still think we could turn the corner of renewable tech if we hadn't sacrificed properly investing in people and tools. But that would have required serious leadership from several C-levels, and, well, that's just not how the world works.

"Well, who could have seen this coming?"

"Uh, me. 20 years ago."

Tech debt is a thing for any non-trivial product. The more tech debt, the slower it is to create working increments of a product and the more risky changes are.

I have experienced products of which the development has ground to a halt due to the system having such complex interconnections that every change required everyone in every meeting to assess the impact of a change. The root cause was constantly churning out MVPs with no thought of architecture and no overall management of the product or teams. I was the architect hired to clean up the mess.