Not too large, not too small.

If you google “the best size of an engineering team” you would come to the numbers 5 to 7 quite fast. And it won’t be wrong: having 5 to 7engineers per team is ideal. There are several arguments to justify that:

• Reasonable span of control for an Engineering Manager. She has enough time to host regular 1–1 dialogues, prepare for them(!), act on points discussed and etc. Engineering Manager has a room to coach every single engineer and still be involved in a wider dialogue about priorities, objectives and value delivery.
• Feeling of a camaraderie and bonding within the team. Average person feels safe and intimate within the group of around 7 people. That’s why rifle quad (primary military unit) has the same size.
• Resilience vs agility balance. In one hand, team performance is not impacted by sick leaves, vacations, personal days. In other hand, all rituals (planning, retrospectives and etc) can be done fast and efficient.

The problem with reality is: it’s not always ideal. You won’t be able to have all teams around an organisation being perfectly sized at any given moment in time. That’s why it’s important to understand what the challenges of having odd size team are and what trade-offs you have to make. Let’s take a look on two cases which happen quite often.

Scenario A: team is too small. There are 3 engineers.

Often it happens when you want to add a new team and split a regular team of 6 engineers into two smaller teams of 3 people with an aim to hire more engineers later.

Span of control: too small for an experienced Engineering Manager, which leads to underutilisation of the leadership talent. He can surely steer two small teams to success. Alternatively, it might be a good place for the first-time manager to learn and gain expertise. So trade-off to make: first-time lead, multiple teams per manager or underutilisation of a talent?

Camaraderie and bonding: in my experience, small size won’t affect team’s bonding on a short notice, but it might create challenges for the growth of a team which was understaffed for a longer period of time. So trade-off to make: should we hire more engineers now or face problems later?

Resilience vs agility balance: team’s ability to build and run has been affected considerably. One person is ill, second took a vacation… and say goodbye to that new shiny feature. I am not even mentioning on-call duties and mission-critical services maintenance. So trade-off to make: stable run and delivery vs not this team?

In a nutshell: you will have small teams. Make sure they won’t stay small longer than absolutely necessary.

Scenario B: team is quite big. It has 12 engineers.

There are 2 types of teams, that have tendency to become large:

• Complicated sub-system team.
• Platform/SRE team

If you want to learn more about team topologies, I high recommend: https://teamtopologies.com/key-concepts

Crucial moment(!): neither of those teams has to be large. Complicated sub-system team often maintains a legacy system, with several key-person exposure. Solving those will effectively scale team down. And it’s absolutely possible to handle SRE duties with 5–7 engineers with a good documentation, polished processes and extensive automation.

But, as I mentioned above: World is not ideal. So you have a large team. What are consequences and possible trade-offs?

Span of control: too much of an Engineering Manager. Let’s do the math: 12 bi-weekly 1–1 (6h) + preparing for them (6h) and acting after (6h) = 18h. This is the half of your manager’s time, if she is working 36 hours week. So trade-off to make: should an Engineering Manager spend time on growth of talents or team’s goal, focus and delivery? It won’t be time for both.

Camaraderie and bonding: if the team too big the sense of intimacy is gone, so people will combine smaller sub-teams and call them home. So trade-off to make: necessity to have a larger team vs week bonding and team spirit.

Resilience vs agility balance: more engineering means more resilience. Sometimes 🙂 As I mentioned above, often larger team means key-person exposure and not resilience. However team’s agility will be impacted significantly. So trade-off to make: resilience (or semblance of resilience) vs speed of delivery.

In a nutshell: you have a large team. You might be told, that it was always like that. Challenge this thought. Scale it down.

At the end

• There are golden standards. Two pizzas Amazon principle is one of those. Just follow it and you can’t do VERY wrong.
• There are ALWAYS exceptions. Be smart about them and make a conscious decision on what trade-offs you are ready to make.
• Be transparent with both Engineers and Engineering Managers. Explain them the situation, trade-off you made and the way forward!

p.s. Stay tuned for the second and third rules of the team!