When any company acquires another business, merging the two entities’ technologies is a project unto itself. Having worked both in (as an employee) and with (representing a services company) organizations in which a merger occurred, I recognize that every merger has its distinct goals and challenges. However, there are some commonalities that can help any tech merger be more successful.
I’ve broken down the key steps in the tech merger process, including my recommendations for best practices:
Step 1: Define what “merging” means to your business
Before you start digging into code or migrating platforms, identify any business requirements and concerns that will need to guide the merge process. For example, what was the business impetus for acquiring this company? Are there any legal restrictions around data sharing between the two companies? Are there marketing benefits to maintaining two distinct brands? Defining the business needs up front will ensure that the tech merger will be aligned with the business value, rather than simply making two products work together on a technical level.
Step 2: Establish a dedicated team to own the merger project
One of the risks of merging tech is when the work is pushed onto existing product development teams that are responsible for continuing to evolve current products. Like many other projects that split efforts between siloed groups, the risk of duplicated effort is extremely high in this type of approach and leads to increased context switching which will result in overall decreased productivity for the team.
Don’t let a merger put your entire business on pause. Where I’ve been involved in acquisitions, the most successful tech mergers are defined and executed by a dedicated team that pulls its members from key groups within the organization, allowing existing teams to continue evolving and releasing innovative products while the migration is underway.
This dedicated cross-functional team is then responsible for working with the current product team’s by treating them more as customers of the work to ensure alignment on the approach and execution of the merge.
A dedicated merger team should be responsible for creating a framework by which to evaluate both companies’ tech. The team will need to define the products, infrastructure, and configurations that exist in each organization, and identify where there might be overlap, duplication, or a potential gap. At that point, each component should be evaluated based on relative comparison, not absolute.
Do not overcomplicate the framework. To start, rather than try to gather specific metrics on performance and measure each function using time-consuming evaluation processes, use concepts such as “strong versus weak (or neutral),” “better or worse,” and so on. Much like duplicating workstreams, spending time overanalyzing is a waste of resources. Let the evaluation complexity emerge to help inform comparison decisions that are not obvious. For example, when both your options for an area feel like the same relative weighting i.e. both choice A and choice B are ‘strong’. In this case, lean into more defining, capturing an evaluating specific metrics to inform your decision.
Other things to keep in mind during the evaluation process:
- Even in cases where one company’s tech is better, there might be a different solution that could be leveraged to achieve the same functionality that would result in a net lower investment over time. For example, could custom login code be replaced with a third-party single sign-on solution? Consider options outside of an either/or choice.
- If there are services that either or both companies have created that are unique to the business, are the services in place to accommodate critical edge cases? If so, what is the level of work required to migrate those services?
Tip: Defining a framework and evaluating tech is best accomplished if the merger team is composed of representatives from every department with an executive title—for example, if there is a VP of DevOps, a DevOps manager should be involved. In other words, tie the framework to the people and technology involved. Note that, in some cases, you might find that using this approach results in key stakeholders missing from the merger team. This could be a sign that the organizational structure needs revising. This secondary benefit—verifying organizational alignment—is one of the reasons I prefer this approach of forming a merger team.
Step 3: Merge
Once the clear winners have been determined, part of the merger team’s work is to define what a “completed” merger or cutover means and to develop a timeline based on that end goal. Keep in mind that these projects always take longer than estimated—so set expectations accordingly.
Once the plan for merging or migrating has been developed, it is time to begin the work. For each area, the team on the ground that owns that functionality should be required to sign off on it, but the actual merge work should be executed by the merger team.
The team that owns the functionality will have to maintain it once the merger is over, so keeping them in the loop as the merge moves forward is critical for both optimizing functionality and avoiding duplicate work. The merger team should validate what it has heard with the team tech leads—those folks who make day-to-day tech decisions about the functionality and are hands-on.
Ongoing, regular updates, sprint demos/weekly reviews, and having cross-team pull requests approvals are all examples of ways to maintain strong communication between the merger team and the existing product teams. Don’t wait until the merge is complete to gain buy-in from the product teams—you might find that all your work is wasted if you’ve missed something important.
Team alignment matters
While every organization is different, any successful tech merger really boils down to two key elements: constant, meaningful communication and strong collaboration. Sometimes, an acquiring organization might be under the impression that it should be the one to make all the decisions on what and how to merge, but it is important to remember that there is a reason the purchased company was acquired. Involving both sides and aligning early on around clearly defined business goals, with a dedicated merger team, makes a big difference.
Rob O'Brien
