What’s the right team size for your project? What might seem like a simple question is actually a lot more involved than you can imagine. The TL: DR is “it depends”, an unsatisfying answer if there is one. But there’s no other way to put it: Figuring out a team’s size is more of an art than a science.
The answer to the titular question isn’t one that can be given in numbers. It’s akin to a philosophical conundrum. We can talk about it, gain insight, but never reach a definite answer. Having said that, it’s an important question and something that you have to keep in mind if you want to maximize your team’s efficiency.
Amazon’s Two Pizza Rule
Amazon’s CEO Jeff Bezos said during an interview (perhaps jokingly) that any meeting where you can’t feed all the people in the room with two pizzas is too big to be productive. Leaving the reliability of using pizza as a metric aside, the overall advice is actually spot on.
Have you ever heard of the “team-scaling fallacy”? People tend to think that the bigger the workforce, the more productive they are. Unfortunately, that isn’t quite right. For example, as group size increases, managers tend to underestimate or underweight the number of hours required to finish a project.
This fallacy is an error in estimation, as most people tend to think that group effort is additive. For example, if Paul and Jason work 2 hours a day each, then you’d have 4 hours of daily productivity, right? Not precisely.
Like every engineer has heard at least once in their lifetime, “you can’t make a baby in a month with 9 women.” Not every problem can be solved by adding more hands to the task. It depends on the nature of the task at hand.
In fact, some problems get more complex as more people are involved. As teams grow, so do communication patterns, becoming much more difficult to manage. If you’ve ever played the game telephone, that’s a perfect example of how more people make a task harder.
How many people is too much? Evidence points to the fact that groups of 3 to 8 members tend to outperform bigger and smaller teams. It’s not that you can’t have bigger teams, it’s that if you do, it might be a good idea to group them in sub-teams of 3 to 8 members.
Understanding the Requirements
Now that you can agree that increasing the size of a team isn’t necessarily the best choice, you have to ask yourself: How can you decide how many people you are going to need? The first place to look for clues is the initial requirements.
Pay close attention to:
- Project scope
- Projected timeline
- Technical requirements
Keen readers might wonder about budgets, and yes, that’s important too, but we’ll get to that in a minute.
Big projects often need bigger teams, especially if they involve different technologies. A senior developer might have plenty of experience with databases as well as frontend development. But do you really want to split their attention between development and managing SQL queries?
If working with the database is an occasional occurrence, then the answer is yes. Having a dedicated database engineer is a waste of resources, so a single talent can fill both roles just fine. Otherwise, using more than one developer appears as the best choice.
Then there’s the project schedule. What’s the timetable for the project? For long-term projects, you can get by with smaller teams, but if you are facing a short deadline then you might need the extra help for the crunch.
Another key indicator is how many parallel processes can be worked on at once. A parallel process is one that is relatively independent from other aspects of the project. Projects with more parallel processes can accommodate more software developers.
Budget is a touchy subject. On one hand, it’s probably one of the most important aspects to consider when building a team. On the other hand, overfocus on budget constraints can lead to understaffing a team to save money, which will mean a bigger loss in the long run.
In that sense, while it’s important to have a budget goal, it should be as flexible as possible.
The Nature of The Team
If requirements give you the strategic view of the process, then understanding your team’s psychology will give you tactical insight.
Leadership styles lend to different team sizes. For instance, managers who prefer an autocratic approach tend to work best with bigger teams. On the other hand, democratic managers often are at their best when they are working with a small crew of highly motivated talent.
Different project managers have different preferences in regard to the size of their teams. If you already have a manager in mind, let them play to their strengths. Their expertise will prove invaluable in figuring out how to build the team.
Methodologies also play a part here. Teams who opt for agile methodologies tend to be at their best when they have between 5 to 11 members. More than that and the flexibility of the method can be detrimental to the project. On the other hand, waterfall approaches accommodate both small and big teams, as the structure helps keep things organized.
Technological Resources
From management tools to automation and AI, there are dozens of resources out there that can help you build your team. Thanks to serverless services, communication apps, and version controls, you can have dozens of developers from all across the world working on the same project.
On the opposite side of the spectrum, routine tasks that used to require dedicated developers can be automated. Thanks to that, you can have smaller teams with higher levels of productivity.
Keep in mind though, that while technology may help you, it can’t force an understaffed or overstaffed team to be at their best. No amount of computing power can substitute communication and the social capital of a highly functional team.
Start Small
Let me share with you the best piece of advice someone gave a few years ago. Just like how it’s easier to scale a project than to descale it, it’s easier to start with a small team and add more developers as the context demands. It’s easier to spot a bottleneck and add another member than having to downsize and then having to increase the workload of the rest of the team.
Like I said in the beginning, building a team isn’t an exact science, as there are no right answers. The experience of a consultant or an expert is extremely important when figuring out what’s the ideal size of the team for our project.
