Merging teams

Recently I was put in the position of having to handle the merging of two iOS teams working on two different apps into the one larger development team working on one app. I was given this position as I was the Team Lead of one of the teams and the Head of iOS for both of them. This post is about that merging process and what was learned from it.

Setting the scene

Each team was structured the same way with one team lead and 3 developers (4 in total with the team lead also acting as a developer). Both teams shared a similar codebase either through using Core Projects or shared experience of working on both apps. The two teams had also held several Share Meetings where they got to discuss anything that anyone found interesting about development. They also attended several General Development Meetings where we discussed a common iOS development approach. The one app that both teams where going to be merged into was not a new app but an existing app that one of the teams had been developing for a few months. When the choice was made to merge the two teams, that app was a few weeks away from its deadline. To summarise the two teams had a somewhat similar development approach, the same team structure and some shared knowledge/code.

The merging approach

To start with, we took our time to understand why the project was behind schedule and how it was structured. This involved speaking to each developer on that project independently.

And leads us to our first merging rule:

1. Understand how people think things are

By speaking individually to each developer in the team, it allows those developers the chance to describe how things are going and where things can be improved. It also opens the door to them airing any frustrations that they may have and gives you the opportunity to respond. This should not be undervalued as you need a good relationship with each developer for this merging process to work.

Ok, so having gained an understanding, in theory, for how things were going, I needed to understand how things were in practice. So I spent some time looking at the code of the project and attempted to analyse in code how the team was structured and how that matched up with what I had been told.

This leads us on our second merging rule:

2. Understand how things are

In order to make the most impact in the shortest period of time, you need to make sure that you correctly understand the current state of affairs. People tend to sugarcoat issues that they feel personally responsible for and focus on what they perceive to be the failures of others, especially if those failures are holding them back. As developers, we have an excellent counterweight to this in that we can open up a project and understand exactly how things are without having to only depend solely on personal opinions.

Ok, so armed with the knowledge of how everyone felt things were going and how the project was structured in code, it was time to work out how the two teams could be merged. From the information, I had gained from the first two rules I could see that the teams had moved apart in the development approach. Ideally, we would have continued to keep the two team separate and worked to move the two teams to have the same development processes. However, due to the approaching deadline, this wasn't an option so I had to figure out how to integrate to the teams in the smoothest way into the existing development process and work on the introducing a new development process later. I straight down with some of my colleagues and draw some possible approaches on the whiteboards. The big bang approach of merging was quickly ruled out as it was felt that adding so many new developers to the project would cause it to grind to a halt. It was decided that the best approach here was to introduce the new developers over the course of 4 weeks.

This leads us to our third merging rule:

3. Introduce change gradually

By introducing change gradually you ease the pressure on the existing team of having to educate the new developers. You also ease the social awkwardness of that new developer in having to ask for help with a group of people that they have not worked with. The existing developers have to answer fewer questions and can do what they feel is real work i.e. introducing and extending features and the new developer doesn't feel that they are yet another interruption into someone else's day.

Ok, so I now had a schedule for changing the team, it was time to have a discussion with the other team lead, understand if that schedule would be acceptable for them and discuss how roles would be divided up.

This leads us to our fourth merging rule:

4. Clearly share responsibilities

By clearly understanding and sharing what is expected of each developer on the team you can avoid any awkward situations that would damage the merging process.

Ok, so with an agreed-upon schedule I proceeded to execute the plan.

This leads us to our fifth merging rule:

5. Execute the plan

As the teams begin to merge and you start to see productivity gains it's easy to get carried away and attempt to speed up the process. You need to fight this and ** stick to the schedule**. Sticking to the schedule is important as the schedule should have been communicated to both teams, with so many things changing around them people need something that is predictable to hold onto. Bear in mind that very few people genuinely like change and some will even actively fight against it just for the sake of it, so to change the time schedule is often enough for any underlying tensions to rise to the surface. How you handle the tensions that do surface can eat up valuable time and energy, you don't need to create any more issues for yourself or your team.

Ok, so now you have an expanded team and have smoothed out some of the initial issues that came up - it's time to understand how people they felt about all the change.

This leads us to our sixth merging rule:

6. Understand how the team felt about the merge

This is essential, you may feel that the merge went smoothly but there is no way that everyone feels that way so take the time to chat to everyone again and understand how they feel. As before it could be that merely speaking about an issue will allow that person to feel better about it but if it's not, it's important that you understand the concern and address it either through detailing why it has to be that way or changing something.

Ok, so the teams are merged and I've taken the time to get to analyse how things are in the larger team dynamic. Now I had to come back to something I raised at the start of this merging process: changing the development process. I had spent the past year or so building and tweaking a development process with the old team. I was keen to switch the expanded team over using a form of this older process however if the past year had taught me anything it's that I don't have all (or even that many) the answers so I really wanted to open the doors for tweaking our processes.

This leads us to our seventh merging rule:

7. Build a consensus for further change

It's important to not force change on a team especially if you perceived as the outsider. You need to first of all truly understand how a process works from the inside. Ask yourself questions such:

1. What is this process attempting to solve?
2. Why is it structured this way?
3. What are the Pros and Cons?

Only once you can give good answers to the above questions should you even consider proposing change. When you do propose change you need to make sure that you genuinely believe in your ideas and that are prepared to defend them. Some of the ideas that you have are going to be rubbish (don't shake your head, it's true!) and that's ok, we can't be right all the time. What's important is that every process change has been properly discussed with the team, and their views have been taken into account. It is too easy to stray from the path of teamwork here and into a dictatorship. By opening an idea to group discussion, you allow that idea to be scrutinised by the very people who have to live with it. It gives you the chance to explain why you feel something is an issue and how you propose to overcome it which allows you to start building bridges with your new team. Hopefully, a consensus can be reached here for the changes that need to be implemented however if it can't be reached you can either: postpone the changes or push them through. Which path to take depends entirely on how important you feel the change is. With any new process, you have a grace period where people are accepting of any issues that come from that process change, that grace period is longer if everyone is on board with the process change. One final point to add here is that after having used that process for some time you need to go back to it with the team and re-evaluate it.

So to recap, I've found that you need to go through the following steps to successfully merge two teams:

1. Understand how people think things are
2. Understand how things are
3. Introduce change gradually
4. Know your responsibilities
5. Execute the plan
6. Understand how the team felt about the merge
7. Build a consensus for further change

Underpinning all of this is the need for constant, open and truthful communication with the teams involved about what is going to change and when that change will come.

What do you think? Let me know by getting in touch on Twitter - @wibosco