Split

A growing team is a good thing.

It probably means that you're doing something right and the business wants to invest more into your situation, or perhaps the business has finally recognised that the size of the team is too small for it's set of responsibilities.

Unfortunately, growth can come with problems. There is a tangible limit to how large a team can get before you start to see issues, like reduced team happiness and cohesion, or progressively lower benefit from each additional added person.

It also becomes really hard to manage a lot of people all at once.

Once you do start to see problems, it's time to think about breaking up the band.

We Are What We Believe We Are

The first step in splitting a team is deciding what line you're going to split on.

If you've got some long-running projects, you could split the team based on that, but I wouldn't recommend it. Projects have an expected duration, and once the project is delivered, what happens to the team?

Instead, I suggest splitting on domain.

A domain is an overarching theme into which a set of capabilities or responsibilities are bucketed. It probably has a ubiquitous language of its own, though it might not.

Figuring out what your domains are is hard, especially if you have many. You need to create bounded contexts around sets of responsibilities and capabilities and then, even more painfully, name them clearly.

Here is an example drawn from my own experience, heavily abridged to the sake of your sanity.

My team at Atlassian is responsible for a few things:

• making sure there is enough infrastructure to host our Jira and Confluence Cloud users
• orchestrating the movement of Jira and Confluence Cloud users within our infrastructure
• making good decisions about where Jira and Confluence Cloud users should go within the infrastructure

The first point is Shard Capacity Management and the second point is Shard Migrations. These are both clear and distinct domains.

The third might be a separate domain (Tenant Placement), but for now, it's bundled in with Shard Migrations, because making good decisions about where users should go seems like a key part of moving them around.

In fairness, there is more art than science to identifying domains and I'm not going to spend any more time going into how you might go about it. It's complicated and iterative and one of those things where the more you talk about it, the more you realise that it's slightly wrong but it's too late to go back and change everything.

The reason for splitting on domains is simple: when you have a big group of people, and you want to split it into smaller groups, each group should inherit some of the problems, so as to evenly split the pain as best you can.

You Are Different From The Rest

Splitting a team is not a frivolous thing though and should be treated with the appropriate amount of care and respect.

That's not to say that you should um and ah about it perpetually, there is still room for being decisive and moving quickly, you just need to make sure that you don't cause more damage during the split than you were intending to prevent over the long term.

For example, don't just go and design a perfectly split team in isolation and then unveil it all at once.

Not only is that a generally bad management strategy, but it also means that you're less likely to come up with a good proposal. The best solutions are iterative and involve other people, so you should message your intent early and often, create and share different models and solicit feedback from as many people as possible to form a balanced view of the impacts.

As with talking about any important topic, managing the feedback can be tricky.

People get nervous around team splits. They represent a fairly monumental change in the scheme of things, a shuffling of people and responsibilities and a disturbing of any existing relationships and power structures.

That doesn't mean it's not necessary, but as a manager it's important to go into the situation with a clear idea of what you want to accomplish and an underlying acceptance that you won't be able to make everyone happy. You need to understand that you are going to cause short-term disruption in exchange for long-term benefit.

Well, that's the hope anyway.

Rejoice!

As is typically the case, this blog post is based on my own experiences.

I've got a team. It's growing. It had too many responsibilities. I started to see problems in team cohesion and cognitive load. I was having difficulty managing that many people.

Luckily for us, we'd already put a significant amount of effort into identifying the domains that we were responsible for. We actually did this because we were hoping to shed one of our domains to another team a few quarters ago, but that didn't shake out as expected. With domains already identified and relatively easy to use as a dividing line, that's the path we went down.

My first preference was to go for a hard-split and try to solve all of the problems at once. You know, literally create another, independent team from an organisational point of view that was responsible for a subset of our domains, with a brand-new manager in charge.

Unfortunately, we didn't have a manager available, so I had to compromise.

Instead, I did a soft-split, extending on the streams model that the team was currently using and making the streams larger, with a more well defined and self-contained set of responsibilities instead of being project focused.

This was probably the less disruptive approach anyway, because it didn't involve creating a brand-new team from a business point of view and wasn't reliant on handing over people management to a new person while also trying to change the way that we were working.

Of course, the downside of this approach was that it wouldn't reduce my own overload. In order to mitigate that a little bit, I established a stream lead in each one of the streams, which is basically just a Senior Engineer acting as a pseudo-manager, without the people management responsibilities.

From my point of view this was a win-win; a good opportunity to show leadership, organisation and facilitation skills for the person filling the role, and a good way for me to delegate some of my responsibilities.

The Broken Are More Evolved

Splitting a team is painful and requires a significant amount of effort, but it's for the best.

Smaller groups with smaller sets of responsibilities tend to operate much better than large groups with large sets of responsibilities. It's all about controlling the cognitive surface area and creating clarity.

I've never actually had to split a team before, and the experience I've outlined above is still very very fresh. It's barely weeks old.

However, in the very short amount of time that we've had the two more focused streams with clearer responsibilities, I've noticed some positive improvements.

I'll know more once everything has settled down a bit and the paint has had time to dry.

I'm cautiously optimistic.