Software Merger

Problem: A software company is not growing fast enough to keep its stockholders happy

Context: Multiple products competing in a mature (slowly-growing) marketplace

Forces:

The marketing & engineering departments spend most of their energy worrying about the competition
The absolute market shares of the players are changing very little OR a previously-dominant player's share is stagnant
Nobody expects engineering improvements to revolutionize the market

Solution:

Buy one or more of your competitors, exploit the synergy between your products, benefit from the increased efficiency born of your combined market share, and improve the growth rate of the marketplace!

What Happens Next:

( 1 week after merger) Executives of both companies announce that business will continue just as usual, that wonderful opportunities lie ahead for both the customers and employees of both companies, and that no layoffs are anticipated.
(1 month later, or after euphoria dies) Employees of both companies realize that there isn't be enough interesting work to support two separate engineering workforces, and that somebody is going to get stuck supporting an obsolete platform. They respond, depending on individual temperament, by (1) leaving or (2) playing politics to ensure that their team is given responsibility for the most interesting new project. Engineering progress grinds to a halt.
(2-3 months later) A senior executive of the buying company announces a new, improved, merged product, which will provide an easy upgrade path for both sets of customers. The first round of layoffs is announced, covering mostly non-engineering personnel. The wars inside the merged divisions intensify.
(6 months to a year later) After engineering has fought itself to a standstill, management realizes that it is impossible to produce a merged product, because the two apparently-similar products were actually optimized for quite different, and incompatible, goals. Management announces that one of the two products will continue to be developed, and "an upgrade path" will be provided for customers of the other product. The second round of layoffs is announced; it includes many engineers.
(later still) The "upgrade path" turns out to be a copy of the new release of the winning product, plus a warm hug from the customer's sales representative.

Lessons Learned:

It is rarely possible to add two market shares and achieve their sum. More often, the sum of two market shares is only slightly larger than the market share of the acquiring company.
Competing software products survive because they are solving different problems.
Merging independently-developed software is rarely possible.
Developers who are accustomed to thinking of one another as enemies find it hard to work as unified teams.
Software engineers have excellent self-preservation instincts.

Another Lesson Learned, or perhaps a different take on "self-preservation":

An organization that fails to paint a vision of the future that people can see themselves being a productive part of risks losing those people. Software engineers want to contribute, and will do so - somewhere else, if necessary.

-- DaveSmith

In '01 I was working for a company that was acquired. An experienced guy told me what would happen over the next year - which looked awfully like the sequence of events described above. Sure enough, it all happened right on time - I particularly liked the bit about the abortive attempts to weld together products that were intended for different markets and that had totally different technology platforms. A year after the 'acquisition' we all got the bullet - actually with a fair amount of relief all round.

Given that the acquirer is still going, it probably didn't work out too bad. But most software M&As between similar sized companies appear to be terminal for one of the teams involved - any good counter examples?

The best is when an IT group scrambles to create a new project from scratch to justify their continued employment. One of the 2 companies was using state of the art Identity Management software (MaXware?), but instead of integrating it into the new company's domain, the other IT department proposed rewriting an Identity Management solution from scratch (which could easily take 8+ years) and the glossy-eyed manager who has no clue what he's hearing, approved it. Dazzle the PointyHairedManagers? with technobabble in order to keep your job.

It has happened to me, just this very year. Was working for a large market leader financial company who had a very small web-dev team with lightweight products on latest framework providing their web channel for products. Large staid market leader financial company acquires small up-and-coming youth-friendly insurance company with a fantastic successful marketing department. Board of old staid company assumes new whizzy company will have equally whizzy IT which will regenerate its own offering, and forces the two IT dvisisions to merge by giving IT bosses of small whizzy company senior IT roles in large staid company. Bosses then start on a process of 'merging' the two systems, which meant replacing fairly modern lightweight web offerings with their completely UNwhizzy 10-year-old CMS system which was already struggling to cope with the two web products they had before acquisition. I tried to use it.. for almost a year, before moving on. I fear for them.

CategoryAntiPattern CategoryOrganizationalAntiPattern