Since I was a kid I've been interested in combining diverse elements to create something new and unique. I remember spending a lot of time mixing different types of colored clay to see the final tone or blending different oil paints to see a completely new one emerge from this primordial broth.
The fascination with merging elements to create something new followed me during my music studies. If you think about it, the quintessence of music is and always will be the combination of ingredients to tell a story. Different notes, rhythms, instruments, and sounds merge to paint a new love song, ignite a fast jingle, or lay down a solemn anthem.
Last year I got completely lost in the world of fragrances just to realize that the fascination about this universe originates in the same place. Perfumes are just a bunch of different ingredients, blended together inside a bottle.
I immediately found myself smelling everything I encountered: flowers, foods, plants, or raw materials. Everything that had an odor sparked my curiosity and I started asking myself how those notes (this is the official name used in the perfume industry) could have been matched and mixed to create something new, unusual, and unexpected for my nose.
The ultimate idea of merging (or splitting) different elements to create something completely new is perfectly described by the Latin saying "Solve et Coagula" which could be roughly translated as "dissolve and join together".
During medieval times "Solve et Coagula" became sort of a motto among alchemists who used this expression to describe the essential alchemical process. “Solve” refers to the breaking down of elements and “Coagula” refers to their coming together or, being more philosophical, “Solve” refers to the dissolving and vanishing of hardened positions and negative states of body and mind. “Coagula” refers to the coagulation of dispersed elements into an integrated whole, representing the new synthesis.
After many years spent in a leadership position, I realized that sometimes the process of unifying different people in a team or splitting a group into subsystems can have incredibly beneficial effects on the growth of an organization; taking, of course, into account that people are not mere elements to mix but individuals with feelings, fears, goals, and ambitions. This is the reason why I would like to share all the challenges, the learning, and the mistakes I made while merging teams; while the process of splitting a team will be discussed in the second part of this series.
Why do teams merge?
The first thing we need to clearly understand is why we are merging two (or more) teams into one single entity.
Teams are social groups with their set of rules, habits, dynamics, and internal conflicts. Before starting a process that is, to some extent, disruptive we need to have a clear reason why this step is needed.
Let's try to describe the most common reasons why teams merge.
End of the software cycle
Usually, the development of a (software) system follows some sort of life cycle. At the beginning the requirements are collected and analyzed through user interviews. Once the requirements are clear, a technical solution is proposed and its feasibility is discussed involving the tech team(s) responsible for the implementation. The implementation follows an iterative approach and small deliverables are continuously released and tested, with the final users being able to adjust the direction as soon as possible if a misunderstanding or a wrong assumption is spotted.
Once the final version of a software artifact is delivered in production, the main task of the team responsible for it consists of monitoring the behavior of the product and being sure that things keep running smoothly 24/7; this phase is commonly called the "maintenance phase".
During maintenance, a development team focuses on observability, bug fixing, small refactoring, and tiny evolution. This task, even if extremely important from a business point of view, it's definitely not the most exciting part of a software developer's job.
Other than that, we need to consider that the amount of people required to build a new feature - often committing to a tight deadline - is usually higher than the amount of people needed to maintain that system.
To keep the team motivated and optimize the talent allocation, a team merge might be a good idea and the developers who are maintaining the feature could join another group to enlarge the new team skill-set, increase its bus factor, and share the maintenance responsibility.
Collaboration improvement
Sometimes multiple teams evolve in a way that puts them in a position where they work together on the same macro functionality. When this happens, the teams find themself collaborating a lot, stepping on each other toes, and sometimes, blocking each other. When this happens, it might make sense to merge those two entities to increase and smooth the collaboration and alignment processes having those folks in the same team.
This approach is not always possible to implement and many factors (e.g. final team size, tech stacks) have to be considered but it's a solution worth considering.
Better talent optimization
In my career I've seen many companies have a clear and fixed footprint for team building; organizations that follow scrum by the book, for example, mandate a dedicated scrum master and product owner for each team. Other companies require every team to have a dedicated person responsible for QA or design.
When the team topology is too fragmented we end up having a large number of very small teams, each of those requiring a dedicated key role.
The byproduct of this setup is a bad optimization of talents across the company with people who struggle finding daily work to do and often losing motivation.
This symptom could indicate that some teams might benefit from a merge and a higher focus on talent allocation.
Hiring and cost optimization
Many companies require each tech team to be led by one person, usually identified as Engineering Manager, but also called "Tech Lead" or "Team Lead". This person often has people leadership responsibility and is accountable for the team delivery other than providing a communication interface between the team and its stakeholders.
Having too many small teams, each of those with a dedicated Engineering Manager, could be extremely inefficient in terms of headcount and salary allocation; not to mention that, a leadership structure too horizontally spread makes the alignment cumbersome and the decision-making process slower.
If your tech organization ends up having a lot of folks hired and paid like a manager but doing mostly individual contributor work due to the small team size, this could be a symptom that some smaller teams might merge into a larger group.
How to merge teams
Once the reason behind the merge is clear, it's important to monitor the merge process in order to be sure that it happens smoothly and without major hiccups. The first weeks of a merge are the most critical and the final outcome might be heavily impacted by the mistakes made in this preliminary phase.
In the next section we will discuss the common issues that emerge when two teams are merged and how can we deal with it in a constructive way.
Focus on transparency
Being honest and radically candid with people is always extremely important but it becomes critical when trying to blend two different social structures who base their existence on different written and unwritten rules.
When delivering the news of a merge we need to be sure that clear information are shared and people have the time think, reflect, eventually vent and, last but not least, ask follow up questions.
In case facilitators (e.g. Agile Coaches) are available in the company, it makes sense to involve them and get support during the whole process. A facilitator can help understand the fears and feelings that are often not share when a manager is in the room and can be leveraged to better share the vision and be sure that the whole process is as transparent as possible.
Consider redundancy
As a manager we are expected to clearly communicate expectations and vision but, at the same time, we need to practice empathy an understand how people can react when they hear the news of a team merge.
Let's focus for one minute on the roles that are unique inside a team, like an Engineering Manager could be. In this case the news of a merge would inevitably mean that one of the two managers will need to find a different team to lead or, in the worst case scenario, a different company to work for; it is indeed not unusual for a company to have a layoff round after a restructuring.
Merging two groups means that some roles will become redundant and nobody likes to be labeled as redundant, no matter what the ultimate goal is; this communication must be handled tactfully and with respect.
Understand social interactions
In my twenties I used to study music and play in various bands. One of the most important features of great bands was the ability of those folks to play together; and when I say "play together" I'm not talking about turning a music sheet into an alternation of sounds and silences but rather about being able to interact with each other and create the chemistry needed to perform great.
This ability is commonly called "interplay" and it's the main reason why some bands work great and some other don't. Interplay is not about technicality or music knowledge but rather about a sense on ensemble and a sense of holistic view of the band playing music together.
When it comes to merging teams it is extremely important to consider the chemistry between the personalities that will form the final ensemble and avoid evaluate people only based on their skills or resume.
At the end of the day those people will need to be able to work together, discuss, challenge each other and commit on topics they might not necessarily agree on.
I personally found the Moving Motivators game particularly useful to understand what is important for different folks. Another tool I've been using is the Personality Style Cards that is focused on understanding what is important for a person and what are their core values.
Those tools are, of course, not meant to replace the process of knowing people through 1:1s and career dialogues but are a nice tool to get a grasp of what a diverse group of people value using a playful and social approach.
Embrace change
It's quite important to be sure that everybody in the merged team will be willing on working on the topics that belong to the new ensemble; a developer who joined a mobility company to work on challenging mapping optimizations and algorithms will definitely lose motivation if they end up in a team focused on building, for example, an APIs aggregation layer.
This is one of the most difficult challenges during a team merge because it's almost impossible to make everybody happy when it comes to something so much related to personal preference. Other than that, motivation is highly influenced by external factors and it's not something that can be switched on and off pressing a button.
When I had to deal with someone who is not motivated by the goals of the new formed team, I ask them to wait a couple of months to effectively see if the new team is really not a good fit for them or if the initial reaction was solely based on the anxiety, the stress and the pessimism that comes with putting together two different groups. Once the merged team reached the Norming phase I usually have a second check-in with the people who were not convinced, trying to understand what are the feelings and how can things be further improved.
In case things haven't improve and the person(s) still doesn't feel like working with this new constellation I try to negotiate a team move to see if this person could join a different team that could be a better fit for them.
A couple of times in my career I've seen people using the team merge to make a lateral move and trying a new role inside of the same company; this is another great development option that we, as managers, often tend to ignore.
It's worth underlying the fact that the previous options are not always available and, sometimes, people decide to join a different company to find a set-up that better fulfill their aspirations, desires and needs. As managers we should always accept this move as part of the natural growth of an individual, avoiding resentment and keeping in mind that a company, as great and beautiful as it might be, remains and will always be an organization that is paying employees a salary in exchange for a chunk of their time and their skills; situations changes, companies changes, people changes and that's nothing wrong with that; let's just embrace a bit of Amor Fati.
The after merge
The weeks after the merge happens are the most critical for the newly formed team and the resulting setup should be carefully monitored touching base frequently and, eventually increasing the frequency of the 1:1 meetings. In this phase, involving external observers like Agile Coaches or facilitators, might be a good idea.
In case you are a more senior manager, this could even be a good moment to touch base personally having skip level meetings with folks who are reporting to your direct reporting managers (this topic has been deeply covered in this article from Lena Reinhard).
Rebirth and restart
A physiological decrease in productivity is absolutely normal after a team merge; developers have to get acquainted to the new code base, product owners have to spend time getting familiar with the new product scope and have a good backlog grooming, quality engineers have to understand the new features to test and adapt the plan.
As managers, we should observe this phase with realistic expectations, showing empathy and not expecting people to hit the ground running. The stabilization phase should last, depending on the team, from a couple of weeks to a couple of months and in this phase we should notice a slow but steady increase of the team output.
I said it before, I'm gonna say it again, humans are not machines and some support in terms of team building activity will absolutely pay dividends down the road. A previous manager of me used to say "The team is built in the pub, not in the office" and, even if the pub might not be the best place for a diverse audience like a team, I absolutely see some truth in this sentence. Spending some time (and money) organizing out-of-the office team activities will go a long way in creating the social glue that is very much needed when people who never worked together have to share so much time reaching the same goals.
Volunteering, solving an escape room, taking a cooking class are definitely great examples of activities that can break the ice and contribute to build interaction between humans.
Conclusion
Merging teams is a complicated process that requires the right amount of care and attention during all the phases of the process.
As managers, we need to focus on the expected outcome without minimizing the social aspects that are normally involved when dealing with humans.
Especially in cases like this, empathy, transparency and active listening are paramount.
To be continued...