Step-by-step guide on how to merge teams

People form tribes. It's such an ingrained part of human nature that we do it quickly and without thinking. We end up thinking in terms of "us" and "them". Our tribe becomes part of our identity. You see this behaviour in every aspect of human society. You see it in development teams. So, how do we overcome this instinct when we need to merge two development teams?

In this post I want to look at how I overcame that challenge when merging two teams, each working on a different app, into a single, larger development team that would work on a single existing app.

The merging approach

People generally dislike change, so introducing it in a high-handed manner will likely result in unnecessary pushback. If you have time, a better approach is to gradually introduce change, allowing people to be involved in the process, providing feedback throughout the change and allowing for adjustments as your plan butts up against reality.

1. Build trust and to know people

Speak individually with each developer on the team.

An excellent topic for discussion is to ask each developer how things are going and where they think things can be improved. Be open here; don't ask for their opinion and then dismiss them. Instead, delve into each area. You don't need to agree with them, but you do need to hear them. This process builds rapport and should not be undervalued, as a good relationship with each developer is crucial for this merging process to be successful.

Change will be much harder if you are viewed as an outsider, so use these conversations to get to know everyone as a person and let them get to know you. Recognise that a power dynamic is at play, and you may need to work harder to encourage some people to open up to you.

2. Audit reality, not just perception

To have the most impact in the shortest period of time, ensure 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. Open the project and verify the feedback given against the actual code. Remember, not all feedback will be valid and taking the time to verify how much weight to give to someone's technical opinions will save you a lot of pain in the future.

To gain an understanding, ask yourself questions such as:

1. What is this process attempting to solve?
2. Why is it structured this way?
3. What are the positives and negatives of the current approach?

Only once you can provide good answers to the above questions should you consider proposing a change. When proposing change, ensure you genuinely believe in your ideas and are prepared to defend them. Some of the ideas you have are going to be rubbish (don't shake your head, it's true!). And that's okay. We can't be right all the time. What's important is that every change is grounded in well-thought-out reasoning. It is too easy to stray from the path of teamwork here and into a dictatorship.

Working through feedback and gaining an understanding of the current ways of working is time-consuming, but making poor choices could damage the team's goodwill towards the merger. Therefore, take the time to ensure your ideas and beliefs are on solid ground.

3. Scope change tightly

You may find many issues with the way the teams currently work; you need to decide which of those issues need to be addressed immediately and which can wait for later.

If an issue needs to be addressed immediately, you must develop a plan to do so. Your plan should answer the following questions:

1. What is the issue?
2. Why does it need to be changed?
3. How can it be changed?
4. What metrics will be used to assess change?

Set a high bar for process changes - not everything needs to be perfect immediately. Once the teams are merged, you can come back and make process adjustments later.

4. Share and stick to the schedule

With a working understanding of the project (processes, code and bottlenecks), share the merging schedule with the teams and detail any adjustments that need to be made along the way. Be open to feedback and allow the schedule to be tweaked here or there based on that feedback.

By opening the schedule to group discussion, you allow that schedule to be scrutinised by the very people who have to live with it. It gives you the chance to explain why you feel any changes are necessary. Hopefully, a consensus can be reached regarding the changes required. However, if it can't be reached, you can either postpone the changes or push those through against the opposition. Which path to take depends entirely on how important you feel the change is. If you push through without sufficient buy-in, you risk alienating those very team members who will ultimately determine whether this merger is a success or not. This alienation rarely manifests in the form of shouting and throwing things, but is often in its more insidious form of quiet noncompliance. Look out for quiet noncompliance by assessing how each team member is contributing and holding regular 1:1s to allow them to share their feedback privately. Ultimately, a merger doesn't happen in a bubble - your organisation still expects delivery. So, if you push through a change that causes a mutiny and affects output, be prepared to be ousted from the tribe yourself.

5. Introduce change gradually

Change takes effort; change forces people to alter their patterns. By introducing change gradually, we can avoid overwhelming the team with newness. If you try to change too much too soon, things will start failing, not because the changes are wrong, but because the team only has so much capacity for change at any given moment. Once that capacity is filled, you need to back off from introducing further changes. By providing the team time to adjust to a change before introducing a new one, you can ensure that the change has the greatest chance of success. Gradual change builds credibility with each successful rollout, which in turn reduces the burden on you to convince people that your change is worthwhile. When introducing change, start with the least controversial changes, and the more controversial ones may become less so by the time you reach them.

6. Clarify roles and 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. Be direct in your communication - while it may feel uncomfortable to do so, any misunderstanding about expectations will lead to wasted effort and use up the team's goodwill when trying out new ideas.

7. Monitor metrics and adjust

With any change, you need a way of monitoring how successful that change has been. Whatever metrics you choose, you must closely monitor them throughout the change-process to determine if the change is on track or not. Things can either be:

1. Going well.
2. Not going well.

If your metrics are showing that things are going well, avoid the mistake of accelerating the process - stick to the schedule. Sticking to the schedule is important, as it should already have been communicated to the teams and agreed upon. With changes happening, people need something predictable to hold onto. Changing the schedule introduces unnecessary change, so avoid it.

If your metrics indicate that things are not going well, be prepared to make changes. Be brave and pause the merge. Return to the initial knowledge-gathering steps. Try to identify where expectation and reality started to diverge, focusing on what went wrong. Once you know what went wrong, be honest about it with the team (they already know!) and come up with a new schedule together that takes into account those unexpected challenges.

Expect to make small tweaks along the way without needing a full pause on the merger.

8. Consolidate the new team identity

Now that the merge is complete, you need to consolidate the merged teams into a single team. Deliberately mark the transition with a ritual such as retiring old labels or agreeing a new team charter. What is right for the team will depend on the individuals on that team and the flexibility of the wider organisation.

Listening to feedback is essential. You may feel that the merge went smoothly, but there is no guarantee that everyone feels the same way. Take the time to chat with everyone again and understand their thoughts on the merge and their feeling around it. Be guided by these conversations - no one is all-knowing, so don't pretend to have all the answers. Stay humble and seek out those awkward conversations before they can fester into something greater. Make adjustments based on that feedback where possible. However, if no adjustments are possible, merely allowing someone the chance to speak about an issue can relieve the pressure surrounding that issue.

I've listed this as the final step, but in reality, it should be happening throughout the change-process.

Everyone ends up happy, right?

Not everyone will be happy. Some people will continue to stick with their original tribe. Where you see this happening, challenge those individuals in a respectful, reasonable manner. Understand that even the most logical person is still driven from a place of emotion, and there is no greater place of emotion than identity. Make those individuals feel welcome in the new team's identity while being firm that the old identity is dead. Care must be taken here, as although their new identity should supersede their old identity, that superseding must not remove their previous achievements; i.e., honour the dead while moving on.

Underpinning all of this is the need for constant, open communication about what will change and when. Your job is to show the path and support those who are hesitant through coaching, 1:1s, and demonstrating successful changes. After clear expectations and fair opportunities to opt in, some may decide that they don't want to change and will either leave or need to be removed. People leaving the team is a very real risk; handle any team members who wish to leave fairly and with dignity, or risk compromising team harmony.

Merging teams is not an easy process; in fact, it might be the most challenging task in management, so you can't go into it blindly. Take the time needed to set yourself and your team up for future success.