Tales from the Basement - Mergers and Acquisitons (1)

There is something about bus stops. Maybe because I often find myself standing at them, alone in the wind, with dim lights, and the wind blowing through my in need-of-a-haircut hair, but they make me think. Usually when I get these thoughts, it's probably remenicing that I am no longer leaning on a lamppost.... (ignore the comment, I just think Ian Angell, my former tutor, 's book "No More Leaning on Lampposts" has a surreal title, and its content is even more interesting).

Anyway, I know a couple of friends of mine that work in M&A, or Mergers and Acquisitions divisions of some leading investment banks. It's like slavery, because these people work the longest hours there is, and call there excel sheet home. I do not really want to know what there actual jobe entails, but my friend, the exotics trader, claims its the most boring and tedious job in the field.

That's there choice, although, I'd like to find out if those M&Aers know what it is like to be on a receiving end of a merger or an acquisition from the client side. They broker and engineer the deal, but once it goes through, they make their cut, and skedadle off, with the clients left to deal with the mess of either merging, incorporating, or integrating the 2 companies that just got M&Ad (nice I should make a t-shirt that says "Smile! you've just been M&A-d).

Well, I am on an integration team for a company that was aquired by another, much larger, company. I'll focus on the tech side for now, rather than the acquisition process, which is buying out the partners, all the outstanding shares, assets etc etc...

The way acquistions usually work, at least in software, is that companies make a strategic build-vs-buy decision once they are looking at usually a 5-year growth/survival/competitivness plan. A company will decide that it needs to offer a certain product or solution, either to gain a competitive advantage, or maintain competitivness within the market it operates. Usually, the second reason is the main reason for an acquisition: the idea already exists in the market, is offered by the major competitors, or a small company offers it, and it is small enough to be acquired. (That small company is usually a spinoff or a venture by someone in the business, who isn't really shooting at becoming a competitor himself, and can sell the idea with a working product and a client base, making a nice bonus when the company is acquired). On the other hand, usually new ideas are built in-house by companies, and existing ideas are only built internally when buying an already existing company-product (interchangeable terms here), is less cost effective.

Which brings us to the main problem, or issues that the i-bankers don't have to deal with, which is integrating the businesses together now that they have been M&A-d, which is one of the situations I am in. We, the mother company, work mainly with C++, which is the cornerstone of our applications framework. Mainly financial databases, market data, stock exchanges - and that's the most I can tell you due to respecting confidentiality! Anyway, the acquisition company operate(d) with Java. I can't say much about the details, but, C++/Java interfacing, especially that these are serious products with a serious code base, that is at least a few years old, are not in the .NET/C#/JVM kind of integration realm, which creates some hoops to jump through to create a seamless experience for the end-user: Be it Java, C++, or Spaghetti Gorgonzola, for the user, it should all be the same speed, same look and feel, same results - everything.
If you work with software, you are probably familiar with the concept of meshing , and we all know how much that can be of a pain. That's why, we , just like many other companies in finance that worked with a wide scope of data formats and forms, have their own internal integration technologies, to create one main interface that all technologies need to integrate to, and that's the main interface that the user interacts with.

It's a tough spot.... Internal technologies are always clunky, clumsy, buggy, because, there are just that many people working on refining them- it's not like open source, with myriads of people working on the infinite use cases a programming language or system may have. But, in finance, two things are prevail:

1) There are too many data sources that you have to have a common platform - a suite that brings everything into one place.

2) Finance institutions have the money to build serious technology in house, and lack the trust to give it to anyone else!

At least that's the technology briefing on M&A, but there is the other managerial side as well: different structure of work, different hierarchies, different corporate culture, different business process, etc etc... that often when an acquisiton is made, there is alot of people shuffling, with people leaving and new people being brought in to join the new kids on the block. (I'll talk about this in another post).

All of that, is not the worry of the M&A dudes......

But, hey, justice comes to some eventually! With all the i-banks feeling the squeeze, some have merged or been bought out by others, and now they can see what it is like to be M&A-d!