How to split teams

There are a few things to keep in mind when it comes to splitting teams.

First of all, consider Conway's law:

Organisations that design systems are constrained to produce designs that are copies of the communication structures of these organisations.

This is helpful information. You can use it to the advantage of the entire organisation. Depending on the stage of the company or the industry your company is in, some architectural decisions work better than others. So you can flip the information the law provides: only specific organisational structures produce the architecture that fits your context better. The idea is to help design a large system by organising teams so that they naturally (as in according to Conway's law) design the system correctly.

With this in mind, the whole process of splitting teams becomes a quest for a good splitting criteria. The criteria need the same brevity and clarity that a team's name and mission need. Splitting has to be meaningful and it's tricky because some splits only make sense on the surface.

A common example is splitting teams by platform boundaries: the typical one-to-one mapping between team names and platform parts. You have a backend team, an API team, a frontend team, and so on. This split seems meaningful, but it forces your teams to keep the existing architecture as is and, far worse, it bounds the future organisational design of your teams to your technical decisions. Last but not least, it make no sense to people outside of product development.

Finding the right split is a quest for simplicity. As I often say, simple isn't easy. This problem needs strategic thinking. My suggestion is to sketch on a whiteboard what your teams would look like under different splitting criteria. Then you benchmark each split using this checklist:

• Does the split make sense to the rest of the company?
• Do your product managers buy the split?
• Can you picture how to split teams further from here?

The order of questions is not relevant here, but they all need a clear, positive, and strong answer.

In my experience, the best approach is to search for inspiration in the business model. Loosely mapping the teams to the various parts of the business model has a few intriguing benefits:

• You can align the strategic goals of the company with your hiring strategy.
• The business model changes slowly, yet it may change often. The more an organisation understands its market, the more it adapts its business model to it. Structurally adapting to these changes is a powerful tool because the it resonates with the entire organisation.
• The roadmaps of your teams mirror the overall strategy of the company.
• Naming makes sense for everyone. The name "API team" doesn't tell much about the team to the people outside of the product development. The name "Driver app team", on the other hand, has a meaning both inside and outside of the product development team. You also want the meaning to be the same for everyone. An amusing example from my career: the "Ops team". In one company I worked for, this name created a lot of confusion. We managed warehouses ourselves, so the company had another "Ops team". We ended up renaming our Ops team to "Platform team" which, no surprises here, was also a more accurate name.

Another way of validating splits is picturing how the new product roadmaps would look like. I'm purposely ignoring backlogs because they cover what a team needs to do right now or in the immediate future. Splitting teams is about a long-term strategy.

I left the most important aspect of a split out of this conversation, so that I could give it the right space before we move on to a different topic. Whatever way you split, diversity is the key factor for the future successes of your teams. You don't want to split in a way that some teams become too homogeneous. These teams rarely innovate and their failures can create unpleasant dynamics in the organisation. Sketching different splits on some whiteboards helps with diversity, too. Try sketching different splits with people's names. They are only sketches for now, so don't sweat it trying to get it right. It's OK to put people in teams without having involved them yet. The point of sketching isn't to come up with a decision, it's to get a sense of what you can and can't do.

Depending on how you split, it may make sense to have teams with, say, no JavaScript skills. Every time you split, you specialise teams further. Smaller teams can achieve more by having a more focused roadmap and backlog. Therefore, as you scale, hyper specialisation is somewhat expected.

As the discussion may feel a little too abstract, let me share two examples. In both examples, we start with one team and work out a way to split the teams further as they grow.

Marketplace

In the words of Wikipedia, a marketplace is:

A location where people regularly gather for the purchase and sale of provisions, livestock, and other goods.

Reading the history of markets is fascinating! They have always existed so it's only natural that many companies create digital marketplaces.

Marketplaces deal with two completely separate groups of users: buyers and sellers. Each group has its own needs. So, even at the earliest stages, the natural split that comes to mind is:

• Sellers team
• Buyers team

I picked marketplaces as one of my examples because it leads to an interesting conversation despite how "obvious" the first split is.

Let's benchmark this approach with the checklist I proposed in the previous section.

• Does the split make sense to the rest of the company?

  The split is natural to the people outside of the product development organisation.

• Do your product managers buy the split?

  Product managers can often draw a clear line between the features for sellers and those for buyers. The two teams share important parts of the data model, which may be worrisome at first. For example, buyers place orders and sellers fulfil them. With a two-team split, Conway's law does its magic. To avoid getting in each others's way, the two teams agree to build a system with some message bus as a boundary. The buyers team places orders in their system and notifies the sellers team about it. The sellers team takes it from there and notifies the buyers team about changes in the fulfillment process. Each team has their own data model and their contract is clear: the buyers team is responsible for producing the correct order of events and the buyers team is responsible for consuming those events.

• Can you picture how to split teams further from here?

  The answer to this question is product dependent, so I can only share how I would go about it. Further splits are a matter of focus. For example, imagine your company sees offering a richer buyer experience as an opportunity to win over competitors. The company strategy gives you the hints you need to split teams further. It may make sense to segment or specialise features by the kind of buyer. Data analysis may suggest some segments to you that are meaningful and relatively stable. Unfortunately, I've seen a lot of arbitrary segments in my career, too.

Subscription business

Subscription-based business models have appealing properties. Revenue streams are a function of the number of subscribers and, often enough, understanding a business model's potential is a matter of a few multiplications.

For the sake of this conversation, our subscription business works like this:

• Customers choose a plan.
• Each plan unlocks a set of features for a price.
• Customers buy a plan and are charged monthly for it.

From a user-base perspective, subscriptions are more straightforward than marketplaces. They have only subscribers. You are either subscribed to a product or you are not.

In subscriptions, the customer journey is central to the business model. You want to understand two things: what convinces people to subscribe and what keeps them subscribed. Here's a trivial breakdown of the customer journey:

• Alice is a potential customer because they're visiting the website.
• Bob started a trial period.
• Zara is a subscriber.

The marketing team of a subscription business often splits their efforts in acquisitions and subscriptions. The budget allocation for each bucket depends a lot on the phase the company is in, but you need both. You can't run a subscription business without:

• Converting leads into subscribers.
• Keep subscribers happy.

This conversation suggests an interesting split:

• Acquisition team.
• Subscription team.

Let's run the checklist again.

• Does the split make sense to the rest of the company?

  You have a team that takes care of the customers before they subscribe and another one -- after they subscribed. Most likely, the whole company thinks about customers that way.

• Do your product managers buy the split?

  The kind of features you need to acquire customers has nothing to do with the features you need to keep them, so it should be easy for a product manager to imagine distinct roadmaps. Balancing the two roadmaps may be challenging. Of course, a subscription business always needs features for its subscription base. That's always true for such a business. That said, roadmaps are still dependent on what a company's needs are at any given moment. For example, if you don't have enough customers yet, you should focus on your acquisition efforts. This is often a cyclic process in a subscription business, so the hint is to optimise splitting for flexibility.

• Can you picture how to split teams further from here?

  In a successful subscription model, the customer journey tends to become more specialised over time. The organisation learns what works for whom and optimises the journey. Sometimes this means more waypoints in the journey itself, other times this means different journeys for different audiences. Those are great hints for further splits. Teams end up creating these journeys themselves sometimes. For example, a trial feature can become so successful that it can feed an entire team for a year.