Integrating businesses is no small task. Established workflows, systems and tools are vigorously defended yet poorly understood. Fearing for their jobs, people will equate systemic knowledge with job security. Many in the acquired business will cling to their legacy identity. Organizational politics - and power plays - will alter tactical integration plans. But it is the business goals that investors signed up for - not the internal special interests - that will determine the fate of the leadership responsible for the integration. How do we stay focused on these?
Be a business leader, not a technology partner. Technology leadership must be fluent in the broader business context of the integration and be prepared to make decisions on behalf of the business, not just the technology applied to the business. This means being or bringing in business process analysts to simplify the operations - and with it, the technology - of the business itself.
I wrote last month that most material on the role of IT in M&A are platitudes, and this certainly smacks of one. But the fact is, this is not something that IT departments have in recent years positioned themselves to do. The change in moniker from "Information Systems" to "Information Technology" has been a detriment to CIOs: the word "systems" implied responsibilities inclusive of business and technology, whereas the word "technology" suggests it is solely responsible for tech. As a result, there is less expectation that tech will shape business decisions as much as it will carry them out. It doesn't help that business analysis skills remain low in captive IT.
M&A gifts captive IT with the opportunity to be the "resident adult" in sorting out intransigent participants in an integration. However, that opportunity exists only if it is prepared to act as a business leader and not merely a technology supplier.
Slowly strangle, don't wholesale replace. Existing systems are complex: they have highly specialized rules that were developed over a number of years, they were developed with very different architectural principles than would be applied today, and the older the underlying technology the scarcer the technological know-how there is to incrementally change them. This makes it easy to make the case that dueling systems are incompatible with one another, are no less valuable owing to the criticality of the specific edge cases they accommodate, and can only be replaced through a large "enterprise"-scale rewrite. Thus we have no choice but to maintain the status quo, and only costly and high-risk change can possibly sweep it away.
The headwinds to change blow fiercely; there are always plenty of reasons not to do something.
Unless both organizations have extraordinarily geriatric technology, proposing an enterprise refit will be met with skepticism in the boardroom that will cast doubt on our leadership capability. Even a big-bang retrofit of one incumbant technology to take the place of another will receive only a grudging endorsement. Both scenarios also create tactical confusion: should existing systems be modified to meet immediate business needs or do we wait for the big-bang replacement? And what do we do if that big bang replacment gets delayed?
We avoid this trap by strangling existing software. In effect, we allow our portfolio of assets to continue to evolve with the business while simultaneously deprecating and retiring them. We do this gradually, identifying specific functionality that can be integrated and replaced. We have the practices and technologies today - from continuous integration to feature toggles to branch by abstraction - to make this a matter of will. It is also palatable to the board because it gives us a means to show how we are structurally reducing our cost of operations in a manner that will support the business in the short-term and sustain it in the long-term, not a slash-and-burn approach that makes it thinner at the cost of making it more sclerotic.
This will mean making some unpleasant decisions. We may have to create new code - a lot of new code - to integrate old code on our way to fully retiring it. We may have to integrate in unpalatable ways (e.g,. at the database level) where legacy systems do not support modern architectural principles. And there will be times when the extent of integration will makes our collection of assets very complicated. This means that our measure of success isn't just getting things deployed, but getting things removed. To the CIO, the critical measure is a composite "simplicity index" of all IT systems, not "integration progress" in simply making systems work together.
Insist on excellence in engineering. When the clock is ticking, there will be temptation and pressure to cut corners. We can create the appearance of integration with quick and dirty solutions, and all that matters in the end is that it works, not how it works.
The phrase "we'll fix it later" probably has the lowest conversion rate of any statement made in business. An implcit expectation in M&A is that we are investing in simplicity and robustness, not complexity and brittleness. The reality is, we're not going to get money later to pay down technical or operational debt we take on. If the combined landscape has more moving parts and fragmented institutional knowledge than the sum of the parts of the combining companies, we'll have a higher cost of operations and, therefore, have failed.
Investigate, measure, and draw attention to quality of engineering. Instrument all code, looking specifically for complexity, duplication, testability, and test coverage. Incentivise good engineering practices and reward teams that make structural and procedural improvements. Take deliberate action against poor engineering decisions: delay an implementation rather than accept a poor one. We have to live with the consequences of our decisions; make clear that we have invioable standards of performance.
Nobody is irreplaceable. Inheriting somebody else's code is never much fun. We have to deconstruct what other people were thinking at the time they created it, while simultaneously trying to understand the business context that existed at that time versus the context that exists today. It's much easier to fight for funds to perpetuate a legacy team than it is to take responsibility for cleaning it up.
Two things to remember: it's just code, and the people behind both the code and the business usually don't have as much systemic or contextual knowledge as we project into them that they have.
To the first point, most code is not as algorithmically complex as we are told that it is. The implementation might be complex, but implementation decisions are generally easy to discern (somebody really liked Java interfaces, so everything is implemented as an interface). Once we figure that out, it's fairly straightforward to restructure the code and increase test coverage to make it more testable. This is true for current and legacy languages alike.
To the second point, don't assume that the business leaders have as solid a grip as you'd hope they do as to why they do the things they do. Some years ago, I was working with a firm to redesign fleet maintenance operations. The existing suite of software tools were a combination of RPG, Visual Basic, Java and Excel, tied together with a number of manual integration steps. The business operations leaders could only understand operations in the context that the technology allowed them to do these things. We had to understand their business operations better than they did to get them to understand the actual value stream.
Do not be held hostage by tribal knowledge or the perception of that tribal knowledge. Reward people for knowledge sharing and provide career paths for people to move beyond system caretakers to leadership roles that builds on their experience in mission-critical systems and knowledge of how the business itself operates. Do not be afraid to cut people loose who are obstacles to change, no matter how entrenched they are perceived to be. Best of all, replacing legacy systems will reduce pockets of that knowledge: we start the clock ticking on it the minute we start to retire it.
Put your personal credibility on the line for these things. A CIO has only as much time as the M&A horizon to create a common culture within the technology organization. Whatever the cultural norms are of the two firms at the start, insisting on engineering excellence, business leadership, and gradual improvement while being willing to accept responsibility for cutting loose tribal knowledge sets a decisive tone of change within an organization. This creates both a new mission and a new identity for everybody.
Most importantly, we have to make it clear to all and sundry that we are every bit as much on the line for these things as they are. We will take responsibility for a delay in implementation where quality is sub-standard. We will develop new leaders in our organization rather than being forced to retain people in existing roles. Our actions will speak louder than our words.
Nobody is irreplaceable. If we fail to deliver, we'll find that out to be true for us, too.