I’d add to the other replies by saying that this isn’t just pure inefficiency - it’s the ability to try things and get them wrong without dying. Often several things. If one of them works out, maybe they justify the rest - just like investing in startups, ironically.

Second, it’s also about redundancy, having more employees covers you from key man syndrome where your operations could be adversely affected by an employee leaving. Even if it means you technically have more employees than you need at a bare minimum.

Third, I’d argue that the level of “efficiency” required by a startup simply isn’t sustainable in the long run, unless you want everyone to burn out. Successful companies likely span a spectrum of efficiency, but none of them need to be on the far efficient end like startups do, and that’s better for everyone working there.

>it’s the ability to try things and get them wrong without dying. Often several things. If one of them works out, maybe they justify the rest

Yep, just look at 3M for instance. They were already an established chemical manufacturer, but they could afford to have some people spend their time investing adhesives. One of these was a total failure for the desired application (they wanted a strong adhesive for aerospace, they got a weak but reusable adhesive), but then they spent more time looking for applications for this, and now everyone and his dog uses 3M Post-It Notes.

Once a company becomes successful, it attracts the second kind of people in Iron Law of Bureaucracy.

https://www.jerrypournelle.com/reports/jerryp/iron.html

Third, there's people who only value themselves and use the organization as an excuse.

This is probably the majority of cases, but it is beneficial to the organization, similarly to the Adams's Smith invisible hand.

It takes effort, requires goodwill, has damaging implications to internal politics and ultimately is not the best way to maximize tenure at C-level roles.

Executives are solving for their job, not for the company's success.

I think the main driver is a lot more simple than other people have said: when you don’t need that efficiency you can focus on resilience instead. As the pandemic showed with JIT supply chains, efficiency and resilience are often at odds. And the bigger you are the more resilience you want to protect your core business and let you just turn the fly wheel that’s making you profitable. That’s also why you see companies start to engage in monopolistic and anticompetitive practices - now that they have the weight they can waste resources on protecting their business instead of just growing it by being more efficient.

This is 100% bad from a country/market level but is what you get when you let local optimizations trump capitalism. In some sense that local optimization also isn’t bad - it’s not uncommon that that behavior is also what lets efficiencies be extracted.

In other words, in many ways all of this is inevitable behavior as things grow and a lot of it are themselves (perhaps inevitable) symptoms of the mechanics at play rather than the mechanics themselves.

In other words, once “founder mode” is documented, you’ll have everyone claiming they’re doing founder mode same as how everyone says they’re now doing agile or whatever other fad you want to pick and you’ll be back at square one until someone then invents “strategic founder mode” or “growth founder mode” and claims to have figured out how you can spot that vs what everyone is just pretending to do right now.

> As the pandemic showed with JIT supply chains, efficiency and resilience are often at odds.

I’m not convinced this is necessarily true. JIT implies making all of your buffers more obvious, and you will want to reduce unnecessary buffers to save cost, but maintaining some buffers for the sake of resilience isn’t incompatible with JIT supply chains. The problem comes when you combine short-term oriented management with JIT supply chains; if you quantify the cost of a buffer, you make it easier for that type of management to make that kind of decision.

Toyota, for example, is one of the firms that popularized JIT, but they don’t usually run into the same short-termist problems that afflict other firms. Relatedly, Toyota’s senior management have all spent decades if not their entire careers at Toyota and still includes members of the Toyoda family. Those guys are probably not going to play fast and loose with resiliency just to make quarterly numbers look good. They are going to look at the quantified and understood cost of their resiliency buffers and say, “removing this buffer might save lots of money next quarter but in the long run that represents a risk to a company I intend to pass down to my grandchildren so I won’t do it”. Whereas a different manager at a different company might say, “this will definitely make the next quarter’s numbers look amazing and if there are consequences in the long run, either I’ll have switched companies or I can just say it’s not my fault”.

> This is 100% bad from a country/market level but is what you get when you let local optimizations trump capitalism. In some sense that local optimization also isn’t bad - it’s not uncommon that that behavior is also what lets efficiencies be extracted.

Is it really 100% bad? Do people really think that the goal of humanity is to work in the most efficient way to extract the most economic value from everything possible? Can't we just be content being 50% efficient and use the other 50% of that effort to chill with family and friends and talk about films or something?

There are visible and invisible numbers, which are fundamentally at odds.

If your sole objective is to „number goes up“, you sacrifice everything which is not trivially quantifiable.

An upper-level employee wants many employees under them. Then they can argue for a higher salary and have a good line on their resume.

Maintaining a good structure is a cost on its own. A good analogy is how most many engineers think "if I spend two days writing documentation then I'll save one hour figuring out things later, resulting in net gain of negative fifteen work hours, great job".

Software "Engineers" thinking about creating documentation and actually creating documentation? Where? Usually I find "engineers" trying to use new unrelated tech to create more work for themselves and the company. Like adding the AWS stack to an Azure firm. Or the overzelous "perfectionist" starting with way too much abstraction to solve a simple problem. Real engineers get certificates, but software "engineers" range from over-glorified PowerApps developers all the way to the people who program medical devices and other life/death-grade solutions. The former never thinks about documentation and the latter has most all documentation provided or automatically generated.

> What are the disincentives to doing so (beyond the need for requiring more from people)?

Working out how to motivate people whose individual impact now has near zero impact on the stock price.