When I transitioned from supporting a team to supporting an organization, I started to encounter a new category of problems I had never thought about. How many teams should we have? Should we create a new team for this initiative or ask an existing team to take it on? What is the boundary between these two teams?
These questions were the gateway to the obscure art of organizational design. As I’ve gotten more exposure, I’ve come to believe the fundamental challenge of organizational design is sizing teams. You’ll find yourself sizing teams在重组，以适应招聘的增长，以及在考虑如何支持新项目时。这将是一个不寻常的月份，你不会考虑团队设计的某些方面。
While I’m skeptical that there exists a unified law of team sizing, I have iterated onto a useful framework that solves the majority of cases I encounter. That framework has in turn led to a standard playbook. Both are short, opinionated and hopefully useful!
The guiding principles I use for sizing teams are:
- Managers should support 6-8 engineers。This gives them enough time for active coaching, coordinating and furthering their team’s mission bywriting strategies,leading change, and so on.
- Coaches。Managers supporting more than eight or nine engineers typically act as a coach and a safety nets for problems. They are too busy to actively invest into their team or their team’s area of responsibility. It’s reasonable to ask folks to support larger teams during the transition to a more stable configuration, but it is a bad status quo.
- Managers should support 4-6 managers。这为他们提供了足够的时间向教练，与利益相关者一致，并对他们的组织进行合理的投资。另一方面，它也会让他们忙碌足以让他们对他们的团队创造工作。
- 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.
- Oncall rotations want 8 engineers。For productiononcall职责, I’ve found that two-tier 24/7 support requires eight folks. As teams holding their own pagers has become increasingly mainstream, this has become an important sizing constraint, and I try to ensure every engineering team’s steady state is eight folks.
- Shared rotations。It is sometimes necessary to pool multiple teams together to reach the eight folks necessary for a 24/7 oncall rotation. This is an effective intermediate step towards teams owning their own oncall rotations, but it is not a good long-term solution. Most folks find being oncall for components they’re unfamiliar with to be disproportionately stressful.
- Small teams (<4) are not teams。I’ve sponsored quite a few 1-2 person teams, and each team I’ve regretted it. To repeat: I have regretted it every single time. An important property of teams is that they abstract the complexities of the individuals that compose them. Teams with fewer than four folks are a sufficiently leaky abstraction that they function indistinguishably from individuals. To reason about a small team’s delivery, you’ll have to know about each oncall shift, vacation, and interruption. They are also fragile, with one departure easily moving them from innovation back into toiling to maintain technical debt.
- 保持创新和维护。A frequent practice is to spin up a new team to team to innovate while existing teams are bogged down in maintenance. I’ve historically done this myself, but I’ve moved towards现有团队内的创新。This requires very deliberate decision making and some bravery, but in exchange you’ll get higher morale, a culture of learning, and avoid creating a two-tiered class system of innovators and maintainers.
Fitting together those guiding principles, the playbook that I’ve developed is surprisingly simple and effective:
- Teams should be six to eight during steady state.
- Never leave managers supporting more than eight folks.
Like all guidelines, this is a structure to aid thinking through sizing problems, not a straightjacket to slam shut every exception. The context of any situation deserves careful examination, but increasingly I’ve found the long-term cost of exceptions to outweigh what I once considered their strengths.