The size of a team can have a great impact on its effectiveness, productivity and happiness. There needs to be a balance between team member satisfaction, team productivity, and collaboration. Despite the availability of information and experience, there still seems to be a belief that throwing more people at a problem will solve it faster.
When deciding what the ideal team size is, there are a few factors to consider:
- Satisfaction of the individual team members
- The impact of team size on individual contributions
- Team Size and Communication Complexity
Individual Satisfaction
One famous study is by Hackman and Vidmar, which shows that individual satisfaction decreases as the team size grows. Having satisfied team members is important. Satisfaction is highest when there are only two in the team, but in the workplace this is quite often not practical, since quite often one of the team will be sick, on leave or absent for other reasons. Also, two people might not be able to handle the required workload, so you might need more people in the team to handle it – but there is a limit to how many people you can add before individual contributions drop. That brings us to the The Ringelmann Effect.
Individuals Contributions and Team Size
As the team size increases there are a few things that can happen. The Ringelmann Effect shows that individual performance decreases as more team members are added – additional studies have found similar results. There are a few possible reasons for this – social loafing (people contribute less as the number of team members increases), coordination complexity, individual motivation, and team cohesiveness.
Communication Complexity and Team Size
Communication complexity increases as you add more team members. You may have come across the image below previously (source: Lighthouse). In this picture the points are people, and the lines are possible communication paths between the other people in the team.
As you add more people, beautiful patterns emerge! But that is only in the picture. In reality, this means that communication complexity increases dramatically as you add more team members. Communicating effectively with all people in the team becomes very hard. Coordinating tasks also becomes more difficult as you add more team members.
If you consider one example – the morning huddle or daily scrum. I personally witnessed meetings where just giving each person a minute to speak means that this ‘quick’ meeting consumes the best part of an hour! Where team members need to collaborate on a piece of work, or need to communicate important information, it becomes time consuming and complex to do so.
Within larger teams there is inevitably multiples streams of work, resulting in a team with multiple, potentially competing, goals. Experienced team members are often split between these streams as the sub-teams request help. Cliques can also form, disrupting the social cohesion of the team.
Adding More Team Members Doesn’t Speed Things Up
Brook’s Law says that adding new team members to a late software project will make it even later. It sounds counterintuitive doesn’t it? I can tell you from personal experience that many people think still so.
Why does adding more team members to a software project not speed it up?
- When you add a new team member, you need another team member to bring them up to speed to be able to contribute.
- Communication complexity increases as you add more team members.
- It takes more time from your team leader, manager, scrum master or product owner as you add more to the team.
- Social cohesion can also be interrupted as you as more team member.
- Plus, if you add team many at the same time, it is the same as creating a new team.
So, you can’t just add people to a team to get the work completed sooner. In fact, if you add people to a team you can expect the work to be completed later.
What do some other people have to say?
Jeff Bezos has his 2 Pizza Rule – if you can’t feed the entire team with 2 pizzas then the team is too big (or you’ve ordered the wrong size pizza!). This is a rule of thumb that makes sense – if each pizza can have eight slices and each person needs two slices, then the maximum you should have is 8.
Michael Lopp has a good explanation of his 7 (plus or minus three) theory here, which is based on the time needed for a team leader to communicate with the people in the team. If a team leader is going to be able to devote enough one-on-one time with the team members, if there are more than 7 people in the team there simply isn’t enough time.
Jeff Sutherland puts the absolute limit at 7. If there are any more in the team, then the team should be split. His article is here.
The team at QSM have studied this as well, focussing on technical IT teams. They found that teams of 2 to 4 people delivered the best schedule performance, and that teams of more than four people delivered dramatically worse cost/effort and schedule performance.
And from personal experience, I can say that 5-6 has worked best for the teams I’ve worked with. Four seems to be a good number, but there is very little buffer for when things are going well (such as long-term illness from one of the team members or when a new person needs to be onboarded), and 5 to 6 allows that little buffer, accounts for turnover well, and still provides for a high level of cohesion and collaboration in the team. When you start to add more people lots of things take a lot longer.
The Ideal Team Size
The ideal team size depends on the purpose of the team and the amount of collaboration needed between the team members. The higher the interdependence of tasks and need for team member collaboration, the more likely that a smaller team will perform better. But for most collaborative teams, the ideal team size is between 4 and 8.
- What is Developer Experience?
- What is the main role of the product owner during backlog refinement?
- How to Set Up a Home Where You Can Work and Relax
- Effective Remote Team Communication
- Tips for Staying Productive While Working Remotely
Photo by You X Ventures on Unsplash