
The power of small teams
November 16, 2009One of the most recurring questions that crops up in software development is ‘what size of software team is optimal?’ It’s a tricky question and consensus seems as far away as ever.
There is a school of thought which suggests that smaller teams are considerably more effective, per person, than larger ones. The theory goes that the overhead required to organise and manage a smaller team is proportionately lower than that of a larger team. As team numbers increase, in fact, this overhead appears to increase exponentially.
Why should this be? Well, there are a number of factors, including:
- Communication
The more people need to know, the greater the time spent propagating information and ideas, and the larger the risk of those ideas being misunderstood; - Diversity
Generally a good thing, in an effective software team it can be difficult to ‘carry’ anyone whose skill-set and experience doesn’t closely match to the tasks in hand. Diversity is nice, but when there’s a job to do it’s better to have a few specialists than many generalists; - Division of tasks
Splitting larger tasks into smaller ones makes sense but it requires careful planning and resourcing, and runs an increased risk of ‘compartmentalisation’ of knowledge; - Personality issues
The greater the number of participants, the larger the likelihood of conflicts, fallings-out and so on. Also, more people mean that people have smaller individual stakes in the outcome of the project and may feel that their contributions are less valuable; - Environmental issues
It is always trickier to locate a larger team together due to space constraints so larger teams may end up having to be split into two or more physical locations. This creates difficulties with communication, co-operation and dilutes the sense of ‘belonging’ that a smaller team located in one place would have.
In fact, a smaller team can be considerably more efficient than a larger team for a majority of software projects. And this is after taking into consideration the fact that a smaller team will have fewer ‘man days’ available within a fixed period. With the right people on board, a smaller team can be twice as productive per person as in a larger team, due to the considerably lower organisational overhead.
So, who are the ‘right people’?
There is a strong body of evidence to show that the very best individuals can be five or ten times as productive as even averagely competent individuals, when given the opportunity to release that productivity. This opportunity occurs only when the structure of the team permits rather than obstructs performance.
In other words, the team is small enough so that communication is direct and timely, meetings are short and only when required and management’s role is less one of fighting the bureaucracy and ‘red tape’ and more one of enablement and facilitation. The interaction between team members, playing to individuals’ strengths, promotes a synergy that is very rare in larger teams.
A smaller team, composed of talented individuals who have sizeable responsibility, enthusiasm and whose workflow is not impeded by the overhead of larger team issues, can achieve great things.
“Innovation always has been driven by a person or a small team that has the luxury of thinking of a new idea and pursuing it. There are no counter examples.”
– Eric Schmidt, Google.
The power of small teams is in achieving great things with minimal waste – and in this sense our original question ‘what size of software team is optimal’ might be answered as follows:
The optimal software team size is as small as one can get away with whilst still achieving the goals.
I know this doesn’t really commit to a particular number, and of course everything is dependent on the quality of the people in the team, the scope of the work to be carried out, the environment in which that work needs to be carried out and countless other factors, but if we had to be drawn on a number, we’d say that the very best software teams are composed of less than ten individuals in total. Generally speaking, of course…

