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