The purpose of this post is to provide guidance on how to manage the complexities of scaling up a team.

As with most things that involve people, nothing is black and white, so you’ll have to balance what’s described here with your specific team and consider which of these actions make sense, and which don’t.

We also avoid being overly specific so as to ensure we are not caught up in the details.

First of all, we need to gauge in which size group the team is.

Definition of “Team”

To avoid confusion about who we include in a team, we’ll define “team” as the group of individuals who actively take part in delivering project backlog items.

Identifying what kind of team size you are in

We will differentiate 3 types of teams:

• Small teams: Where we would ideally want to operate . A small team will be efficient and nimble.

• Medium teams: There’s an awkward phase of growth where you start noticing some issues, but it feels like splitting the teams would result in teams that are too small, or that don’t have the cross functional skills that they’d need to deliver software effectively.

• Large teams: A large team is when the size of the team has become no longer tenable and splitting the team is a necessity. Ultimately, we’ll have to split the team into smaller ones that are independent enough not to revert into thinking they are the same large team, which would result in a regression and not solve any of the issues we are trying to avoid.

Warnings of your team size

There’s no hard limit on maximum team size, as it will be very context specific (a general rule of thumb is less than 9 people).

This section aims to call out some signs that may be caused by growth pains, but could have other prime causes. As an example, if a standup takes too long to run, it’s likely to be due to the team size, but it could be a very talkative team member uses 10 minutes everyday.

Indications that your team is a small size team

It’s likely that you wouldn’t be here if that were the case 🙂

By exclusion, small teams will be teams that don’t exhibit the indications of medium and large teams.

Indications that your team is a medium size team

• Not everyone is interested in what’s going on. E.g a grooming session goes over tickets that part of the team are uninterested as they know they won’t work on them.

• Crowded ceremonies.

• Reaching an agreement is difficult (many opinions to align).

• People start specialising in an area of the codebase, creating knowledge silos within the team.

• The team doesn’t fit in a small meeting room.

• Long stand-ups, sometimes overrunning.

Indications that your team is a large size team

• The same symptoms as those displayed for the medium sized teams, plus:

• A feeling of too many things happening at the same time

• Lots of communications about specifics

• Lots of ad-hoc syncs to get everyone on the same page

Teams cognitive load overwhelmed. This imbues the team in a mist of stress where somethings may be forgotten or missed as there’s too many plates to juggle.

• Deadlocks in decision making.

• Little common ground in retros.

• Typing attendees to meetings takes longer than summarising the outcome.

• Team doesn’t fit in a large meeting room.

• Often people don’t do something because they’re waiting on someone else to do it first.

• Stand-ups consistently overrun.

Engineering, engineers, team, scaling up

Recommended actions depending on team size

Small team

A small team should be lean and nimble. At this early stage, simplicity should be favoured to avoid committing too much effort future proofing something that may never occur. As a result, we would recommend that you:

• Avoid overly modular architecture as it requires overhead to plan, execute, and maintain.

• Keep It Simple, Stupid.

• Focus your unit test code coverage on business logic that warrants those tests.

As your team grows, you can start introducing overhead to keep everything ticking along.

Medium team

At this stage, you’ll likely be hesitating around the question of “Should we take action now, split the team, and risk “storming” for a period while we get used to it, or carry on as is?”.

Unfortunately, we can’t clear your doubts. As everything, splitting the team will have a tradeoff, so ensure you have a clear understanding of them via a cost/benefit analysis.

Be clear on what would it cost to act now, versus how much benefit you’d get. Also, don’t just think about this cost/benefit as a static one off, but consider how it will evolve over time. Will cost go down while benefit remains constant? Will the cost go up? That should factor into your decision to act.

Finally, never forget about opportunity costs. You could use this time on something more beneficial to the company.

Large team

If you have concluded that your team is a large one, then you have to find a way to split it apart, creating multiple small teams that recover the initial ability to be lean and nimble, but now at scale.

Splitting teams

Splitting teams is no easy feat, but we’ll try to summarise what you should have in mind while doing it.

The main goal when you split teams is to enable them to act as decoupled teams, that is:

• Each sub-team should look like a complete small software organisation.

• The internal processes and communication of the team should not be a concern outside the team.

• How the team implements software should not be important outside the team.

• Teams should communicate with the wider organisation about external concerns: common protocols, features, service levels and resourcing.

To achieve that, there’s three main dimensions where the team split will impact your team members. For each of them, you should be able to understand:

Who will they work with?

The first one should be simple, as it would be listing the new teams’ composition.

What will they work on?

What will they work on is where it gets a bit more convoluted. Will they work on a specific feature? What will happen once that feature is done? Will this team lose its meaning? Will they work on maintenance?

There’s no absolute answer for that, so you’ll have to consider what alternatives are in your reach and plan out how the next few months of the team will look like. A good resource to think of what a team can work with is Team topologies which calls out the multiple ways teams can collaborate to achieve a common goal.

Where will they work within the codebase?

Finally, where will the new teams work within the codebase. Will they overlap modifying the same files and creating merge conflicts?

In order to maximise the performance of a decoupled team, the architecture they work on has to similarly be also decoupled. In “Accelerate, the science of lean software and dev-ops independent teams”, they define a decoupled architecture as one where you can:

• Make large-scale changes to the design of their system without the permission of somebody outside the team.

• Make large-scale changes to the design of their system without depending on other teams to make changes in their systems or creating significant work for other teams.

• Complete their work without communicating and coordinating with people outside their team.

• Deploy and release their product or service on demand, regardless of other services it depends upon.

• Do most of their testing on demand, without requiring an integrated test environment.

• Perform deployments during normal business hours with negligible downtime.

The first likely blocker you’ll find on this comes from Conway’s law:

'Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.' 

— Melvin E. Conway

As your team has been so far a single unit designing a system, in all likelihood, you’ll have a monolithic system or component to share amongst multiple teams, and therefore, you won’t have a decoupled architecture.

The first step towards having a decoupled architecture will come from applying an Inverse Conway manoeuvre, which consists of hacking Conway’s law, and starting to create the architecture that will enable your future team structure to work correctly. This can be performed early on in the team’s lifecycle, but consider that it will come with an overhead cost in planning and executing the layer separation required.

Engineering, engineers, team, scaling up


In summary, scaling a software engineering team can be a time consuming endeavour, but when executed properly, you have the chance to multiply the velocity of your product development by horizontally scaling the number of engineers you work with.

In order to do so, you have to carefully plan the team structure so that your teams remain decoupled, and create a new architecture that scales to a larger number of developers.

You’ll also find yourself in an awkward phase where you are on the verge of needing to split the team, but not fully there. A cost/benefit analysis that considers how the tradeoffs will evolve over time will help guide your decision to act early or not.

Further reading

Tech lead, engineer, engineering, teams,

Josep Rodriguez

Tech Lead,London

Tech lead, engineer, engineering, teams,

Josep Rodriguez

Tech Lead,London