Splitting our product team from a single team to several teams

Your product team is growing and is getting too big for a single team. But you’re not yet big enough to have multiple full-time teams on different products. What do you do? How do you split the team? This blog is some notes on our approach to it and how we found it. 

The problem – things start to slow down 

As our team grew from 10 to 15 people we started to notice that everything was taking longer than it used to. Daily stand ups were mostly still under 10 mins, but only by being superficially brief. Planning, grooming and retro meetings stretched on as there was so much content to cover. There were many strands of development and people were getting weary from context switching. Lots of people were tagged on pull requests which meant stories took longer to get across the board as we waited for approvals from everyone. Our long-time internal SLA of ‘no story should wait more than 3 days from code complete to release’ was breaking. Pace of development was slowing and as a start-up, that is our main weapon. 

Focus on your upcoming roadmap themes 

We have a large product set and not enough people to have full time teams on each area. Rather than try to carve the product up, we looked at the upcoming roadmap and OKRs for the quarter. We then created teams aligned around a theme, specific changes or particular end result for users. For example, one team focussed on improving BI data for our client facing project teams. One was finishing and delivering v1 of a new product.  Another was delivering the bidirectional interfaces with other health systems. 

One thing we are keen on is not to split the team into tech stacks. You don’t want one team doing front and another doing backend, else you are going to create dependencies between teams and slow down actual useful product improvements. Make sure each team can deliver all parts of the changes for their end users. 

Splitting the team by upcoming themes had one other benefit – by its nature, the teams would be temporary. In the future, developers (+ POs + designers) may get to know a product area intimately and can own the long term roadmap for that product. However, when you are first splitting up your team it’s liberating for all involved to know that your decisions now are not permanent. Split the team, try it for a few months, learn what works well for you and what doesn’t.  Then when you make the next round of teams you will make a better split. As your team grows and you have more permanent teams the experience of people from this time is not lost – they will take it and form a core of your new teams. 

Give the teams an identity 

We knew that the teams needed to work independently to get the benefits we wanted. One thing that was key to this was to give each new team a strong identity.  It helps people make the mental jump away from the single team they have known so far. Each of our teams came up with their own name, mission statement, and OKRs for what they wanted to achieve. This helped them explain to the rest of the company who they are and what their purpose is. We get each team give an update to the company at end of sprint on how they got on, product demos and whether they met their sprint goal. 

Coordinating the teams 

The teams maintain their own roadmaps and backlogs, and track their own progress to plan. To coordinate this it is useful to have a one page summary for each team of who they are, what they are working on, and any problems they are facing. We also made traffic lights for a quick view of: mission, plan, progress to plan, team roles, team processes. This should be available where everyone can access it - could be PowerPoint, Excel or an online tool. What is certain is that your format will change over time so don’t overthink the tooling or layout. 

For running the status update meeting, get a representative from each team and keep it brief. The aim is not to go through all the information, you should do that in smaller groups. Instead you want to break down any cross team silos you have inadvertently created. Good topics include: changes to linked roadmap items, technical blockers, or adjusting resource levels between teams. Give each team 3-5 mins to highlight any changes since last time and raise any issues which are blocking them. Then spend the second half of the meeting to have more in depth discussion on any of the big issues. 

Try separate meetings and processes for each team 

With separate teams you will now have separate backlog grooming meetings. We also tried separate stand ups and retrospectives to see how that would work. The short answer is very well – allows them to be much more focused. The key learning is that if there are any issues that cover the wider team then you need to make sure they get noticed. We have a quick cross-team retro to raise any points like that. 

One benefit of separate teams is that they can start to create their own processes. Want to try Kanban instead of sprints? Have a recurring discussion about should stand up be based on people or tickets? Now you can let each team try their own way and teach others how it went. 

Avoid micro teams 

A typical team size for an agile team seems to be about 7 people (give or take). That allows them to be self-sufficient, big enough to get good output, small enough to be fast. The temptation when you don’t have a lot of people is to create micro teams of 2-3 so you can still work on all the different product strands. Resist that urge. 

We tried small teams and it creates several problems. If someone is on leave then you quickly get down to a single person which is not a team – it’s not fun and they’re less effective. You will create extra dependencies for specialist help from other teams which will stall progress. You still end up trying to manage lots of different product initiatives which hasn’t solved the focus problem that was the starting point. 

Instead, force yourself to prioritise. Have fewer, bigger teams and put more effort into getting those features across the line quickly so you can get on with the next one. 

Sharing resource between teams 

As a small company you may not have enough resource for every team to have all their own skills. Maybe you only have one designer. Or you have more teams than you do product owners/managers. While it’s not ideal, the only option is to share them between teams until you get to a bigger size. We’ve found there are two ways of doing this and which is best depends on the people and role. 

• You can have someone who is a full member of both teams. They are in all the meetings and have a dual personality. This is necessary when they play a key role in the team and have to be there for all parts. This is not ideal as they end up doubling up on meetings and reducing their effectiveness. Also gives a scheduling headache of making sure that no two meetings happen at the same time. We found we needed this where teams share a Product Owner. 
• You can have someone who has a ‘home’ team where they spend most of their time and then an ‘away’ team(s) where they loan out help and support. This can be easier on their time, depending on how much they give to other teams. The issue to watch out for here is the away team getting blocked or stuck whilst waiting for help. We found this worked well for Designers and any specialist skills. 

There is no easy answer for needing to share resource and it will probably be painful at times. One thing we were keen on though is that no one floats outside of the team structure. Everyone should have a home. 

Changing resourcing levels between teams 

From your status meetings you will notice that some teams will be doing better against their goals than others. This helps when you need to be flexible with team sizes and reallocating people. 

When teams talk to each other they can help out where they see problems. We often find one team offering to help out when another is under the gun with a tight deadline. This can be by taking a bug or some support tickets off that team to let them concentrate on what they need to do. 

Unconventional roles 

One new problem you may have created in separating teams are the ‘softer’ roles played by people. For example, if you have a person who is usually the one organising meetings and chasing people up if they are late. Who does this now that you have split teams? The situation will be unique to your set of people so think it through and find out any single points of failure. For a couple of our teams, we have made it explicit for them to decide who is the ‘team chaser’ and it is a named position. 

How has it worked out? 

Splitting the team has been hard work at times while you bed in new processes but it has enabled us to regain our pace. Releases are back up (17 last week) and pull requests are quicker. The people have really enjoyed the process and like having the ownership and focus on what they’re building. No one wants to go back to the single team structure. We’ve still got a lot to learn and experiment with as we grow - processes never stay still for long.