If your company is undergoing a transaction to be acquired or preparing for an injection of investment,
as part of the process you may hear the phrase that can strike fear into even the most hardened of
We’ll have a team come in and perform a technical due diligence
Upon hearing that the questions you may have swirling around include:
What does it mean really?
What sort of things are they looking for?
How is it performed?
Should I/we be concerned?
What can I/we do to prepare?
Let us take each of these one-by-one and take a deeper dive, by the end of it, you should feel much better informed as to what is about to happen. While we will focus on the technical side of the company, many of the same themes will apply to other departments, including finance, which usually gets the most intensive due diligence performed on it.
Buying or investing in a company is not dissimilar to buying a house and a due diligence in that market is called a home inspection. If you have ever bought or sold a house, then you will know only too well what this report yields. A home inspection report is the result of of an expert crawling around into every nook and cranny of a house looking for big problems that are often invisible to the naked eye. For example, is that big crack in the basement letting in water really that big a deal, or the gaps in the roof letting in light a feature or a problem? Stuff like that.
It is the same thing with a company. The buyer or investor wants to make sure the company they are about
to get involved with can do everything it claims to do with no hidden problems. They want to get behind
the marketing hype of the sales deck and validate some of the claims made.
So at that level, it is a very reasonable and responsible thing to do (again think house buying — you wouldn’t buy a house without a home inspection). As with the home inspection report, each buyer is responsible for their own, and to that end, if you are in a process of being bought, you may find yourself undergoing a number of these in a short space of time by each of the interested parties. Not surprise you to learn, that like the home inspection report, you as the seller, rarely get to see the end report. This is a large vantage point you miss out on.
The type of transaction and the buyer who has initiated the due diligence will determine which area the
report will focus in on. There is not enough time (or money) to do a deep dive on absolutely everything,
so there will be a strategic meeting prior to starting as to where they want to know more information.
First thing they will want to do is to get a read on the logistics of how you support the current day-to-day operations of the company. Typical things here include; enterprise setup, technology stack, software management process, and personnel. At this stage they are looking for any red flags that may be of concern to a new buyer with the classic issue being a significant amount of the business relying on out-dated or unsupported hardware/software.
Then it will be deeper investigation into a particular area that the buyer has expressed knowing more about. For example, if the buyer plans on scaling the sales of the company, can the platform cope with immediate growth, or if there was another product idea they plan on building or bolting on, can the platform cope with this, or does it require significant investment to support the growth.
Another typical thing that is often sought after is key-man identification. Who within the company has all the knowledge and is the goto person for when things need fixing? Every company has that person, and more likely than not, there is little to no documentation around to support their absence. Getting to know their boundaries and their motivations for staying with the company will be crucial.
Most buyers will know what they want to do with the company before they close, therefore, they want to know as much as possible on the amount of investment that is required to realize their wants. Chances are though, you won’t be told of their plans, but you can make educated guesses depending on where they kick the tires. This is where any legacy systems that should have been taken care of many years ago, may come back to haunt you.
The first thing to remember is that it isn’t an interrogation, but instead, a conversation. Each due diligence team has their own way of doing it, from being very formal with a list of questions (which comes over more like an audit — which a due diligence is not) to a very friendly relaxed conversation with key individuals within the organization to help them find what they need to know.
The second thing to remember, no one is out to trick or judge you. There isn’t any clever courtroom
style questions that you have be careful with, it isn’t a deposition. The vast majority of the due
diligence is performed through oral analysis particularly around explanations of product demonstrations,
system diagrams or source code walk-throughs.
Depending on the buyers motivations, there may also be source code analysis tools run against the code base to get a feel for technical debt, general maturity of the code and dependencies on external or open source libraries.
The typical duration can be anywhere from an hour on the phone, to a number of days onsite. Again, it all depends on what the buyer wants to know. Back to the home inspection analogy — if we are planning on building an extension out the back to house an additional 4 bedrooms, will the current bathrooms support the extra load?
If you have nothing to hide, then no. The good news is that rarely a deal goes south because of what is
found in a technical due diligence. What is more likely to happen though is that the value of the deal
is reduced because of a finding or the plans post-transaction are changed slightly. If it is something
that is obvious to everyone (outdated technology stack that is difficult and costly to replace) then
this will become a major project item post-transaction. That could mean a change of priority to address
the concern or even more dramatic, a change of team to fill in the knowledge gaps.
Overall the key here is honesty. Any deliberate lying or misdirection will rarely win any favors. Worst case, it will cost jobs because who wants to trust the person that lied to you before you bought the company to run the department afterwards?
Where it can fail, is when you don’t have any documentation/process, or you are in continual fire-fighting mode with little time to build new product features or pay down technical debt. If this sounds familiar, you need to prepare for why it is like this, without necessarily blaming anyone.
A well run engineering group supporting a live production environment should never have to worry about
answering any questions on how they do their jobs so successfully. So things like documentation, well
practiced and adhered processes and standards will all help support that.
If you don’t have that, then start identifying the areas where you are failing, and start making plans to address them. You don’t have to fix them before a due diligence starts, but the fact that you have identified the problems and thought through a resolution plan is enough to instill confidence.
Like many home sellers, you can also get ahead of the due diligence, and invite a team in to do a mock due diligence on you. It will be a full due diligence process, except this time, you will actually get to see the final report. This is an increasingly common practice as it gives a company team enough to address any major short comings and get out ahead of any potential roadblocks. We at the MacLaurin Group offer this service, including advising on how best to position your future road map.
Overall, a technical due diligence is a very critical part of the company buying process and should not be taken lightly. It is important to have the right people talk to the due diligence team, so they have all the information they need to form and paint the picture back to their buyers.