Sizing teams
The big engineering teams we created in my department after a reorganization did not work as well as I hoped. I always liked Larsons writing on Sizing Engineering Teams, but felt I needed a broader framework to reason about team size.
The magic number
Team size is a trade off between interests. How this trade off works out differs per team. Team scope, complexity of the business and the experience of the team’s manager are all factors.
When we are sizing teams there are different dimensions to consider:
Resilience
For overall resilience, bigger is better. The impact of one person falling ill in a seven person team is far less than in a team of three.
Span of Control
Managerial span of control is optimal somewhere between four and eight direct reports, depending on how we see the role of the first line manager. Small teams may underutilize managerial talent, but they do create bandwidth to do projects or hands on work ,whereas larger teams gradually push the manager into a People and Process only role.
Product management
In a similar way we need to optimize for the bandwidth of the Product Manager. Too little scope will underutilize them and with too much it will become hard to align with the team’s stakeholders as well as to keep feeding the team relevant problems to solve.
Running it
If the team is the unit for technical ownership small teams of two or three people can be very efficient building new services, but are a serious risk running services in production.
Scope
For the team to function as a cohesive unit the team’s technical scope needs to fit into the head of each individual engineer to enough level of detail to actively contribute to design discussions and confidently jump in on firefighting efforts.
Process
Team processes, such as designing, planning and grooming require at least a couple of heads to come up with the best ideas. But large teams with more scope will have less efficient communication and meetings and will require more context switching.
Safety
A team is also a home within the company, providing emotional safety, especially for new hires. This starts to fall apart when it gets bigger than eight people.
Autonomy
To achieve team autonomy we should give the team a scope that allows it to influence business relevant KPIs with minimal dependencies. This is not easy in a large organization. If it can’t be achieved on the team level it should at least be done at the level of the department.
In conclusion
When the dominant craft is engineering and the engineering manager runs the team I think the magic number is five. Five engineers to an engineering manager. With a Product Manager and one individual contributor from a different craft reporting to their own craft manager, it gives the team a total size of eight. This still neatly fits the Two Pizza Rule.
