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
hearts:
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.