Lessons from mergers and acquisitions
During my last stint of 10 years in an enterprise application company, I was fortunate enough to see many mergers and acquisitions as we grew (over a dozen). The acquisitions ranged from very small companies in far flung places like Scandinavia to the largest software acquisition (of that time).
The lessons that I learnt are the following:
Things always look great from outside. Almost always things were much more hairy than was visible before the acquisition. Be aware that somebody who is willing to be sold out would for very obvious reasons put their best foot forward. There are more stories than you would care to hear in my previous company where we had everybody involved in the acquisition swearing by the greatness of the company to be acquired and without exception, each one of them turned out to be disasters. That does not mean the executives and team members were not intelligent (although I will admit they were more impressionable than other others – I think that happens in young software companies especially if they do not have a healthy ratio of seasoned executives brought in from outside). What it says is that take all your time to do the due diligence. Assume that 50% of your conclusions are wrong. Then seek data to disprove that hypothesis.
Be clear about what you are acquiring for. Are you focused on acquiring the customers? Make sure that you do not lose the key people who have the customer relationships (which often is not the sales or account executive). Are you focused on increasing your footprint by acquiring IP? If so, read the next point.
You cannot integrate yourself to greatness This is perhaps the greatest learning I had. As one of my peers once summarized it best – When you buy IP, it is in the people not the software. Without exception, we followed the software route. Which means we tried to “integrate” all these products into one set of solutions? The nightmare was unbelievably costly and is what I believe eventually brought us to our knees. You are much better off taking the hit of isolating top 30% of the acquired company’s engineering group aside and tell them to rebuild the solution on your existing architecture all over again.
Don’t worry about which is the better architecture. In almost all cases, it is like debating over religion. Technology is way over-rated for most enterprise problems that customers face. You will much faster to market with a truly integrated solution with lesser overall cost (for both you and your customers) of ownership by taking the hit upfront. I admit it takes guts to do this. The whole world is expecting to show you results from the merger. But companies like Siebel, Cisco have this model outrageously successful.
I would like to reflect on the only successful merger we had. The big difference I see from the other mergers is that we had some amount of history with this company. We used to resell their product for about a year. I think that gave us a great due diligence. We understood what was working and not working in positioning this product to our customers and what the difficulties the customers were having with the product were. What we did not do is the point number 3 above and I have paid heavily for it!
Feel free to send me comments about your experience.
The lessons that I learnt are the following:
Things always look great from outside. Almost always things were much more hairy than was visible before the acquisition. Be aware that somebody who is willing to be sold out would for very obvious reasons put their best foot forward. There are more stories than you would care to hear in my previous company where we had everybody involved in the acquisition swearing by the greatness of the company to be acquired and without exception, each one of them turned out to be disasters. That does not mean the executives and team members were not intelligent (although I will admit they were more impressionable than other others – I think that happens in young software companies especially if they do not have a healthy ratio of seasoned executives brought in from outside). What it says is that take all your time to do the due diligence. Assume that 50% of your conclusions are wrong. Then seek data to disprove that hypothesis.
Be clear about what you are acquiring for. Are you focused on acquiring the customers? Make sure that you do not lose the key people who have the customer relationships (which often is not the sales or account executive). Are you focused on increasing your footprint by acquiring IP? If so, read the next point.
You cannot integrate yourself to greatness This is perhaps the greatest learning I had. As one of my peers once summarized it best – When you buy IP, it is in the people not the software. Without exception, we followed the software route. Which means we tried to “integrate” all these products into one set of solutions? The nightmare was unbelievably costly and is what I believe eventually brought us to our knees. You are much better off taking the hit of isolating top 30% of the acquired company’s engineering group aside and tell them to rebuild the solution on your existing architecture all over again.
Don’t worry about which is the better architecture. In almost all cases, it is like debating over religion. Technology is way over-rated for most enterprise problems that customers face. You will much faster to market with a truly integrated solution with lesser overall cost (for both you and your customers) of ownership by taking the hit upfront. I admit it takes guts to do this. The whole world is expecting to show you results from the merger. But companies like Siebel, Cisco have this model outrageously successful.
I would like to reflect on the only successful merger we had. The big difference I see from the other mergers is that we had some amount of history with this company. We used to resell their product for about a year. I think that gave us a great due diligence. We understood what was working and not working in positioning this product to our customers and what the difficulties the customers were having with the product were. What we did not do is the point number 3 above and I have paid heavily for it!
Feel free to send me comments about your experience.
posted by Rajib Roy | 10:31 AM
3 Comments:
the merger that worked, we didnt do it for the wall street :)
Rajib, I recall the merger, and I still point to it as the beginning of the end of what had - up until that time - been an incredible company, job, and future. It seemed that too many were drunk with the same "the only direction is up" euphoria that engulfed too many companies and people. Such a shame, but now it serves as an example of what not to do.
I agree and disagree with your statement below:
You are much better off taking the hit of isolating top 30% of the acquired company’s engineering group aside and tell them to rebuild the solution on your existing architecture all over again.
The point I agree with is that too many times, the acquiring company keeps the existing staff supporting the acquired product and fails to infuse enough of the legacy experience into the "rebuild", which causes the existing customers of the acquired product to become dissatisfied with the "rebuilt" solution, often faced with high costs to migrate, loss of functionality and not enough added value.
The point I disagree with is that, in my experience, many companies jump too quickly to "rebuild" the proven legacy solution. First steps must be an integrated solution with added value at reasonable or attractive cost. The re-build must be thought out very well, involve key people as you suggest, and have plenty of Beta and customer involvement. It can't be rushed!
Post a Comment
<< Home