Rework, one of my all time must-reads, makes an excellent case about size. “Right now you’re the smallest , the leanest and the fastest you’ll ever be. And the more massive an object, the more energy required to change its direction.”

Here at Cloudoki we’re fortunate enough to have a very healthy mix of early startups and bigger corporate clients. We’ve worked with 1 person and 100 people teams, and everything in between. This article is about my view on how a software development team’s size affects productivity and overall work and delivery quality.

What is a “too big” of a team?

There is certainly not a defined number for what makes a team big or small, these are completely subjective to what you’re evaluating. Here, we’re relating (not directly) team size with productivity and quality. So, in this context, what is too big?

Assuming everyone is great at their job, I tend to draw a line in the sand when it becomes clear that extra levels of management are necessary to make sure everyone’s job in the team is clear, documented and accounted for.

Middle management: The root of all solutions, and evil

Just like the game we used to play when we were kids (pass on a sentence through a chain of people and see as it changes), the message gets both diluted as well as polluted the more people it has to go through. As communication is key, this definitely has an impact on everyone’s job.

Although extra layers of management are necessary (even mandatory) in many cases, one has to be aware of the impact increasing a team has on the overall project or product.

Error prone-ness

Doesn’t matter how you put it, more people means adding extra roles to manage those people which will always lead to having the complete knowledge split up between different people.

This is not a bad thing per-se, it’s how companies are built, unless you’re a one-man show. This it’s a practical necessity. Is it, however, more productive and less error prone than less people? No.

More people managing means different people handing out orders, which, unless everyone is amazingly at sync all the time, can lead to different expectations, and that leads to different results.

If you think you can easily go about solving this by adding more people to make sure these are at sync, you’re not paying attention.

Communication & autonomy

The more moving parts there are to consider, the harder it is to have all of those working exactly towards the same direction. It becomes impossible to sit everyone in the same room to talk things through and go right back to work independently.

The more hierarchy there is the bigger the chain of communications becomes. Making a decision is no longer a 5 minute talk with someone, it’s instead a full day trying to share requirements and limitations with 4 different people, where the people that made the questions in the first place are not even there.

Speed & agility

Autonomy goes hand in hand with speed. Lack of it can slow down the process unbearably to the point of frustration and implosion. Decisions now take longer, and the bigger the team, the more expensive time becomes.

A team that loses autonomy also loses agility. Many moving parts, too much “weight”, makes it immensely more complicated to shift when it has to. As gravity increases, change becomes less attractive and mistakes get even more expensive to fix.

Responsibility & ownership

This one is probably the silent killer of projects and teams. A natural by-product of a bigger and layered environment is the lack of sense of ownership.

Either nobody is really aware or responsible for the full scope, and things never get done because everyone just assumes someone else is already doing it; Or everyone is just doing their thing because they know best and hope the rest will follow their lead.

As responsibility gets diluted into the different layers, at the end of the day, it’s nobody’s job to pick things up.

The limitations of a small team

Big and huge teams are a necessity, of course. There are many projects a small team simply can’t undertake. There is a threshold to the amount of work one team can produce, regardless of how productive or aligned it is.

Bigger teams are usually the sum of many smaller teams with their own processes, management and goals, and if they are autonomous enough to deliver what they need to, there is absolutely nothing wrong with this. The reality however, is that this is rarely the case.

What is best?

Unlike some Project Managers swear by, 9 women cannot deliver a baby in 1 month. With this I mean that more is not necessarily always better, and bigger doesn’t translate to more.

Best is whatever works for the problem at hand. If you can go small, smaller and simple is always better; And if you can’t make it small, grow. But grow responsibly, only when it’s really needed, and be fully aware of the challenges it might bring.