Efficiency Before Scale
Organizations that hire in a manner that could cynically be called "throwing bodies at problems" often end up in cyclical cash crunches due to inflated payroll obligations. In the long run, they lose competitiveness to companies that achieve more efficiency.
Ideal Team Size
Converging on an exact team size formula is, of course, impossible. There are too many cultural and organizational factors, so seeking a precise answer will result with a clear "it depends." However, it's clear the ideal team size is much smaller than is commonly found in the corporate wild.
The above chart shows that individual productivity tends to go down in a compound manner once a team size is above 3, but it actually starts going down past one. Notice that performance gains completely flatten out at 7 individuals.
[2]
^b65523One thoughtful engineering manager says that to assure a software project is successful, you need both redundancy and to pursue several approaches. By redundancy, the manager highlights two factors: 1) most are not the mythical 10x or 100x engineers, so the practice of Pair Programming assures that better code is written, and 2) there is always a risk someone will randomly quit or someone will just not work out, and when that happens one pair is lost. Therefore, by default any project needs 2 pairs, so 4. However, the manager also highlights that from conception to implementation, there are always many different possible "approaches" -- from language, syntax, organizational conventions, programming paradigms, etc. Projects are more likely to succeed if you try multiple approaches, as it will become clear over time which approach has more merit. Yet, even factoring the need for multiple approaches, he only adds one pair to his recommendation: 2 to 3 pairs, so 4 to 6 engineers.
[1]
When surveying the perspective of experienced software engineers, rather than engineering managers, its clear that there is a fierce allergy to large teams. A discussion on Reddit shows the boundaries of what engineers feel is appropriate. The discussion catalyst says "12 is too big." Other commenters seem to lose their faith in the team after 7 team members.
[3]
Small teams that are resource constrained are often forced to find efficiencies that require motivated tinkering. One of the louder voices advocating for small teams is David Heinemeier Hanson. His organization, 37 Signals, is both radically successful and highly influential in the global technology world. Codified in the books Rework and Getting Real, he promotes contrarian principles on building technology products, and on scaling technology companies. According to DHH, a fierce commitment to sticking to small teams, not hiring, not adding resources, not investing money, and not working hard, is counter-intuitively the best way to build technology products that scale to millions and make large profits.