Defining teams for a product development organization
Four interesting ideas about product org design
Recently I’ve been again thinking a lot about setting up product development teams, since we are working on growing the product and engineering orgs at RevenueCat.
I’ve written before about what I consider the best in class principles to follow for the product development organization and empowered product teams. In this article, I want to get a bit more practical: how do you decide how to size teams, where to draw the lines between teams, and how to grow them?
Below, I will share some interesting ideas I’ve come across in the following areas:
- Team size and PM:Eng ratio
- System architecture and team setup
- Types of teams
- Hiring and scaling approach
Team size and PM:Eng ratio
Whenever you are changing the team setup (for example, because of growth or reorganization), an important factor determining the number and composition of teams is the size of individual teams.
In general, cross-functional product teams will have one product manager and a certain number of engineers. The number of engineers per product manager is often called the PM:Eng ratio. Design is mostly paired 1:1 with product management; in other words, a product team will have one product manager and one product designer. Depending on the company, there may be other roles on the team as well (e.g., user research, QA, data science).
There is, of course, no absolutely “correct” size for a product team, and many models can work. There are many factors influencing the team size, including the domain, the level of experience of team members, as well as the complexity of the work (technology, UX, business aspects).
However, there is a quite clear consensus on what is generally considered the “normal” range for the size of a product team. While for your organization, a different size might be optimal, it is wise to deviate from the “normal” range with care and deliberation only.
Standing in for a lot of writing on the topic, let me point you to Ken Norton’s piece on the PM:Eng ratio, where he summarizes the ideal ratio to be 7±2 engineers for each product manager. This team size is also reflected in Amazon’s famous “two pizza teams” (teams small enough to be fed by two pizzas, though I’ve joked that that depends on the size of pizza, in Italy generally two pizza teams would only have two members).
Another data point to support this team sizing: in the great book on engineering management “An Elegant Puzzle”, Will Larson argues that an engineering manager should have 6–8 direct reports. This means that in a team setup where an engineering manager and all their reports make up the engineering part of a product team, that would mean 7–9 engineers complementing one product manager.
System architecture and team setup
How should you decide on the structure and setup of product teams, and where the lines are drawn between different teams?
To make this kind of decisions, it is important to note that in product development, the team setup is tightly linked to the architecture of the system. In this context, many people are familiar with Conway’s Law, which is often shortened to “you ship your org chart”. The full wording of the Law as defined by Mel Conway in the late sixties is “organizations which design systems […] are constrained to produce designs which are copies of the communication structure of these organizations.” It is worth noting that the Law isn’t limited to the org chart per se but rather talks about the communication structure. The org chart is of course a subset of the communication structure, because there tends to be a lot of communication up and down the reporting line. However, the communication structure also encompasses other formal and informal lateral lines of communication.
Conway’s Law, among other things, can be understood to mean that teams (which internally communicate extremely frequently and closely) tend to build components and subsystems, and that components and subsystems built by teams that communicate more frequently tend to be more closely coupled.
In terms of dealing with this Law, you sometimes hear the advice “don’t ship your org chart”. This advice is supposed to mean that you shouldn’t just let your system architecture happen (because of the way your organization is set up), but rather that you should be deliberate about the architecture.
However, the way this advice is phrased isn’t helpful. It seems to suggest that you should counteract the forces of Conway’s Law and attempt to build a system that doesn’t reflect the communication structures of your organization. However, that’s clearly an uphill battle. Even if you did manage to succeed, it would be against strong headwinds.
A better way is to use Conway’s Law to your advantage, using the so-called Inverse or Reverse Conway Maneuver. It entails designing the org structure and communication paths in a way that reflects the ideal system architecture. The system that the organization builds will then follow that ideal architecture.
This means that the design and setup of a product development organization can never be decoupled from the technical architecture. Moreover, it means that you need technical knowledge to design the organization.
In terms of team setup, this means setting up teams and their boundaries in the way that they reflect where the system has or should have component or subsystem boundaries. It also means being deliberate about the interfaces between teams which mirror the interfaces between the components built by these teams: close communication will result in closely coupled components, less frequent communication in more loosely coupled components.
This technique should also be applied when thinking about how the system and the organization will evolve in the future. As Marty Cagan notes, this means that the product vision needs to be sufficiently detailed to be able to derive at least the scaffolding of an architecture that can support that vision, so you can today set up the teams to deliver on the path to that vision.
Types of teams
The Book “Team Topologies” by Matthew Skelton and Manuel Pais is a gold mine of mental models for organizational design of product development organizations. It provides a lot of detailed thoughts about the Inverse Conway Maneuver and also supplies a useful nomenclature of different types of teams.
If you just think about Conway’s Law and the Inverse Conway Maneuver, you might be tempted to think: I have a layered architecture (eg, frontend, backend, and database), so I should make teams that align to those layers. However, that idea is at odds with empowered teams, because then no team can deliver value without lots of dependencies on other teams (e.g., frontend teams depending on backend and database teams).
Instead, most teams should take the shape of what Team Topologies calls “stream aligned teams”: Teams that are “aligned to a single, valuable stream of work: this might be a single product or service, a single set of features, a single user journey, or a single user persona.” These teams should be “empowered to build and deliver customer or user value as quickly, safely, and independently as possible, without requiring hand-offs to other teams to perform parts of the work.” This, of course, is precisely the definition of what I call an Empowered Product Team.
Team Topologies argues that stream aligned teams should be the vast majority (90%) of teams. Other types of teams identified in the book are platform teams building internal platforms, complicated-subsystem teams for components which require specific domain expertise, and enabling teams that collaborate with other teams to build up their skills.
Hiring and scaling approach
Another great nugget I took away from An Elegant Puzzle is an approach to hiring and scaling teams that I found somewhat counter-intuitive. It’s clear that hiring and growing teams incurs costs and cognitive load on both the team and its management. Hiring costs a lot of time (preparing job descriptions, sourcing candidates, reviewing resumés, interviewing, debriefing, …), and onboarding new team members is both time intensive because the new team members need help getting ramped up and also drags down the performance of the overall team because the team isn’t fully “gelled” yet.
The advice given in An Elegant Puzzle, then, is to not spread out this cost evenly across the organization and across time because that will cause permanent drag and disruption, and keep teams from ever being in a high performance mode. Instead, Will Larson advocates for clustering that cost by alternating teams between periods of rapid growth and stabilization. In growth phases, the team should focus mostly on hiring and onboarding, and delivery expectations of the team should be reduced during that time.
To decide which teams in the organization to focus on for growth, the teams with the biggest need for additional capacity should be identified. These teams are the ones that are falling behind, meaning that new work for the team piles up more quickly than the team can deliver on its existing backlog.
These teams should be grown rapidly so that they can catch up, meaning they get into a state which is at least what Will Larson calls “treading water” in which the team is getting critical work done, but not paying down debt or starting major new work.
I found this approach counter-intuitive, because my instinct would have been to spread out the cost more evenly, but I find the arguments convincing and will attempt to follow the approach in the future.
I hope this article was helpful. If it was, feel free to follow me on Twitter where I share thoughts and articles on product management and leadership.
