Why you should prepare for technical due diligence
“Companies don’t get sold; they get bought.”
This great nugget of wisdom was shared by one of our board members, when we first started discussing our potential exit. I understood what he meant, but didn’t really get it until we went through due diligence for the first time. There were many more layers to that simple statement than I thought. Of course I understood that the decision whether a deal goes through, or even makes it onto the table, is with the buyer. What I didn’t anticipate, is what it feels like, when as technical leader in a startup, you get a visit from the buy-side technical due diligence team, and they start digging. For the most part, we had our ducks in a row. Our technical debt had been paid off in the years before we tried to sell the company, our management structure and processes had matured, and we even had decent documentation. But still, when the CTO of the potential buyer and one of his architects showed up, we really had no idea what to expect, and our usual confidence was nowhere to be found. The first time kind of sucked; we were not in control.
Most startup CTOs have never been through due diligence, and there’s not much support out there to help them prepare.
Mid last year (2017), we finally did it! The company where I had spent over a decade building products, infrastructure, and a growing team, had its long-awaited exit. GreatCall, a connected health- and safety company (known for the Jitterbug cell phone and the 5Star urgent response service), sold to GTCR, a Chicago based private equity firm. The sales process itself impressed me. Between our team, the investment bankers, and the PE firm, everything ran so smooth and fast, that other interested parties didn’t stand a chance. We closed quickly. With small acquisitions, due diligence can be pretty nimble and fast, because there’s not that much to lose, but this wasn’t a small one. GTCR had hired a consulting firm that specializes in buy-side technical due diligence. They came in, did their thing, and quickly gave us the thumbs up. The whole process, including technical due diligence, was actually pretty enjoyable to me. Stressful, but enjoyable.
So what was the difference? Why did it go so much better, and feel diametrically different?
The answer is simple: confidence and control.
We were prepared for what was to come; very prepared. After having gone into due diligence the first time (when we did not sell the company), we had a much better understanding of what to expect, and how to prepare. And in our case, there were about 3 years in between the first- and last time (and a few in between). This was plenty of time to fix the issues we found 3 years ago, and to prepare for the anticipated documentation requests (we were big and mature enough that an acquirer should expect decent documentation). Intuitively, I took it a little further, and created a deck that told the story of our technology and our teams. (The running joke among my team members at the time, was that Power Point was my IDE, and it kind of was.) I initially intended for it to be included in our management presentation (pitch deck), but the investment bankers wisely cut all but 10% of it, and stuck the other 90% in a “technology and product addendum”. I did not take that personally, and instead decided that I would stick it in the data room, and design the structure of our part of the data room around it. It became sort of an index to our part of the data room, with all the supporting documents, code samples, process descriptions, etc., linked in an organized fashion. For anyone who has had to just dig through a data room before, with no one to guide you through it; you know how much pain this saved. And when the consultants came to our office for the site visit and initial interview, I told them that I had prepared a small presentation, and asked if they would mind if we started off with that. They said ‘ok’, and for the rest of the day, I was in “presentation mode”. It felt great. We were able to get our story out the way we saw it. We would answer questions as they came up, take notes for action items, and then go right back to our storyline. It was a completely different experience from the first time: We were in control.
Ok, I know what you are probably thinking by now: “I don’t have time for all of that!”. Probably true. I’m certainly not saying that everyone should go this far to prepare for technical due diligence. If you’re a small team, without much technical debt, and well-architected infrastructure, you might just be fine. If your code reads like a book, and you rarely have to hot-fix production, you could just sail through.
You won’t know for sure, though, until that first time you’re in it. Even if everything is in order, if you are not mentally prepared for the pressure that can come with due diligence, it could appear that things are really not that great. Our attitude and composure during the last due diligence process was completely different from the first time, and that came through practice.
The advice I got, when I asked how to prepare the first time around, was:
“Don’t get defensive, and good luck!”
The first part was good advice, but doing it in practice is not that easy. When a smart and experienced person (technical due diligence is often done by a CTO or former CTO) starts asking you questions, it’s easy to get defensive. When they home in on flaws or potential issues, it’s just human nature to try to brush it over, or worse: hide it. (Even if you get away with that during the process, that could come back to haunt you later.) My point is this:
You should practice!
In case you’re wondering, we didn’t fail to sell the company 3 years ago because technical due diligence went off the rails. It had to do with the ability of the potential acquirer to integrate us into their organization. It just wasn’t a good fit. I’m glad, though, that it wasn’t because we messed up during diligence, but that does happen. When the sell-side team is not prepared, and request for information are being handled slower than they’re being generated, the buyer gets nervous. Generally, the longer it takes for a deal to close, the lower the chance that it will. I would not want to be responsible for the deal going bad.
Practicing the site visit / interview, or for example how you would answer questions about potential security breach, while on a call with a group of lawyers, is just a good idea, and it doesn’t have to take a lot of time. Having an outside person do a quick assessment of your technology and team, can be super-helpful too. It’s amazing how easily group-think can emerge within an organization; that outside perspective is invaluable. When a goal is important, and selling the company you built through hard work is probably one of those, you should practice the critical steps to getting there, as much as you can afford.
It would be careless not to.
