In my time at Microsoft I drove technical due diligence for potential acquisitions many times. This is a solid article but I'd like to add a few points from my experience.
I have to admit that I view my track-record in engaging in M&A activity during my career at Microsoft as almost perfect. Out of the dozen M&As I was involved in only ONE actually closed with an acquisition; the rest Microsoft walked away from. I view this as successful because I was never the biz-dev guy, always the technical guy. I'm quite sure my biz-dev colleagues felt the opposite about our "success rate" because, at large companies biz-dev people involved in "corp dev" or "M&A" activities are typically measured, at least in part, on how many deals they complete a deals a year. When I was doing this I never actually had any written commitments/goals for M&A work. It was just something I got roped into/volunteered to do. And I always took the principled approach.
As a guy driving due diligence I viewed it as my job to find all the skeletons in the closet ahead of time that would make the deal impossible for Microsoft to swallow. I'm not saying that all the deals MS didn't do that I was involved in were due to my work; they weren't. But a few were. I found some serious skeletons.
The skeletons I found had to do with three things, which were also the things I explicitly tried to uncover:
1) Horrific code quality.
2) Weak people.
3) Improperly licensed 3rd party code.
You can imagine how I uncovered details on each of these. In some cases #2 was the hardest to accomplish because interviewing employees of an acquisition target is actually very hard. The target often does not want employees to know it is a target early on in the process. One reason is what would happen if the deal did not go through: The employees would know (and probably leak) that a major Co. had attempted the acquisition and turned away. This could be devastating to the target company. When we did interview target company engineers we often found shockingly bad engineers.
Reviewing the code (and often just as importantly the engineering system) was always the most revealing (and damning). Engineering debt creeps up on a lot of small companies and, in cases where the deal is to "buy code", is a deal breaker.
The thing that we had the biggest allergic reaction, however, was #3 above: Improperly licensed 3rd party code.
Many of the acquisitions I was involved in were associated with Windows in some way. The risk to having Windows being contaminated by either commercial code that was not clearly licensed or by open source code with a license like GPLv2 was huge. And we found it all the time. Initially it was shocking to me how these small companies were so cavalier about plagiarizing code with no thought about the consequences; especially given these companies clearly had long term strategies of being acquired at some point!
So add to this great article the following pieces of advice:
1) Set your hiring bar high and be hard-core about managing poor performers. Remember the maxim that As hire As, Bs hire Cs, and Cs hire Ds.
2) Invest in reducing your engineering debt, particularly in the areas of your code where a potential acquirer is going to find the most value.
3) If you use 3rd party code, or open source, take the time to ensure you are using it in a way that is compatible with potential acquiring companies. DO NOT BE SLOPPY.
Can you give some more detail about what your process was for determining code quality? Just getting people to get a checkout and read through it? Running static analysis tools? Examining commit histories?
I have to admit that I view my track-record in engaging in M&A activity during my career at Microsoft as almost perfect. Out of the dozen M&As I was involved in only ONE actually closed with an acquisition; the rest Microsoft walked away from. I view this as successful because I was never the biz-dev guy, always the technical guy. I'm quite sure my biz-dev colleagues felt the opposite about our "success rate" because, at large companies biz-dev people involved in "corp dev" or "M&A" activities are typically measured, at least in part, on how many deals they complete a deals a year. When I was doing this I never actually had any written commitments/goals for M&A work. It was just something I got roped into/volunteered to do. And I always took the principled approach.
As a guy driving due diligence I viewed it as my job to find all the skeletons in the closet ahead of time that would make the deal impossible for Microsoft to swallow. I'm not saying that all the deals MS didn't do that I was involved in were due to my work; they weren't. But a few were. I found some serious skeletons.
The skeletons I found had to do with three things, which were also the things I explicitly tried to uncover:
1) Horrific code quality.
2) Weak people.
3) Improperly licensed 3rd party code.
You can imagine how I uncovered details on each of these. In some cases #2 was the hardest to accomplish because interviewing employees of an acquisition target is actually very hard. The target often does not want employees to know it is a target early on in the process. One reason is what would happen if the deal did not go through: The employees would know (and probably leak) that a major Co. had attempted the acquisition and turned away. This could be devastating to the target company. When we did interview target company engineers we often found shockingly bad engineers.
Reviewing the code (and often just as importantly the engineering system) was always the most revealing (and damning). Engineering debt creeps up on a lot of small companies and, in cases where the deal is to "buy code", is a deal breaker.
The thing that we had the biggest allergic reaction, however, was #3 above: Improperly licensed 3rd party code.
Many of the acquisitions I was involved in were associated with Windows in some way. The risk to having Windows being contaminated by either commercial code that was not clearly licensed or by open source code with a license like GPLv2 was huge. And we found it all the time. Initially it was shocking to me how these small companies were so cavalier about plagiarizing code with no thought about the consequences; especially given these companies clearly had long term strategies of being acquired at some point!
So add to this great article the following pieces of advice:
1) Set your hiring bar high and be hard-core about managing poor performers. Remember the maxim that As hire As, Bs hire Cs, and Cs hire Ds.
2) Invest in reducing your engineering debt, particularly in the areas of your code where a potential acquirer is going to find the most value.
3) If you use 3rd party code, or open source, take the time to ensure you are using it in a way that is compatible with potential acquiring companies. DO NOT BE SLOPPY.