Through our experiences, we have learned that small teams are often better than the large teams. Throwing more people in on a project doesn’t always expedites the process of developing an application or a product. According to a study performed by QSM consulting,
“Smaller teams are more efficient than larger teams. Not just a little more efficient, but dramatically more efficient. QSM maintains a database of 4000+ projects. For this study they looked at 564 information systems projects done since 2002. (The author of the study claims their data for real-time embedded systems projects showed similar results.) They divided the data into “small” teams (less than 5 people) and “large” teams (greater than 20 people).
In our previous article, We focused on how to find the right team to build your startup product. Today we wanted to go ahead and discuss why small teams beat the large teams in terms of productivity and efficiency as well as cost effectiveness.
Communication is definitely the most important factor when you are working with remote teams. A small team will have a simple hierarchy and there will be one contact person to deal with most of your issues. There is less chance to play blame game and basically there is very little place to hide. A team that is constantly growing is focusing more on quantity rather than quality. When I say quality, its not just the quality of work, but also the quality of relationship they have with their clients. You just can’t handle a dozen clients with equal importance.
2- Everyone pulls their weight
When you know you are going to have a small team, you are extremely careful in your recruitment process. You just can’t afford to have members that don’t pull their weight. Every member has to bring something on the table. Therefore, when you work with a small team you are working with a select group of people who are not afraid of the spotlight and constantly working hard. It is impossible for anyone to fly under the radar for that long.
3- Believing in Co-creation
Think of team that helped you bring your idea to life. Created an MVP of your product which you were then able to proudly present it in the market, gain traction and were able to take it to the next level. You know everyone in this team by their names and have developed a relation. This team understands you and knows how you like things to be done. When you decide to take your product/website to the next level, you can’t imagine doing that without this team. A small team that wants to stay small by choice is a team that believes in Co-creation. They want to grow vertically as opposed to growing horizontally. They want to be involved in creating your product and can become an integral part of your business. They know if they helped you launch successfully, they will be needed again and therefore will do their best to ensure that your project sees the light of the day.
4- Efficient Delivery
Although it may seem like a logical approach to add more people for schedule compression in a situation where you need more work done in less time, research shows that it’s actually counterproductive in software development. Your project may be time sensitive and you have a deadline for the launch the additional cost incurred by adopting the manpower-intensive approach may be trivial compared to the revenue or benefits derived by earlier delivery.
5- Rely on Trust, not Process
And last but not the least. Small teams give more value to trust than process. In other words, these teams will hire the RIGHT people and build a culture of trust without micro management as opposed to creating a stringent process that hinders performance. In their Culture presentation Netflix described this as
“Instead of a culture
of process adherence,
We have a culture of
Creativity and Self Discipline,
Freedom and Responsibility.”
An assumption is that as team size grows, the percent of high performance employees is often decreasing (red arrow in the graph below). As this diagram demonstrates, at some point the percentage of high performers isn’t high enough to manage the complexity.
At that point, Process becomes the middle manager’s favorite tool to manage team growth.As mistakes start to happen, process is formed around those mistakes to try and reduce damage and inefficiencies. Examples of such process can be:
“You need to get approval from X and Y before starting to work on feature Z.”
“Every morning at 9 AM you have to attend a stand up meeting.”
“Every code checkin has to go through a code review.”
“You can never do any project related work from your personal laptop.”
“You have to work at least 8 hours a day and take no more than 5 weeks of vacation a year.”
The problem with this kind of rigid process is that it’s focused on reducing damage to the team from bottom performers or untrustworthy people, at the cost of increasing barriers and friction for the top performers to make unexpected positive impact. This is the exact opposite of what it should be. An agile approach, where getting the work done is the most important thing.