Sizing Engineering Teams
--
What is the optimal size of an engineering team? How many managers should a manager of managers support? How can we stay on the path of a high performing team?
I had all these questions and a lot more when I first started managing engineers at Concur/SAP years ago. However, at that time I was managing mostly down and I had only one team. As I kept progressing in my career, and I kept educating myself on this topic, I came across An Elegant Puzzle — Systems of Engineering Management by Will Larson that helped me answer most of those questions.
The following post summaries my notes on Will’s approach to sizing teams and high performing teams.
Sizing Teams
Managers should support 6 to 8 engineers
This gives them enough time for active coaching, coordinating and furthering their team’s mission by writing strategies, leading change, and so on.
- Managers supporting less than 4 engineers tends to function as TLMs - It’s a role with limited career opportunities. To progress as managers, they’ll want more time to focus on developing their management skills.
- Managers supporting more than 8 engineers act as coaches and safety net problems - They are too busy to actively invest in their teams. It’s a bad status quo.
Managers of managers should support 4 to 6 managers
This gives them enough time to coach, align with stakeholders and to do a reasonable amount of investment into their organization. On the other hand, it will also keep them busy enough that they won’t be tempted to create work for their team.
- Ramping up - Managers supporting fewer than four other managers should be in a period of active learning on either the problem domain or in transitioning from supporting engineers to supporting managers. In the steady state, this can lead to folks feeling underutilized, or be tempted to meddle in daily operation.
- Coaches - Similarly to supporting large teams of engineers, supporting a large team of managers leaves you functioning purely as a problem-solving coach.
Small teams (fewer than 4 members) are not teams
To reason about a small team’s delivery, you’ll have to know about each on-call shift, vacation, and interruption. They are also fragile, with one departure easily moving them from innovation back into toiling to maintain technical debt.
Playbook
- Teams should be 6 to 8 during steady state.
- To create a new team, grow an existing team to 8 to 10, and then bud into 2 teams of 4 or 5.
- Never create empty teams.
- Never leave managers supporting more than 8 folks.
High Performing Teams
Four states of a team
- A team is falling behind — if each week their backlog is longer than the week before. Typically folks are working extremely hard but not making much progress, morale is low, and your users are vocally dissatisfied.
– The system fix is to hire more people until the team moves into treading water. Provide tactical support by setting expectations with users, beating the drum around the easy wins you can find, and injecting optimism. - A team is treading water — if they’re able to get their critical work done, but are not able to start paying down technical debt or start major new projects. Morale is a bit higher, but folks are still working hard and your users may seem happier because they’ve learned that asking for help won’t go anywhere.
– The system fix is to add process to consolidate the team’s efforts to finish more things and reduce concurrent work until they’re able to begin repaying debt (e.g. limit work in progress). Tactically, the focus here is helping folks transition from a personal view of productivity to a team view. - A team is repaying debt — when they’re able to start paying down technical debt, and are beginning to benefit from the debt repayment snowball: each piece of debt you repay leads to more time to repay more debt.
– The system fix is to add time. Everything is already working, you just need to find space for the compounding value of paying down technical debt to grow. Tactically try to find ways to support your users while also repaying debt, to avoid disappearing into technical debt repayment from your users perspective. Especially for a team that started out falling behind and has reached repaying debt, your stakeholders are probably antsy waiting for the team to start delivering new stuff, and your obligation is to prevent that impatience from causing a backslide! - A team is innovating — when their technical debt is sustainably low, morale is high, and the majority of work is satisfying new user needs.
– The system fix: You’ve nominally reached the end of the continuum, but there is still a system fix! In this case, it’s to maintain enough slack in your team’s schedule that the team can build quality into their work, and operating continuously in innovation, and avoid backtracking. Tactically, ensure that folks value the work your team is doing, the quickest path out of innovation is to be viewed as a team that builds science projects, which inevitably leads to the team being defunded.
These fixes are slow. This is because systems accumulate months or years of static, and you have to drain all of that away.
Consolidate your efforts
For each constraint, prioritize one team at a time. If most teams are falling behind, then hire onto one team until it’s staffed enough to tread water, and only then move to the next. While this is true for all constraints, it’s particularly important for hiring.
Fixed costs
- Moving one person can shift an innovating team back into falling behind, and now neither team is doing particularly well
- The fixed costs (number of meetings per individual; standup, planning, grooming, on-call…etc) of managing a team are surprisingly high. Consolidate up to 8 whenever possible
- If a team has more than 8 individuals, many social constructs breakdown
Shift Scope
It’s more fruitful to move scope between teams because it avoids re-jelling costs. If a team has significant slack, then incrementally move responsibility to them. Another approach is to rotate individuals for a fixed period into an area that needs help.
