Four things you can do today, to sail through technical due diligence
When it comes down to it, there are really only two sides to due diligence: 1) assess the value of a potential investment or acquisition, and 2) look for issues and risks. For a variety of reasons, technical due diligence typically starts pretty close to the end of a deal lifecycle. It’s usually because it’s expensive to perform, and can be pretty disruptive to the business. At any rate, by the time you’re going through technical due diligence, most people involved in the deal are already (almost) convinced it’s worth doing; You wouldn’t be as far along otherwise. In any universe, big or small, there has to be balance. The universe of an investment deal is no different. If everyone just focused on value and promise, pretty much every proposed deal would go through, and on average we would be making pretty terrible investment decisions. By the time due diligence starts, the last thing standing between a lot of excitement and a risky deal, is often — you guessed it — technical due diligence. In the case of a potential acquisition by a larger company, the dynamics are usually not that different. If you’re the CTO or other tech leader at a company that is about to acquire another, one of the things you definitely try to prevent is to end up eating someone else’s technical debt and other baggage. That’s what I’ve done, and that’s what I’ve heard from every other CTO who has been in that position.
“Find all the reasons not to do this deal”
As a result of those dynamics, this is usually the going in position for technical due diligence, and it puts the sell-side technical team in harms way. If a deal does not go through because of the risks and issues found during technical due diligence, it’s going to reflect poorly on the technical leaders. Never mind if the product was hyped up by investment bankers or the rest of the C-suite, and none of the issues were disclosed before. Honestly, every CTO has a list of things that need fixing, but you never seem to get around to, and often times those issues were not their fault in the first place. In the end, though, if technical due diligence fails because that list of things to fix is much bigger than expected when the LOI / term sheet were sent, it’s going to be on them, and that sucks. So here are some tips on how to reduce the “fix-it” list and increase your chance of success.
There are some really simple things you can do today (seriously, just block 8 hours and do it), which will dramatically decrease the chance things will go poorly. When I perform diligence on a company, these are some the issues and risks I look for, and you’d be surprised how often these simple things are not in order.
Bad demos / code reviews
You can expect to be asked for a product demo. It’s pretty much guaranteed. I’m not sure how your success rate is for unprepared demos, but for me they’re a guaranteed fail. A good demo might need some pre-groomed accounts set up, and data prepped for interesting scenarios. You should figure out what will make a good demo, set things up, and practice them. I’ve seen bugs pop up during demos, and worse. Don’t let that happen to you. Another thing I like to do when I perform buy-side diligence, is to ask for a code walk-though of some of the use cases that I just saw in the demo. It gives me a good holistic understanding of the product.
On the topic of code reviews: Prepare for them! I ask for a review of the best / newest code and some of the worst / legacy code (I didn’t come up with that myself; someone doing diligence on my previous company asked it, and I thought it was a great request). Sanity check the code for crude comments. Some of us developers can be harsh on one-another (and ourselves). I had to remove my own comment stating “this should never be in production” from code that had been in prod for 8 years (and it performed just fine, by the way). Not the kind of thing you want to see during a code review…
No answer for even basic security questions
Security is important for PE firms, larger companies, and late-round VC investors. They have something to lose, and frankly, you do to if you’re at the point when you’re attracting good investors. Security is in my experience the most neglected high-risk aspect of growing startups. Early on, when the biggest risks are problem / solution fit, and early product / market fit (Do I really have a business at all?), the focus should not be on building Fort Knox. But the gradual growth into a more mature organization often leaves behind the necessary increase in security. If a question like “Describe the tools and processes used to protect customer data” is met with deer-in-the-headlight stares, you can bet that the buy-side diligence team is going to go deep on security. Remember: “Find all the reasons not to do this deal”. Security, or rather lack thereof, is a goldmine for those…
Now, just to be clear: I’m not claiming you can fix your security in a day. It’s one of those things you can spend all your resources on, and still end up having issues. But you can, and should, regularly assess where the biggest risks are, and take steps to mitigate those risks. If you haven’t done that yet, or in the past year, now is the time to do so. Knowing your biggest security risks, and having some strategy that seems reasonable to address them, is the bare minimum we expect when we perform diligence on a company. If you can’t articulate this when asked, we’ll find some potential issues for you. And in my assessments, “The team was unaware of these basic security risks” is always worse than “The team has a basic strategy to address” or “There is a roadmap and plan to methodically address these risks”.
HR mess / inconsistency
When you’re doing diligence on a company / product / team, you don’t have much time to get a good picture of how the product- and technology teams are organized, and what processes and tools they use. The buy-side team will usually ask for a description of all the different roles (titles) within the technology- and product teams in the organization, and a description of your SDLC and product design / release planning processes. It’s good practice to have that documented anyway, so that when people join your team (assuming you occasionally hire people) or switch roles, they don’t have to find out the hard way what they’re supposed to be doing and how. You’d be surprised how many companies end up frantically creating this stuff when they get asked during due diligence. Not a great sign…
What’s worse, is that there might be a separate diligence team (legal / HR) asking the HR department for something similar. They typically want to see a roster of employees, reporting structure, titles, salaries. I can tell you that the information from HR rarely matches what you get from the technical teams. That is confusing and does not look good. You really don’t want to make the buy-side team’s job much harder than it needs to be. It drags out diligence, and there will be point where the conclusion might just be: “This place is too much of a mess”. Just go to HR today, and ask them to product the list of people on your team from their system. If it doesn’t match what you have, either fix it, or agree that the data should not be shared outside the company without first it cleaning up. It shouldn’t be a lot of work, and it can go a long way during diligence.
Open source software usage / policy
Do you have an open source software (OSS) usage policy? You don’t? Neither did I the first time I went through due diligence. You know what we did when that question showed up in one of the questionnaires we were asked to fill out? We created one that day. It was dated that day, and enforced going forward. We asked our outside counsel for a good policy, and they sent one over. It was that simple. You should do that today, and here’s why.
The second part of the request was significantly less simple: Provide an overview, including license, version, and use, for all third part components, libraries, and open source software used / distributed with the company’s products, or used to build, deploy, or manage product infrastructure. We were keeping track of that information to some extent, but per our brand-new policy, we had to do an internal audit to get the information up to date. So that meant a small army of people dropped what they were doing and spent a day searching through all source code and analyzing build scripts etc. Fun… It’s much better to do this beforehand, and you are guaranteed to get this request.
There are some horror stories about companies that were using “copy-left license” open source software in their product, weren’t aware of it, and only found out during due diligence. Some of those stories end with a potential acquirer suing to get all the source code published, according to the license terms, and paying absolutely zero to get all the company’s IP. Yikes. There are tools you can use to automatically scan for OSS software, which can make the job a lot easier. If you’re lucky, your tech stack has a tool that can help. At any rate, if I’m assessing a company, and there is no OSS policy or convincing list of OSS use, I will recommend to get both addressed before closing the deal.
And again, the longer these things take (and the “little” things add up), the lower the chance of the deal ever closing. So start chipping away at them today.
