Why is my software development team slow despite having more people?

The software team says the workload is too high. So you add more people. That should help! But what happens instead is that features now take even more time to squeeze through the system and your people start blaming each other. What has happened?

You are far from the first person to live through this dilemma, and the good news is that there are ways to add more people to a project and actually go faster, but it requires some serious work. In 1975 Fred Brooks wrote about this conundrum in his book 'The Mythical Man Month', where he compares developing a software project with having a baby. You won't be able to get that baby in one month when you assign nine people to making it. He coined Brooks's Law which says that "Adding manpower to a late software project makes it later." Several other people have made the same discovery since and came up with reasons and solutions (for the software problem, not the baby one).

Here is a list of some of the reasons:

1. Communication gets more complicated

For every person added to a team, the number of communication channels increases quadratically. If you had five people in the team, there were 4 + 3 + 2 + 1 = 10 communication channels. If you add a sixth person, there are now five more (5 + 4 + 3 + 2 + 1 = 15) communication channels. Each new person increases the number of channels by the number of persons already in the team.

Official communication becomes a lot harder, but the unofficial communication suffers too. Situations like overhearing your colleague talking about a problem that you know how to solve become more unlikely the more colleagues there are.

Communication through code suffers as well. With fewer people it is easier to decide on shared standards and to have discussions about the structure of the code. With a lot more people involved, it is harder to maintain conceptual integrity: the code won't look like it was written by one person and thus be harder to navigate, understand, change and maintain.

2. Lack of trust

The authors of the book Team Topologies argue that the size of a team is limited by Dunbar's number, which is the maximum number of people with whom one can maintain stable social relationships.

If the team gets too big (more than nine members), the trust automatically decreases because of this human limitation. High trust is what allows teams to innovate and evolve. If it is lacking or reduced, the speed and quality of delivery will decrease.

3. Onboarding takes time

It takes time to onboard new members, and it takes away time from those who are familiar with the system. This is why adding people to an already late project makes it later.

If you, however, add more people before everything is on fire or if you add the right and highly qualified people, Brooks's Law does not apply (according to Brooks). It also does not apply if you can perfectly partition the tasks, which Brooks argues is very rare.

4. The real problem is the cognitive load

The cognitive load remains the same even if you add more people, you cannot decrease it by sharing it (it is like 'fun' in that way, only much less fun). Complicated code, processes and tools will influence the speed of every team member, if there are more, that just means more people are trying to make sense of the same mess. Cognitive overload can also be rooted in teams being responsible for too many domains or an architecture that doesn't reflect the organizational structure.

5. The architecture does not support it

There's another law called Conway's Law that says that the architecture of your systems prevails the structure and communication paths within your organization. So adding more people to a big team will not only complicate the communication and trust but also the architecture. If you try to change the architecture without reorganizing, this will, according to Conway and Team Topologies, only lead to friction and cognitive overload, and in the end the organizational structure will prevail over the architecture again.

What to do?

So what needs to be in place to be able to gain speed by adding people? According to Conway's Law, you should start with working on the organizational structure. Together with technical people who know the current architecture and its limitations, you can reorganize with the goal to improve the architecture (this is called an Inverse Conway Maneuver). Taking trust and cognitive load into consideration, you should make sure that the teams stay small and can work independently of each other. Aim for one Bounded Context per team. Now you can make sure that the architecture reflects the organizational changes. This is called a sociotechnical process because it requires both social and technological change.

The new organizational and architectural structure (which is modular now) makes it much easier to add more people and gain speed.

Once you have come so far, you might find that you no longer need to add more people to gain speed. But if you decide to do so, you are now able to add a whole new team that starts working on a new module without affecting other teams. Or you add multiple new people to a bunch of smaller teams. If each team has to onboard one new person, the negative consequences (trust, communication) are much less serious than onboarding a lot of new people into an already big team. You can also think about adding people with the purpose to remove obstacles for the team (a so-called enabling team according to Team Topologies) and thus speed up all other delivery teams.

You still won't be able to make a baby in a month, but you might be able to make more babies in 9 months than you could imagine.

/Katharina Damschen, Principal software architect