Hiring folks also increases the communication overhead. If you are a team of 3 and hire a 4th you now have a new person that needs trained, needs to learn tribal knowledge, asks the other 3 people different things and keeps them busy distracting them from what were doing - finding product market fit. Any more, I prefer lean & scrappy teams. Small teams get more done. Only scale up the other bullshit when you absolutely have to.
>Only scale up the other bullshit when you absolutely have to.
Yet scaling becomes absolutely essential for a company doing anything sufficiently complex. The question is how do you maintain that small team efficiency across an enterprise. It seems that business and engineering are very similar in this regard in that the ultimate baseline problem to be solved is managing complexity. The answer seems to be in adhering to the Unix philosophy of tiny, self contained, composable parts which can be easily reasoned about and composed with.
As the parent comment states, the biggest killer of efficiency is communication, particularly across disciplines and across domains. Reducing the overhead of communication and reporting would seem to the the skill most essential to management but generally it's the skill that is generally lacking, or indeed, absent.
The unix philosophy of composable teams can only happen when the communications are clear, concise and don't generate much, if any, overhead. I'd love to see a company with a CCO - Chief Communications Officer - who has a team responsible for making sure that the information passed among the various parts of the organisation was effective and free of bullshit or grandstanding.
Communication channels formula where n is team members: n(n-1)/2 [1]
As teams grow, not only do communication channels increase exponentially, individual contribution decreases overall and there is less ownership/responsibility so people care less i.e. a team of 100 has 99 other people to pick up slack, a team of 1 has noone else, a team of 3 has 2 people that will let the third know of slackage, where a team of 100 may never be able to apply that.
Small teams get it all done, and sometimes single people, especially language designers like Guido, Stroustrup, Ritchie, Matz, Eich, etc and especially in the beginning.
Small team strategy even in big companies is very smart and effective to get the best performance out of each contributor. Small team configuration does give some power and worth to employees though so it isn't used as much in large companies that looks at employees as resources in a machine. Employees as resources may work for established products/processes but rarely research and development or creative products.
I agree with your comment, yet I wish to pick a nit:
> n(n-1)/2
> exponentially
I see this a lot in mainstream media (who simply can't help themselves) and increasingly so on HN (where we should know better): using "exponential" as a synonym for "explosive". I'd love for all of us to stop that. n(n-1)/2 isn't exponential growth, it's quadratic, and once you're at more than 10-ish team members the difference is enormous :-)
I should have said parabolic or quadratic but was mainly focused on the project management / team aspects and how it affects individual team members of ever-increasing team sizes.
