Post-merger integrations can be difficult to get right. Avoid any animosity and make the process as streamlined as possible.
My first encounter with mergers and acquisitions (M&A) happened a little later in my career. However, when I eventually became the lead of a team integration project, the experience ended up defining my professional journey.
Setting the stage
Before embarking on this endeavor, I consulted upper management, insisting on transparent communication about my role in the process and the reasons for the integration. Understanding leadership’s rationale and all the details of my duties minimized the probability that the merging teams would question my presence, role, or intentions. After this step, the CTO formally announced the upcoming change.
Strategic leadership in M&A integration
My M&A responsibilities were divided into two distinct paths: strategic interactions with the new organization’s management and direct, hands-on engagement with the integrating teams themselves. This dual role required a dynamic approach, blending high-level strategic oversight with grassroots direct engagement with the team.
High-level strategic interactions vs. team engagement
Engaging with the upper management of the integrated company involved aligning multiple strategic and sometimes conflicting priorities. These interactions were essential for ensuring that both entities moved towards a common vision post-merger. Throughout this process, my role often involved challenging existing methods, contending with pushback from the merging company’s management, and advocating for changes, such as an increased delivery pace. Navigating this required an understanding of day-to-day activities so that I could gain as much contextual information and hard data as possible to support my initiatives.
My direct involvement with the teams demanded a more personal and immediate approach, so I dedicated myself to daily interactions with team members. This routine was not a micromanagement exercise but rather a strategic choice to immerse myself in the operational realities of the teams. What do they believe we need to change? How do they feel about their day-to-day life? By doing so, I could form firsthand observations and develop insights to identify key or go-to individuals on the team.
By straddling strategic and operational aspects I acted as a bridge between the overarching goals of the integration, which included improving the performance and stability of services alongside seamless integration, and ground-level realities. Along the way, I forged a genuine connection with the team, empathizing with their daily challenges.
Observe your team before making adjustments
The team structures and roles varied significantly between the two companies, so my initial goal was to identify quick wins and necessary adjustments to align them to a unified framework.
During the initial weeks, my role was predominantly observational. I participated in various team activities, attended stand-ups, and absorbed as much information as I could. This period of active listening allowed me to pinpoint immediate improvements based on their work processes and organizational habits.
I also conducted individual meetings with each team member to review their current status and identify areas for improvement. What is their current role? What does a usual day look like? Do I have merging team members who are looking to leave for another company?
Changes in the way of working
1. Transforming standup meetings
One of the first initiatives I implemented was transforming our daily standup meetings. Previously, these standups were lengthy, often extending up to 30 minutes, and frequently derailed by tangential discussions. To enhance efficiency and focus, I restructured these meetings into concise 10-minute sessions to concentrate on fostering team collaboration and addressing immediate operational issues. This shift not only saved time but also significantly improved the productivity and focus of the team.
2. Optimizing feature development meetings
In addition to refining our daily standups, I addressed the need for better structure in our feature development discussions. Originally, meetings about feature implementations were ad-hoc, which sometimes led to confusion and inefficiencies like key members failing to attend and confusion about priorities, etc. To counter this, I instituted weekly, scheduled backlog refinement sessions, each with a specific, pre-defined agenda. This adjustment ensured that all team members were prepared and informed about the topics of discussion, leading to more productive and focused meetings.
3. Introducing retrospective meetings
A critical addition to our process was the introduction of retrospective meetings at the end of each cycle. These retrospectives allowed the team to reflect on what went well and what could be improved from the previous cycle. The result was an expanding list of action items that the team wanted to start doing, clearly showing that team members viewed this change as a significant opportunity.
4. Introducing chapter meetings
To foster continuous improvement and adaptability within our tech stack and processes, I included relevant colleagues (based on their craft) in the established chapter meetings. These sessions promoted knowledge sharing and alignment among distributed teams while also offering a platform for ongoing evaluation and refinement of our technological practices. The new approach ensured seamless integration of new teams, reinforcing our commitment to high standards and continuous improvement in our technological operations.
Strategic team restructuring
Initial changes
As expected, the merging team had a different structure for roles and responsibilities, presenting a need to adjust frameworks. We aimed to align the company’s practices for consistency and efficiency while carefully considering changes to maintain workflow integrity and support team performance.
First, I set off to address the fact that the new teams had previously operated without an engineering manager, a gap that posed potential challenges to scaling efficiently and coordinating projects effectively. I took steps to fill that role in a way that would complement the existing team dynamics identifying a suitable candidate from within the team to take on this role.
Second, I tackled a reliance on manual quality assurance (QA) processes, which tended to be time-intensive and less effective at swiftly detecting regressions. To improve, I partnered with the QA Chapter – a group within our organization dedicated to advancing best practices and innovation. Their expertise was invaluable in guiding this transformation and training team members for their new roles as software engineers in test (SET).
Despite our best efforts, some team members needed help to adapt to the automation-focused demands. After providing thorough support and evaluation with the help of our principal and staff engineer, we made the tough decision to realign the team by transitioning them into roles that better fit our evolving operational needs and strategic goals.
Longer-term structural shifts
After I’d been in the M&A role for a while, I began to look to further enhance the team’s efficiency. I proposed a reorganization into three specialized sub-teams, each concentrating on distinct tasks. This restructuring invited team members to explore new roles and responsibilities, which required an adjustment period but ultimately benefited collective productivity and growth.
1. Implementing and communicating changes
After I had gained the CTO’s approval, the next critical step was effectively communicating the restructure. We adopted a 6-week work cycle framework, similar to a scrum sprint, which provided an ideal opportunity to introduce our new team structure. During the first cycle’s review session, we outlined the sub-teams, setting clear expectations and offering a structured framework for the transition.
2. Managing feedback and ensuring alignment
The restructuring led to several requests for 1:1 meetings as team members expressed their concerns and sought clarification on their new roles. These interactions were crucial for addressing uncertainties and reinforcing the benefits of the new structure. Some members were skeptical about these changes, they didn’t know what to expect and one of the most important things was the roles & responsibilities.
Addressing knowledge gaps
Ownership challenges across different operational areas were another hurdle of the post-merger integration. A notable dependence on certain individuals for critical tasks highlighted a potential risk to the team’s resilience and efficiency.
Fig.1. Knowledge gap matrix
To begin addressing this issue, I introduced the knowledge gap matrix – a structured tool designed to visually map out expertise across the team. The matrix took the form of a table that paired all microservices with team members, rating each person’s familiarity and expertise on a scale from 1 to 5. This helped us assess gaps in collective knowledge. We found that certain crucial services were often only known by a few team members and that there were system areas where no one had expertise.
This dependency on specific individuals, often described as the “bus factor,” represented a considerable risk should any of those key individuals be unavailable. With these critical knowledge areas pinpointed, the next step was to prioritize addressing these ‘bus factor’ risks.
Knowledge sharing sessions
We organized internal events (online) where knowledgeable individuals presented their areas of expertise. These sessions were designed not only to transfer knowledge but also to foster a collaborative learning environment.
Documentation and Q&As
A dedicated Confluence space was created for each critical area (component/flow). This platform served as a repository for detailed documentation and became a forum for ongoing questions and answers, ensuring that the knowledge was accessible and comprehensible to all team members.
A Technical Due Diligence Approach
Mapping the execution part
To help integrate new distributed teams into our existing technological framework, I devised a detailed agenda that scrutinized both the tools and processes utilized across various teams from ticketing systems to the ways of working.
Code review process
As a strong advocate of thorough code reviews, I aimed to establish a robust and effective process. I closely examined our code review practices and identified recurring issues: inconsistent styling, unclear variable names, and code being delivered without approval.
As a result, I organized workshops on effective code review practices, following a pyramid approach (Fig.2.) that started with code styles (a Linter tool is helpful here to catch inconsistencies), followed by tests, documentation, implementation semantics, and finally, API semantics. However, changing mindsets and established routines often requires more than workshops. To enforce this best practice, I established a rule in our CI/CD pipeline: each code snippet, is delivered only after getting one approval by the module expert, or two approvals in case the components are critical
Fig.2. Code review pyramid
Security and code analysis
During an M&A integration, it was also important for me to strengthen the security of the apps I was taking responsibility for. To ensure that the newly integrated teams were aligned with our security protocols we focused on the basic security processes. The first step was to set up a mechanism to automatically notify the team when security vulnerabilities arose, so we could take the appropriate actions.
The next big bet was to understand the actual tech-debt of the applications so we decided to leverage the use of code analysis tools. These tools (SonarQube) helped us eliminate code smells, reducing code (cyclomatic) complexity but of course addressing security hotspots and improving the code quality in general.
Testcase repository and test historicity
Another aspect that was lacking was a central repository for past testing scenarios. In order to rectify this the teams embraced the adoption of a tool where all the test cases are summarized along their execution status (pass/fail) in one place. This approach not only provided a historical record of testing outcomes but also allowed for precise tracking of pass and fail rates, as well as associated bugs.
This tool also offered valuable insights to each manager about the quality of the released software, pinpointing actions that need special attention. One of these insights was the pre/post-release bug ratio, which acted as a benchmark of the software quality in addition to testing efficiency. Bugs identified post-release indicated a perceived lower customer value/satisfaction and also denoted that the testing processes were not efficient enough.
Results and reflections
As the teams embarked on their paths, the new, proposed approach began showing promising results. The subsequent work cycles highlighted significant improvements in team performance and collaboration.
Above all, I learned that leading an M&A integration is a multifaceted challenge that requires balancing strategic vision with empathetic leadership. This journey has been a profound learning experience, highlighting the dynamics of change management and the power of structured adaptation in the face of uncertainty. As we continue to refine our approach and learn from each cycle, the initial challenges of this integration have paved the way for a more cohesive and efficient operation.
