In startups, teams are — by necessity — small. I’ve worked on bootstrapped development projects where the same five people wrote code, tested, created documentation, and even did ads. (Turns out software engineers don’t make for good marketers, though a sketched ad featuring cavemen discussing ERP was pretty funny…at least to us).
Once a company has that first sugar rush of success, one of the first responses is to “finally bring on all the people we need.” Scarcity weighs on people’s minds during the lean times — the salve of one day having a dedicated person to do (fill in the blank) sustains them during the sometimes long hours. As challenging as that scarcity is at times, it is very often a gift for teams. It creates an environment that fosters creativity, easy communication and simplified problem solving.
Everyone in technology has likely read The Mythical Man Month and as a result hears Brooks’ Law echo in their heads as teams grow. And though not every project is possible with small teams, the decision to grow is a critical one and every measure to retain “scarcity” in its design and structure is essential.
Larger and larger teams are the Petri dish of bureaucracy — and that bureaucracy stunts productivity. Communication flows naturally when everyone fits in a single room; status is easily divined when everyone can stand before the wall Gantt and speak to their part of the project. No one can hide — and no issue can be hidden. When we begin to add people they come with a tax: now we must have mechanisms to communicate when people no longer fit in one room; when status means assembling updates from 10, 20, or 30 people. And that communication can sometimes minimize or inhibit the discussion of problems. That inherently makes the team less nimble.
A related issue is that as the teams get larger so do the meetings. These meetings create the fertile ground that makes pop culture smash-hit games like “Angry Birds” possible. I have sat in sad wonder of meetings with sixty or more people that are billed as “strategic discussions” and watch as focus, money and opportunity vanish with each passing hour. The usual audience of these meetings breaks down like this:
That small teams work more effectively is likely intuitive to anyone engaged in a creative exercise like software development. There is actual science to support the idea as well:
In 2005, the consultancy firm Quantitative Software Management (“QSM”) reviewed over 4,000 projects for which they had complete data on team size, project size (measured by lines of code) and delivery. They found that small teams (5 people) are significantly more cost effective on average than large teams (32 people) by a factor of seven. And, larger teams only shortened the schedule by an average of one week. Brooks’ Law strikes again.
In the early 20th century, Maximilian Ringelmann conducted an experiment to measure effort per person as teams grew in size. In a very elegant experiment, he measured the pulling force by person as more and more people were added to pull on a rope. What he found was that as the team grew, pulling force did not keep pace. That beyond a certain point people began to contribute less and became engaged in “social loafing” where the contributed less because they were less personally invested in the activity.
In 2012, Wharton Business School professor Jennifer S. Mueller published a paper “Why Individuals in Larger Teams Perform Worse” that concluded that — as teams grow in size — individuals tend to feel less connected to one another (those relationships are more tenuous) and their individual performance declines.
Larger teams are sometimes required. There are many endeavors that require more than a small group of people. It’s not possible to build all the features in something as feature-rich as say iOS with a small team (though the first internal release of iOS at Apple was built by a team of three). But even in large organizations, it is possible to embrace the principles that scarcity brings:
- Keep meetings to the essential participants. Some organizations treat meeting attendance as a sort of strange reward: value is measured by meeting attendance.
- Keep teams as small as possible. Especially in the critical early days of a project.
- Break larger groups into smaller ones and give them autonomy.
- Hire sparingly.
Small is the new “big.”
