Are smaller engineering teams faster?

Jeff Bezos, you may’ve heard, felt engineering teams shouldn’t be larger than what two pizzas could feed—that is, about seven people.

There’s a “7 +/- 3” rule. Other smart folks have argued for 6-8.

So. The prevailing wisdom can be summarized as “around seven people, and no more than 10.”

This has a good, commonsense weight. Too much larger, and you can feel team cohesion requiring more attention, more work to keep people on the same page, more managerial time to see that everyone is getting the right guidance and feedback.

These are all valid reasons for keeping teams on the smaller side. But, maybe for these same reasons, there’s also a general sense that smaller teams are faster.

As the following data show, that ain’t necessarily the case.

Team size vs. team speed

To see if we could find a correlation between team size and the speed of work delivered, we studied anonymized work activity across hundreds of Socratic beta users, which represented a total body of work of over 10,000 tasks. To qualify for inclusion, a team need to have completed at least 20 tasks.

Speed, or cycle time, is the average duration (in days) to complete a task—something that Socratic surfaces automatically.

Even after removing outliers and setting minimums for the amount of work completed, there was little observable correlation between team size and the speed at which work was completed:

This lack of correlation between team size and speed may be… good news? It suggests you can set your team sizes based on what feels qualitatively right, without worrying about hitting some tipping point, beyond which your speed will come crashing down.

There’s that old proverb: “If you want to go fast, go alone. If you want to go far, go with others*.*” **But the data say something else. You can go fast with others, too.