To me it always seemed obvious that adding more people decreases efficiency; it's just a matter of communcation:

With more people, it takes more effort for knowledge to spread, so you either spend that effort (which reduces efficiency), or you have people doing their jobs without information that could make them more efficient (which reduces efficiency).

I've heard arguments that adding administrative staff is worse than adding other sorts of staff, but that is not as immediately obvious to me.

It depends how you measure efficiency.

5 people can produce 10 widgets in a year.

10 people can product 15 widgets in a year.

Are the 10 people less efficient than the 5?

If you need 15 widgets, the team of 5 has 0% efficiency.

The difference is this:

If I hire 15 people, I can produce 20 widgets

If I hire 15 people + 5 lower-skill workers, I can produce 30 widgets.

The problem we face is visibility. The question becomes how is it that low-skilled workers can create more efficiency, they themselves don't do anything. The reality is that high-skilled workers are now free to get creative vs having to do the annoying tasks the low skilled workers just took off their shoulders. So _indirectly_ the low-skilled workers produced 10 widgets, but really, everyone was just working at a good production level.

People being less busy lets them be creative.

Oh, there are many reasons we have large organizations, and one of them is that you simply cannot do some things with a small team. I think you have to bend the definition of efficiency to it's breaking point to argue that producing 15 widgets with 10 people is more efficient than producing 10 widgets with 5 people though.

A Honda Fit is clearly a more fuel efficient car than an F1 racer. This remains true whether or not the problem you are solving is "win an F1 race," which would necessitate using the latter.

Actually an F1 car is extremely fuel efficient. In absolute terms it consumes more gas but considering the generated power they are probably one of the most efficient engines around.

As with many other rules of thumb, this rule is usually true, unless there's a specific circumstance that makes it not so.

If you just add more administrative stuff together with other people and specialists that already have n*(n-1) links between them, this will be a problem due to obvious reasons.

However, if you actually spend time to work out a process and organization that will not require additional each-to-each communication and make most of the communication remain in close groups, you may avert this. You can call this a human refactoring, if you will - very similar idea to separate functionality into small, encapsulated classes with smalles possible public interface instead of one huge g-d class.

> However, if you actually spend time to work out a process and organization that will not require additional each-to-each communication and make most of the communication remain in close groups, you may avert this. You can call this a human refactoring, if you will - very similar idea to separate functionality into small, encapsulated classes with smalles possible public interface instead of one huge g-d class.

I dont think this is an exception to my rule; you can reduce the overhead significantly with good process, but any process that does not perfectly predict who needs to know what information will incur some per-person overhead as a team grows.

Perhaps you are arguing that this overhead can be reduced to the point of being close enough to zero to not matter? If so, that would be very impressive, and conflicts with my experience.

(N(N-1))/2

Admin or support staff in any job is just like those who work in logistics. They're the grease which makes the machine work. The underappreciated heroes of most orgs.

This is true. When I was more junior I arrogantly believed that project managers and marketing people and business development and customer liaisons and all those various other support staff were overhead—baggage that only cost the company money and slowed down development. I believed that software would just leap from my fingertips onto store shelves, without help from any of this administration. Only after trying one of these roles did I realize how much would grind to a halt without this overhead. I know the view sounds self-serving but these folks really are the grease that moves projects along and the duct tape that holds everything together as they move.

It seems to me that the people creating the processes have increased in numbers while the people doing the work have become less. In my company they try to be "lean" so you have book your travel and do a lot of other admin stuff. But there are still a ton of rules. The only difference is that now every worker needs to learn them instead of having one admin person dealing with them.

Adding more administration to reduce the number of management seems like a good trade, simply because management-days cost more than administrator-days. If 7 managers are each spending one day on a task that would be done twice as quickly by an administrator paid half as much, you're trading 7 manager-days for 1.75 manager-days completely disregarding the cost of manager context-switching.

And if you're that administrator, you probably don't need to justify your purpose, you should probably ask for a raise.

I'm not sure where else economies of scale are supposed to come from.

I don't think bureaucracy is bad per se -- it's an inevitable development in large organizations. Or rather, not inevitable, but better than the alternatives. Bureaucracy, with its attendant paperwork, procedures, and audit trails, retards the growth of personal fiefdoms and makes individual parts of a larger organization behave more like each other. It also retards forward progress, but I think that's part of the cost of having a large organization. Big ships are slow to turn.

Big ships are slow to turn.

Small ships can't handle big cargo.