The hidden cost of incomplete integration
Companies acquire competitors to strengthen their market position, expand capabilities or enter new markets. Once the contracts are signed, however, many integrations lose momentum. People continue working with the same colleagues, knowledge stays where it always was and duplicate capabilities continue to exist.
The result is a larger organisation that behaves like several smaller companies instead of a single, integrated business. It raises the question: what drives synergy after acquisition?
Prefer to download this Insight instead?
Acquiring companies to secure market share
Our client had acquired several competitors to strengthen its market position. It made sense from a strategic perspective: it would consolidate the market, stabilize competition and increase chances of winning public tenders. The business had a strong hardware division already, but was looking to complement its software capabilities with those of acquired competitors. This would enable a platform offering without having to develop every software capability in-house.
The organisation became a company group after a wave of acquisitions. The playing field could be described as follows:
- Previous company owners became Board Members
The owners of acquired competitors had valuable business expertise stretching several decades each. Most of them had built their company from scratch. They were offered to continue their involvement in the group in the role of Board Member.
- Business units kept "their" people
The company owners had personally handled staffing over the years. None of them were inclined to let go of “their” people.
- Offices are geographically separated
Each of the acquired companies had their own office. Some had a dedicated IT department, others relied on external suppliers. The offices of the newly-minted company group were scattered throughout the country. Their DevOps teams were scattered as well.
- Protection of Intellectual Property (IP)
Companies generally do not share IP with competitors if they look to stay ahead. The company-owners-turned-Board-members were conditioned in such a way over the many years, that they choose to stick with that behaviour. The result was that the group’s DevOps teams were given explicit instruction not to communicate with one another.
The legal integration had succeeded. The operational integration had barely started. The group looked to compete in tenders by offering a one-stop-shop solution platform for a competitive price. Instead, it was unable to deliver what was promised for the price it was tendered for. We were called in to find out why this happened, how this happened and what was needed to come out on top.
Our Discovery found familiar integration challenges
Key players within the group continued to operate unchanged. During our Discovery we found familiar integration challenges:
- Project Managers asking the same functionality from different DevOps teams
Project Managers worked on delivering multiple tenders simultaneously. We observed Project Managers requesting similar functionality from different DevOps teams. Not always because it was needed, but because Project Managers were looking for the DevOps team that was able to deliver the fastest. The other DevOps teams had simply wasted their effort.
- Hardware unaligned with software for the same client
The two hardware departments communicated with one another, but not with the DevOps teams. Hardware was mainly focused on delivering state-of-the-art hardware solutions. More frequently than not, the firmware did not align with the hardware for the same client. Interestingly, nobody was responsible in such cases.
- Customers negotiating custom solutions at no extra cost
Customers negotiated custom solutions at no extra cost in exchange for goodwill. Sales argued that the ongoing development and maintenance was calculated into the quoted price or the tender. In reality, many such custom solutions had become legacy and resulted in unprofitable solutions being maintained indefinitely.
The expertise the organisation had acquired stayed exactly where it had always been. Knowledge did not flow across the new organisation. Organisational learning had effectively come to a halt.
Analyse what is needed
The Board of Directors had a clear vision for the new organisation. It was clear what they were looking to achieve. The acquisition wave acted as a driver to that ambition. It just fizzled out once the legal aspects passed. We visited three key sites to gain a better understanding of the organisation as a whole. With the people working on-site we:
- Asked questions, read documents and attended product demos.
- Gained insight in how the operated their business, tech and operations.
- Compared findings with those from other key sites.
Now we had the input needed to make our Discovery findings actionable:
Deliver to get things moving again
We needed a flywheel to make this integration a success. The common denominator in our observations were the DevOps teams. The DevOps teams were not allowed to exchange knowledge directly. We were not bound by that restriction as external consultants. We became the conduit through which knowledge could move across the organisation without disrupting governance.
In case of success: repeat! We visited the key sites again. This time to validate our earlier findings. These validated findings we verified at the next key site. We went from site to site to structure information that could be shared with all sites. It drove the organisation to a shared understanding of available capabilities, business requirements, hardware limitations and regulatory requirements.
Synergy effects realised
The new organisation gained the following business value:
- Established a common language across Devops teams to foster collaboration.
- Reduced software development cost as duplicate capabilities were eliminated.
- Increased reuse of shared capabilities by business stakeholders.
- Enabled the organisation to secure a multi-million euro tender.
Lessons learned on acquisitions
From this case study we had learned the following on business acquisitions:
- Legal aspects are only the beginning
Provide leadership to merge business, technology and operations to reach the finish.
- Sharing technology leads to shared understanding
Restricting DevOps teams from collaborating left business value underutilized. Business operates sub-optimally as a result.
- Translate first, analyse second
Providing a common language enables the organisation to do its own cross-business unit analyses themselves.
Is there value in Discovery for you?
The new organisation gained the drivers they needed to succeed post-acquisition. Organisations typically contact us when they recognise one or more of these signals:
- Similar work appears in different locations.
- Business units do not align with group strategy.
- Lack of change roadmap ownership stifles progress.