Bus factor. What happens if the knowledgeable lead developer gets into an accident? What happens if they retire? More realistically, what happens when they burn out because it's so hard to hire other team members and so they can never really take a vacation and have to take their pager everywhere with them? That's why businesses optimize for headcount.

I have yet to encounter positive solutions to those questions, as usually increasing headcount does not relieve pressure on team members - it's used to enable quicker replacement by yet-another-junior-to-burned-at-the-altar who will leave after gaining experience and burning out.

The classic "we have niche languages" solution to that is to enable on-the-job learning of those, and not just doing simple fact checking on whether someone honestly claimed to have learnt Popular Language X as claimed on their CV.

Incompetent managers certainly believe they're hedging for bus factor by increasing headcount.

In practice, it doesn't work. For any given product there's still always a small/solo core team.

Don't optimise your business for mediocrity.

There's probably a link to monolith and distributed systems here. You gain way more resiliance when you get more people in your team, but what was once a thought firing in the brain of someone is now two people talking, which is order of magnitude slower. But on the flip side, you can probably handle more things in general this way.

The interview sort of answers this:

> Because we operate a lot in Latin America, I trained non-lisper engineers who speak Spanish on how to program Lisp

So they grew their lisp heads from raw human. That's not an overhead most companies would readily accept.

I think here he is talking about "integrators" - engineers who write in DLisp rules to process documents.

Hiring thousands of developers is a success metric now.

Management is still one of the fastest ways to a high paying job. Managers get rewarded (implicitly or explicitly) for being in charge of more people, either with better pay in the same position or by appearing to be more competitive when going for promotions. This creates a perverse incentive where someone can make decisions which promote a higher headcount at the cost of actual capability or efficiency.

It's often not even deliberate. No one sits down and says, "This language or tool kit requires a higher headcount, so I'll select it for my project". But they aren't motivated to find a more efficient approach that results in them being put in charge of a smaller team (because this would cost them and not reward them).

EDIT: Some grammar things.

It's also a way to hedge risks. If you've got a single programmer working on something, they're a single point of failure and they also have huge leverage (which can be good or bad depending on the person and circumstances).

Not that middle management bloat isn't a thing...it definitely is. But I don't think it's as black-and-white as it's made out here.