A formula to find the right team size

A formula to find the right team size

Challenging the production line playbook

The formula for choosing the right team size hasn’t changed since the industrial revolution. Which is to add another person to a team and expect 1x more output. This was challenged by Brook’s law, coined by Fred Brooks in his mythical man month book published in 1975. But the theory failed to break the mental model and most people continued to build large teams.

It’s no secret that teams lose some efficiency per head as they get larger. They also seem to be less effective at delivering impactful work. Why do things get so much harder when teams get big? Adding more people to existing teams rather than spinning off new teams is the more popular way to go. This formula is: fill your managers diary with 8 reports in 1 team. Rinse and repeat.

We tend to see low innovation in large companies with large teams. We see high innovation in startup’s with small teams. Early members of startups have big incentives to work hard. They pull out all the stops. Perhaps it’s startup’s that are more effective?

Then how does Basecamp achieve success in the same domain as Asana? Basecamp, a team of 60 that’s been around for 20 years is no longer a startup. They outperform Asana in certain segments, a team of 2,500. Basecamp swears by product development teams of 2. Naturally small teams have a higher level of ownership per person than larger teams. Small teams must play broader roles and have a wider perspective than larger teams.

It sounds like having small teams is the obvious answer for new and old companies. But, larger teams have greater resilience to sickness, holidays and people leaving. Since there’s more people to carry the context. Larger teams can specialise. Small teams have to play broader roles than comparatively larger teams.

There are certain breaking points where there are diminishing returns. It’s widely accepted that managers should have a maximum of 8 reports. If you have 1 team of 8 you’re pushing the breaking point of communication. In our small startup, I’ve seen systems break with just a small team changes from 3 to 4 and 7 to 8. When your group gets too big to have effective and efficient meetings, things break. You break the team into 2 and you’ve just increased the complexity of management and inter team communication.

‍

‍

Like a chain of Chinese whispers, each person a message passes through, it loses its effectiveness. The person with the passion for the original message is further away and it loses its potency.

Brooks law states that adding engineers to a late project, will make it later. It’s accepted that communication gets harder as you scale too. Bezos’s pizza rule speaks to when you reach diminishing returns on team sizes. With these theories widely accepted, why is the default formula still to max out a managers capacity with a single team? Like we’re organising an industrial revolution time production line. Rather than a software business. Why aren’t we putting more thought into the cost of communication and other constraints that come with size?

Brooks law is somewhat outdated now. With modern software development practices there are less dependencies. The barrier to spinning up new projects as a solo engineer is much lower. The barriers to engineers deploying code is lower. With certain frameworks and tooling prescribing best practice and more standardisation, there are lower barriers to onboarding in a code base. With containers there are lower barriers to onboarding and spinning up environments.

In infrastructure, there’s long been a vertical vs horizontal scaling debate. Horizontal scaling, often known as “scaling out,” is the process of increasing the number of machines in a pool. In this metaphor, this would be choosing to build 3 teams of 3 instead of 1 team of 9.

Pros:

• More flexibility to be agile and change course.
• Ability to work on different things concurrently.
• Higher level of ownership and more responsibility for each team member.
• Higher level of autonomy as each team member has more control and more decisions to make.

Vertical scaling, often known as “scaling up,” is the process of increasing the power of an existing system or team. This would translate as choosing to build 1 team of 9 over 3 teams of 3.

Pro’s:

• Less complexity involved in managing.
• Smaller inter team communication overhead.
• Ability to specialise and therefore reach a higher quality bar.

In the technical world, horizontal scaling is generally favoured these days. Since we now have the tools and techniques to manage scaling horizontally, the management overhead of the horizontal approach has become minimal. We’ll see this same move in scaling teams of people, when our systems and tooling becomes sophisticated enough.

Factors to consider when deciding your team size

Function types: different jobs have different levels of communication overhead. This very much depends how many dependencies there are on the team members work with colleagues. A sales person might be able to work independently on closing sales, without the need to collaborate with any colleagues. Then the team can be scaled vertically with little concern for communication overhead. You will only see a small decline in communication efficiencies with team size. However, a software team may have more dependencies. For example if you are working on the same project or code base, then you will see a sharper decline in communication efficiency as you scale.

If team members have overlapping work (high dependancy), smaller teams could be are more effective. If you don’t have much overlapping work (low dependency), you can afford larger teams.

‍

‍

Team member types: if you have team members that are not proactive communicators, you’ll feel communication overheads more. If you have independent workers who are proactive you could stretch to the max team size. You need good communicators and listeners, team members maybe proactive at sharing their updates, but not so good at listening or retrieving information from your documentation.

You can choose to put pressure on certain points of the organisation depending on the types of people in the team.

Level of documentation: if you have lots of processes and information written down, this can reduce communication overhead. If your team has a habit of finding answers in your knowledge base over asking a human, you have greater scope to scale.

This is a constant battle to document as you go. If you have built this habit, your documentation may be maintained. If you haven’t built this habit, then your documentation will be declining until your next big push to document again.

Management structures: do you have or do you want to have bigger management structures? This might be sophisticated software to organise work, it maybe a manager with strong coordination skills or it maybe a high manager to report ratio. Is it easier for a manager to mange 3 teams of 2 or one team of 6? It takes a greater level of organisation to manage more teams, coordinating 3 teams work, over 1.

Formula to choose your team size

‍