Splitting one product team into two

This blog post explains why and how we (Climate Policy Radar) decided to split from one big product team into two smaller teams.

The problem with working as one big team

As the team grew in size, we found it increasingly difficult to do everything together as a whole team.  Meetings took a long time to get through. Most people found it difficult and unnecessary to stay on top of everything being done across the organisation.  “Not having enough focus time to get things done” had started to come up in retrospectives.  

We had 14 people and more hires on the way.  As you can see from the below image, that meant many lines of communication to stay on top of.  

14 is a lot of people for one team (and we were scheduled to be 17 within a couple of months).  But it’s not a lot for a multi-team organisation.  Having multiple teams usually means there needs to be a coordinating team to join the dots, but with only 2 teams to coordinate there’s a real risk that a coordinating team becomes overkill.

Four goals of our new two-team approach

1. Have small multidisciplinary teams with all the skills and capabilities they need to deliver value with minimum dependencies
2. Ensure teams stay aligned with minimum overhead
3. Reducing meeting and information overload to give people more focus time
4. Maintain strong social bonds as an organisation

Below I describe the approach we took for each.

1: Have small multidisciplinary teams with minimum dependencies

What size is right?

Teams need to be big enough that work doesn’t grind to a halt when one or two people are away, and small enough that all the lines of communication don’t slow everyone down.  In this thoughtful article about recommended team sizes, 9 is generally accepted as the maximum team size with lots of evidence indicating that this is too large in most cases. So I encouraged us to aim for team sizes of between 4 and 8.  

Where to draw the dividing line?

My most important consideration was ensuring that each team had all the skills and capabilities they needed to deliver value autonomously. This is so that dependencies between teams would be minimised.  I also didn’t want to be reforming teams every couple of months. High-performing teams develop with time, and constant change is disruptive (I learnt this lesson the hard way during our experiment with quarterly planning on GOV.UK). 

Through our work on launching the Global Stocktake Explorer, we had organically started to work as separate subgroups. Data scientists and policy analysts were focused on collecting, preparing, structuring and analysing UNFCCC data.  Engineers were focused on building the product, and our product’s capability to support bespoke project work (in this case, that meant ingesting and parsing the UNFCCC data). Our data engineer and frontend developer found themselves contributing a little bit to both teams.  

Looking ahead at our roadmap for the next 6 months, this division continued to make sense. There was a clear need for data science and policy to work together to deliver bespoke projects for partners and experiment with ways to measure, structure and improve our data.  The engineers needed to focus on building the product capability to bring in more structured data at scale.  There would still be a need for collaboration between teams. But this approach meant fewer dependencies between teams than any other option we could think of. So we decided to split into two teams. The teams got to pick their own names, and in an attempt to describe what te teams were doing, we ended up with one team called “R&D” and the other team called “Product”.

Naming teams
I regret that the teams ended up being named R&D and Product (even though initially it was my idea). There are two problems with this. Firstly, naming the teams in this way creates the impression that one team hands off discovery findings to the other to build. This is not the type of culture we want to promote – both teams should be doing a mix of discovery and delivery activities.  Secondly, it confuses team names with other words that we use day-to-day in our communication with each other.  

Dividing along functional lines
One thing that makes me nervous about this split is that it mostly involves engineers on one team and non-engineers on the other.  There is a real risk that this creates dysfunctional silos.  Once the product reaches a level of technical capability where data science insights can be more rapidly integrated into product, I would like us to explore more cross-functional teams which combine software engineering, data engineering, data science and policy people. 

A product manager on each team
We are fortunate to have a new associate product manager join us a few weeks ago. We will each focus on separate teams, but I’ll also mentor her and lead product strategy at the organisation level.

How we handle cross-team work
The assumption is that most people will spend 95% of their time working with other people on their team.

The exceptions to this are our:

1. Data Engineer. He will be working across both teams.  This is a bit frustrating for him as he needs to be in double the meetings. But he’s making the most of it and is helping to keep both teams aligned.
2. Lead Engineer and Lead Data Scientist.  They need to work together a fair amount both to keep their respective teams aligned and to pair on some of the upcoming functionality that requires both of their skill sets.

There will always be a need for people from different teams to work together on an ad hoc basis. When this happens we will encourage people to self-organise.  We might also set up temporary teams or temporarily have people join other team meetings.  Though if this type of cross-team work happens a lot in consistent ways, that will indicate that we might need to rethink our team topology.

2: Ensure teams stay aligned with minimum overhead

Shared strategy.
Both teams are working towards common strategic priorities.  For example, our next strategic priority is to bring passage-level structure to documents.  This requires the R&D team to improve the quantity and quality of concepts we can detect at passage level.  And it requires the Product team to enable the product to display this data to our users.  

Shared show & tell.
Our weekly organisation meeting includes a show & tell with members from both teams presenting progress, and leadership providing strategy updates.  This ensures strategic direction, learnings and progress are shared.  There is a real focus on making sure we have lots to share at show & tell and that it is recorded for anyone absent to watch in their own time. 

Shared weeknote. 
Our weekly note includes work done last week / planned for next week from each team.  This keeps everyone aligned on what is happening in the week ahead.  We take great care to write a thorough weeknote which captures all the key progress throughout the week, and flags key updates in Slack that might have been missed during the week.

Shared multi-team plan. 
This allowed us to see all work from both teams in one place, and see where there are dependencies that might need to be managed. 

Fortnightly review of the multi-team plan.
Every fortnight, one or two representatives from each team look ahead at the plans for the month ahead, with a focus on managing risks and dependencies.

Use of public slack channels/task tracking/documentation storage. 
All information is open by default.

Various regular 121s between team members on different teams.
Eg. CTO, Data Science Lead and Engineering Lead meet weekly. And Product Managers from each team meet most days.

3: Reducing meeting and information overload to give people more focus time

One all-team meeting per week. 
We stripped back our all-team meetings to just one at the end of the week.  This is the all-hands that includes strategic updates and show & tell.

Team meetings are more focused. 
Only having 5 or 6 people in a meeting means that team time together is much more productive than it was before.

Each team decides a cadence for planning, standups and retrospectives that work best for them. 
Both teams are adopting different approaches: one team likes to get all their meetings out the way at 9 am and focus for the rest of the day.  One team have clumped all their meetings into two afternoons per week.  Both teams are using their retrospectives to continuously improve their ways of working.  

Everyone is being encouraged to think about how they can maximise their productive time as a team and as individuals. 
Read my previous post on managers and makers time for more on this topic.

4: Maintain a strong organisational culture

Have a regular program of offsites and away days that all team members attend.
We have some fully remote team members, but we try to make sure we come together as a full organisation every couple of months.  When we do, we always plan socials.

All team retrospectives.
Every couple of months, we take half a day to have an all-team retrospective.  It’s not easy to do a retrospective with 14+ people in an hour. We found that doing retrospectives less often but more thoroughly gives us the chance to dig into the detail about what needs to be improved and identify actionable improvements we want to make as a team.

Two days per week in the office. 
Most of our team live within commutable distance of London. We generally all work in the office for 2 days per week and all try to do lunch together when we do.

Everything I mentioned under Goal 2 to ensure teams stay aligned also helps maintain a strong organisational culture.

---

Thanks for reading! All views are my own and not those of my employer.