IBM closed on their merger with Red Hat this week. I’ve covered a lot of mergers over the years and, by far, most of them have been disasters. The first, and the most painful for me, was an IBM merger, ironically. When I first moved into technology, it was to work for a company called ROLM which had a “Great Place To Work” department. I was told, without prompting, that the rumors of IBM’s acquisition of that company were false. IBM subsequently bought it and promised to leave it alone and then broke every promise—eventually all but killing the company. Siemens then bought the firm from IBM, costing IBM another estimated $5B in one of the most insane deals I’ve ever seen and finished killing the firm. Both firms used a merger process that has been widely discredited even though it was, and remains, very common.
As a result, however, IBM decided to completely revamp their process—and the outcome is they have been having a ton more success with acquisitions this decade with SoftLayer being the poster child for this success.
Let’s talk about what will likely happen as this merger progresses.
What Makes This Process Different: Lack of Change to Critical Assets
At the heart of this process is the preservation of assets critical to the value that they purchased. This is different than the typical merger where the emphasis is on creating a relatively homogeneous result and the acquired company’s assets be damned. The assets that IBM appears to have identified include Red Hat’s anonymity and independence which pretty much assures the firm’s operations will remain at arm’s length from IBM.
This means that customer relationships should be largely unaffected, services will be largely unchanged, and product road maps will remain intact. The parts you touch at Red Hat should remain largely unchanged initially but, over time, I’d anticipate the firm will have more money for research and development, will be able to afford to staff up more (reducing response times), and product lines will advance more rapidly.
In short, the things you like about Red Hat should remain relatively untouched.
Change
However, this doesn’t mean there won’t be any change. IBM is far larger than Red Hat and that means they can typically get more aggressive prices for things that range from deals for employee travel, to hardware, to services (in fact many of the services that Red Hat itself uses may shift either to IBM or to an IBM service partner using IBM’s intercompany and external discounts).
Common services like accounting, HR, and legal are likely to either merge, rotate over to IBM, or fall under an IBM program because of IBM’s economies of scale. Logistics aren’t as critical for a software company as they might be for a hardware company, but this still should result in significant operating expense reductions at Red Hat once these programs are in place.
And, I would expect, for things that IBM produces (like the IBM Cloud, and Watson) intercompany charges which are typically sales tax free will also be far lower than they would be for a regular IBM customer—both increasing Red Hat’s management resources and providing additional cost relief.
Wrapping Up: Poster Child for Mergers Done Right
In the end, and in sharp contrast to that ugly ROLM merger I so well recall, the Red Hat merger (which is really less of a merger and more of an exercise in creating stronger synergy between the firms) should be a poster child for how to do these things well
This is a process that few companies follow and yet it is a process that is far more successful than what is more commonly done. I just wish, as I expect do most employees of acquired companies, that more firms would follow IBM’s process (Dell Technologies does). The result would be a far higher return on the investment in the acquisitions that firms make, far more job security in acquired firms, and far higher subsequent customer satisfaction and loyalty.
As with all things, there is a right and a wrong way to do acquisitions, IBM was the posterchild for doing it the wrong way. They are now the posterchild for doing it the right way. Others could learn a lot from IBM’s process. It is sad that they don’t.
Oh, and while I focused on the changes at Red Hat, IBM also gets a far closer relationship with that firm and should get a huge return on their investment in the firm largely because that is the focus of an effort like this. If you focus on getting a return and assure the value of the assets you purchased the result should provide a solid return. I just don’t understand why more companies don’t get this.
- Qualcomm’s Snapdragon 8 Elite: Changing the Dynamic for Smartphones - December 17, 2024
- Intel Launches Impressive Battlemage GPUs Just in Time for Christmas - December 12, 2024
- Microsoft Recreates the Terminal with Windows 365 Link - November 26, 2024
This is what will be the biggest issue depending on how far they take it… “Common services like … *HR*, … are likely to either merge, rotate over to IBM, or fall under an IBM program because of IBM’s economies of scale. I worked at both companies and have kept in touch with people at both. Red Hat offered generous RSU stock grants, paid out bonuses at around 100%+/- 10% every quarter (save for 2 in the great recession) for the 8.5 years I was there, great work from home, great benefits, no ongoing layoffs (some firings and a few layoffs with acquisitions only), etc… Lay on IBM’s HR version of this to Red Hat and it will really damage the organization (engagement, morale, retention). If they don’t converge Red Hat to IBM’s systems (or visa versa), then you have 100,000s people in the main organization looking with covetous eyes at the “unfair” situation.
I do believe the tech teams will work together well and collaborate. I think there will be some tough discussions wrt JBoss vs WebSphere (on Openshift and other delivery models too).