How I structure my teams for growth

Having worked in a number of scale-ups in the last 10 years, there are a few principles I have adopted for scaling Tech and Product teams.

The first one, is to organize teams to be cross-functional. Generally, to get any product built, you need Product Managers to represent the business, Product Designers to represent the customer and Engineers to build.

I tend to organize teams to be 5–10 people, following the two pizza teams rule, made famous at AWS, with a Product Trio leading each team.

If more people are needed to achieve a specific goal, I cluster teams in group of teams, with a Product Trio in charge of the group.

With Engineering usually being the larger group of people, it’s not uncommon to also have “Staff/Principal” Engineers supporting the Trio on technical decision that span across multiple teams.

Project Management can be done by the Product Manager, the Engineering Manager, or sometimes an Engineers in the team (depending on the given project or goal), but the trio is jointly responsible for the Output and Outcome of the team as a unit.

Once the Product Trio model is established, it’s important to clarify roles and responsibilities of the Trio, team ceremonies, and collaboration models in each team.

One very important thing is to keep reporting lines by discipline.
Line Managers are primarily responsible for the growth of each individual, so it’s important that the person managing an individual contributor knows what the person job is, in details.

Once the number of teams grow beyond 3 (so 15–30 people), cross team collaboration becomes more critical. It’s easy for teams to start diverging and working in different ways, being that how the code is written, ceremonies run and how products are built.

Establishing groups of people that are cross-team, but grouped by discipline and skills, sharing and agreeing on working practices becomes critical.

The “Spotify Guild” model has been where I’ve taken a lot of my inspiration from.

Last but not least, it’s important to establish a clear taxonomy in the communication channels used.

In Slack, I generally create one channel per team (and an ad-hoc one for me to have discussions with the trio of each team), one channel per guild (and one for me to have discussions with the team leads).

These are just some of the basic principles I follow to organize teams.

A book I particularly like about team types and how they interact with each other is https://teamtopologies.com/.