Banking

IT leaders: How to survive a merger

While being faced with integrating systems, people, and processes, surviving a merger can be tough. Here are some tips for how to do it.

Surviving a merger or acquisition can be a daunting task. While being faced with integrating systems, people, and processes, you're simultaneously wondering whether your job will exist next month, or whom you'll be reporting to this week. Here are some suggestions for IT leaders on surviving a merger.

There are no "mergers of equals"

Despite flowery press releases filled with happy talk about "synergy" and "mergers of equals," there really is no such thing. In the majority of mergers, one company is usually the de facto acquirer and the other company acquired. Generally the company writing the check calls the shots and drives the process, but from an IT perspective the monetary acquirer may actually be looking to buy a superior IT department, and thus its internal IT becomes the acquired. In most cases, one IT department will be forced to integrate with the other, largely adapting its systems and processes. Knowing which side you're on will help guide your expectations as you move through the integration process.

Culture is critical

In IT we rarely worry about culture, preferring to leave this type of "soft skill" to the likes of HR or an internal change management group. However, with a merger, culture becomes increasingly important. As you're cobbling together systems and processes, you'll also be faced with integrating potentially disparate cultures. This moves from touchy feely to the realm of the practical in concrete ways. For example, when one of my clients acquired another company, an unforeseen difficulty was the contrasting cultures. The acquirer had a very distinct "command and control" culture, where decisions were centralized, standardized, and then passed down throughout the organization. The company they acquired lived and died by local management, who operated largely autonomously. When the command and control style of management was applied to the acquired company, revenue was lost as old support structures and informal networks were quickly removed.

Even something as simple as your help desk could present a cultural nightmare. If one of the parties to a merger is used to informal support or an IT person in an office around the corner, quickly changing to a centralized ticketing system will create unease at best, and at worst swamp your well-oiled help desk and send it into a tailspin for the entire organization.

Test beyond the technology

Everyone knows that testing is critical for any sensitive rollout, but mergers usually present a time crunch and sense of false security that leaves testing incomplete. When the merger is between companies in the same or similar industry, there's an obvious desire to rapidly integrate systems and avoid the expense of running two sets of systems for one business function. The similarity and time pressure to integrate and cause cursory IT-driven testing, where technologists exercise the technical functionality of the integrated system but don't exercise all the business processes.

Make sure your testing team is well stocked with business process experts from a diverse pool of talent in the acquired company. Run real data through your test systems gathered from actual transactions, and exercise the major business functionality of the integrated systems before releasing it to the wild. Ideally, release the integrated system to a small initial group of users, work out the kinks, and then proceed with larger releases.

Train and then train again

While the acquirer's systems may seem like old hat, and you may have training down to an exact science, the company you're buying may never have encountered your systems or, even if they're similar, is unlikely to understand how you've configured and customized the system. Like testing, it's tempting to speed through training or bang out of few web conferences and call it done, but you'll pay in the long run with an unsuccessful implementation or expensive retraining.

Keep the information flowing

Mergers are full of distractions, none more compelling than the nagging question, "What happens to me at the end of this?" Everyone from C-level staff to line employees is wondering if their job is secure, or if the vaunted "synergies" include replacing them with someone from the other side of the merger. While you obviously can't disclose everything, sharing what you can and providing frequent updates will keep some of the panic in check. Realize that your people may not perform at their peak when they think their job will disappear, and ensure that you as leader set the example of focusing on the tasks ahead rather than speculating about where you'll end up tomorrow.

The flip side to job-related questions is that mergers often present opportunity among the chaos. As the two companies essentially rewire their IT, there are myriad opportunities for leaders and line level employees to rise to the occasion and prove their mettle amid the chaos. If nothing else, successfully integrating two company's systems, people, and processes is a highly regarded skill.

About

Patrick Gray works for a global Fortune 500 consulting and IT services company and is the author of Breakthrough IT: Supercharging Organizational Value through Technology as well as the companion e-book The Breakthrough CIO's Companion. He has spent ...

1 comments
Lost_in_NY
Lost_in_NY

From what I've seen, by far the biggest factor in whether or not a person in IT or in any other department for that matter keeps their job during the 'merger' shakeout depends on where they came from - if they worked for the bigger/richer company, their odds are a hell of a lot better than if they worked for the company being acquired. When the company I worked for 'merged' with a bigger/richer one, I went all out to find a position elsewhere and within 2 months, found something with more responsibilities/learning opportunities and more money; within 2 months of my leaving, 2 of my colleagues who were in comparable positions to mine had done the same; within 3 months of that, more than half the our remaining colleagues including our boss, peers and lower level techs had been let go. About a year after that, hte majority of the remainder of our IT organization had been outsourced... So, based on my experience, get out early if you are from the smaller/less profitable company - no matter how good your reputation or accomplishments have been there, it isn't going to be your current management making the decisions.

Editor's Picks