When talking about software development teams size, smaller has big advantages. I have heard that premise a bunch of times before and it all made sense, but it was not until I actually experienced it myself that I really understood why.
The first problem working in small teams should fix are communication ones. That is because the communication overhead increases as the team gets larger. Like a geometrical progression, the number of different communication links increases rapidly with the number of people in the team. Janet Choi did a really good job explaining why.
Each additional person increases total productivity of the team but at a decreasing rate, which means if you were the third member to join a team, you made a bigger impact on its productivity than if you were the thirtieth.
Every steep jump in links also produces a steep jump in the potential for mismanagement, misinterpretation, and miscommunication.
Choi, Janet. The Science Behind Why Small Teams Work More Productively: Jeff Bezos' 2 Pizza Rule.
The problem with big teams is not the number of people but the communication links between them that grow when the group size increases. In small teams communication feels natural. If your tools get in the way, change them. If your process gets in the way, change it. When communication is easy there is less room for error and the cost of any change is lower.
Additionally to helping fix communication problems, smalls teams are great at creating a work environment that helps keeping everyone in it motivated. This is hard to achieve in big teams where it is easy to feel like you don’t matter, where as the team gets larger the ammount communication links is so high that they end up being really weak and you feel as if you are receiving less and less support. Having motivated people in your team starts by making every team member feel relevant, helping them be more engaged with the work they are doing. Being motivated, feeling relevant and engaged are things that will make anyone more productive and that is easier to achieve in small teams.
At this point you probably figured about that with the smaller the better I’m not saying that a one person team is the best size, if you can even consider that a team. I’m talking about teams that are not bigger than nine people, you can use Jeff Bezos two pizza size team rule as a sensible starting point, but I encourage you to use whatever you think makes sense in your case. There is no golden rule or perfect team size.
For a small team to be successful, it should be given a clear goal and then given the autonomy to meet that goal however they think it is the best way to do so. Team members need to be well rounded, quick learners, trustworthy and above all, motivated. There is not space for heroes in small teams.
Being part of a small teams allows every individual to be closer to the customer because they are on the front line. The constraints that a small team implies are good, they have less people, but everyone has more power, you have less time, so you have to make a better use of it, you have less resources you give them a better use and you are probably spending less money so are generating more value.
When the project a small team is working on gets behind schedule it is very tempting to increase the teams’ size. Don’t use that excuse as an excuse. As Fred Brooks wisely says in the The Mythical Man-Month adding human-power to a late software project just makes it later, if your project is late look for the root cause and fix it, it might be that the initial expectations were not realistic. In anycase don’t think that increasing your team’s size will help, because you will be in for an unpleasant surprise.
Working in small teams is a sustainable practice that will allow everyone involved to feel engaged in the process of building a software product and will allow you to save time and money. This principle has been proven to be successful in both big and small companies, stick to it even when things get though, because as Bezos says we can’t realize our potential as people or as companies unless we plan for the long term.