If you're talking about Brooks's law, that's a pretty specific observation that doesn't seem like it applies here. It's very specifically about adding workers to a project that is already behind schedule. It doesn't certainly doesn't mean anything as broad as "a company cannot do more things by increasing its employee count."
But of the reasons Books gives, most apply regardless of the project being late, such as the communication overhead and the fact that splitting the project neatly is difficult.
Modern software projects are wildly different than OS/360.
The insights from 50 years ago is fine abstractly but it has its limitations.
Not only are there many more roles to fill but things like translation and QA scale pretty well.
It's an adage, not a hard and fast dogma.
Also it was specifically limited to when in the project people are added and often gets misremembered as some linear programming inspired exercise in optimal team configuration.
The latter is obvious and useful (right size the team for the job) but IIRC, Brooks doesn't actually address it in the famed literature.
I don't think I've ever worked on or even seen a software project that wasn't in some way considered behind schedule. Very, VERY rarely are the correct number of people hired at the beginning.
Sometimes it's more! You have nine projects you want to do. A, B, C, D, E, F, G, H. You have 2 developers. You hire 3 more. One of the new hires has more familiarity with what projects E and G needs than anyone on the existing team had. One of them is slower than the average of the existing devs. One of them is MUCH faster. The five of them complete those nine projects in three months (15 total people months, with boosts from one of the new dev's skills and the other's increased speed) when it may have taken 9 otherwise (18 total people months).
But I've seen a lot of companies not be quite that smart in their hiring...
(The faster scenario I've outlined above also potentially bites you in the butt if you don't have enough more valuable projects lined up behind that first set...)
There is a sweet spot for how many people should be on a team. That number depends entirely on a nature of tasks. I would even go as far as to say - in a good environment up to that sweet spot, productivity gain is linear.
And yes, managers do expect close to linear productivity gain past that spot. Managers, that are a little smarter, start thinking about how spotify did squad (without actually knowing anything about it).
The term "Two pizza team" comes from Amazon and describes a team size such that it is the number of people that can be fed by two pizzas. The reality is that the term is not only a reference to team size but, rather, underscores the concept of "Accountability".
What I was talking about is something like this: SRE team has 1 member and productivity of 1, that person is overworked and if vacation is taken productivity goes to 0.
Hire second person, after onboarding productivity goes to about 2 (i.e. linear scale). Hire third person, productivity will probably be a little under 3 because now they need to spend time to be on the same page. Vacation is still shaky because with such small team, knowledge will be 100% siloed due to outside performance expectations ("hey you worked on X last time, I'm going to assign this ticket to you" repeated many times).
Eventually team grow to a point where they can handle all work load, share knowledge between each other and take vacations without fear (btw if you fear taking vacations - don't, it's not your fault if team can't handle without you).
You can think of "work load + process" as a data structure. If work load is bog and process requires a lot of synchronizations (every meeting is essentially a Mutex for the entire team) - you won't get linear productivity increase, instead you will increase lock contention.
Large software orgs get around this by having multiple projects that are either loosely coupled or completely separate. Otherwise there’s be no point in hiring more than 10 engineers at any point.
I’ve actually spent a long time working at engineering orgs that run super lean. On the upside there are never layoffs, on the downside you’re really constrained on what problems you can tackle - and that can have some major (negative) business implications.
Anyway I can’t help but feel we are slowly reverting back to the aughts where people thought you could clone Google or whatever with like 5 engineers and didn’t understand why nobody took them seriously.
Headcount is a good way to justify a valuation given an investment round - and you have to spend the money chasing growth anyway whether it makes sense or not.
Too many business schools teach classes that claim that managers don't need to know the business that they're in. They just need to know the math. Then apply what comes out of "organizational psychology/sociology" courses to the remaining staff. And when a new CxO takes over, he brings in his cronies who puffed him up at the last place (aka "the new broom sweeps clean"). This is why software companies end up with mismanagers who don't know beans about programming.
I have my own distaste of "MBA Culture" but one thing I would not say is that they teach people to ignore the business and not learn it. From what I've learned, is completely orthogonal to what they teach you in any regionally accredited business school what you are asserting here.
Not all of that is dev. After a certain point, a lot of growth comes from marketing, sales, sales engineering, consulting, support, customer success, etc.
I'd wager most core engineering teams in a co like Apollo are probably quite small and focused. I'd guess the cuts are coming from the ancillary teams.
My comment was about the company as a whole, and slightly targeted more towards management. That said, you are right, dev usually has very little control over these kinds of decisions.
Far too often people are added to existing teams, as if they didn't believe Brooks' observations about communication.
Less often, but much better, are people being hired and put onto new teams, focused on new projects and products. Developers can scale horizontally, but not vertically.
There's a post-dotcom-bubble VC delusion that says that "growth" is the most important thing for an investor. Companies that can show growth, like Uber, are used as an example of "success," and "unicorn" becomes a thing that companies strive for.
So, companies did anything to show growth, which means marketing and incentives to acquire users, to adjacent services, to hiring more staff. I'm sure leadership either knew that this is what needed to be done to get more funding, or they actually drank the cool aid.
But...he's doing the opposite, he laid everyone off. If anything I think that should be encouraged, I remember Whatsapp had less than a hundred employees when they were bought for billions, same as Instagram. I feel like we should encourage embracing the maximum productivity per person rather than throwing more people, since as they said, it doesn't necessarily work.
Why should layoffs be encouraged though? Even if a corporation is bloated, I don't see why we should care if we aren't investors. It can even lead to cool stuff for everyone else, such as more open source tools and software that can usually be contributed by those "bloat" teams
I just like efficient systems, both programming and organizational. Having bloat so to speak just annoys me.
Making open source tools is not something I'd consider bloat, I'm talking more about those in the book Bullshit Jobs by David Graeber.
Having fewer people also leads to people achieving more, ie one company with 1000 employees versus n companies that are 1/n the size, I'd say the smaller companies are much more likely to produce innovations that are useful for society as a whole.
this seems more like a systems problem with a reinforcing and a balancing feedback loop: you're hiring for the future based on current demand, but there's a delay between the syncs of supplying capacity (hiring) and demand.
More hands /= more productivity, at least on a linear scale