Share this article

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

How to Size and Assess Teams From an Engineering Lead

Sizing engineering teams

This post lists the key insights from this article, an interview with Will Larson, former Engineering Leader at Digg, Uber and now Stripe.

In this exclusive interview, Larson shares his system for gauging the size and state of engineering teams — in not only a highly efficient and effective way, but also with a deeply empathetic and ethical approach. Larson builds on excerpts from his book, An Elegant Puzzle: Systems of Engineering Management to bring ratios and frameworks to structuring team size, combining and spinning up teams, and assessing and accelerating team progress.

It’s easy to do the right thing for people you like. It’s easy to do the right thing when it’s cheap. It really only matters when it’s difficult.

Sizing Teams is at the core of organizational design

“The most powerful unit of work is a gelled team. People who know how to work together and are practiced at working together can accomplish truly remarkable things. When managers design too literally around the current product or architecture, they churn people and lose what I think is the only truly renewable source of energy in the world: people who really love — and know how — to work together.”

Here’s Larson’s playbook in his own words, via an excerpt from his book:

Managers should support six to eight 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-of-managers should support four to six managers.

This gives them enough time to coach, to align with stakeholders, and to do a reasonable amount of investment in 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.

On-call rotations want eight engineers.

As teams holding their own pagers have become increasingly mainstream, this has become an important sizing constraint, and I try to ensure that every engineering team’s steady state is eight people.

Small teams (fewer than four members) are not teams.

Teams with fewer than four individuals are a sufficiently leaky abstraction that they function indistinguishably from individuals. They are also fragile, with one departure easily moving them from innovation back into toiling to maintain technical debt.

Keep innovation and maintenance together.

A frequent practice is to spin up a new team to innovate while existing teams are bogged down in maintenance. But innovating within existing teams will get you higher morale and a culture of learning, and will avoid creating a two tiered class system of innovators and maintainers.

Other principles in his playbook include:

  • Teams should be six to eight during steady state.
  • To create a new team, grow an existing team to eight to ten, and then bud into two teams of four or five.
  • Never create empty teams.
  • Never leave managers supporting more than eight individuals.
Sizing teams and groups of teams using sizing rules

I’ve come to believe that dividing organizations by eight lets you see their future. Know the load on managers and you can predict with confidence what’s ahead.

Meaningful investment in each report.

“In a fast-growing company, team ratios will fluctuate. Managers may spend more time with new hires than with tenured people.”

“Eight engineers means eight hours of 1:1s. Say you have four peers with whom you’re spending half an hour per week. Now you’re up to 10 hours. Then there are weekly team meetings, such as a couple sprint check-ins and a larger team meeting. Now you’re up to 12 hours a week. Of course, you’re interviewing, because you’re growing quickly. Add three hours of interviewing, and you’re up to 15. Then there’s going to be an All Hands and cross-functional meetings, so let’s go up to 20,”

“But when the business is growing quickly, there’s always context to communicate and act on, so I haven’t found that one can dip below this commitment without creating inefficiency and pressure. That’s why it’s not only productive, but ethical for this manager to keep her team size to eight people.

Moving up and making room.

Of course, the manager wants to grow like any employee, but the ethical manager recognizes it’s necessary to her people — and the organization — that she grows into a new position so her role becomes an open opportunity for others on her team or at the organization.”

On gauging and accelerating progress

Four states of a team

The framework starts with a vocabulary for describing teams and their performance within their surrounding context.

Four stages of a team’s progress, from falling behind to innovating

A team is falling behind if each week their backlog is longer than it was the week before. Typically, people are working extremely hard but not making much progress, morale is low.

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 begin major new projects.

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..

A team is innovating when their technical debt is sustainably low, morale is high, and the majority of work is satisfying new user needs.

System fixes and tactical support

For each state, here is the strategic solution that I’ve found most effective, along with some ideas about how to support the team while that solution comes to fruition:

  1. When the team is falling behind, 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.
  2. When the team is treading water, the system fix is to consolidate the team’s efforts to finish more things, and to reduce concurrent work until they’re able to begin repaying debt. The focus here is on helping people transition from a personal view of productivity to a team view.
  3. When the team is repaying debt, the system fix is to add time. Everything is already working, you just need to find space to allow the compounding value of paying down technical debt to grow.
  4. Innovating is a bit different, because 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, operate continuously in innovation, and avoid backtracking.
5 min​ read

Subscribe to our newsletter Weekly Bytes to get our curation of the top 5 articles of the week.

Subscribe to our newsletter Weekly Bytes to get our curation of the top 5 articles of the week.

Need visibility in your software development lifecycle?