Technical Due Diligence: Did We Get It Right
Technical Due Diligence: Did We get it Right?
AKF Partners have performed 100s of technical due diligence engagements on behalf of strategic investors, private equity, venture capitalists and others. As such, we have amassed a significant repository of data, of patterns and anti-patterns, and the personal characteristics of successful and unsuccessful executive teams. Moreover, our teams have been on the “other side” of the table countless times as executives for companies being acquired or looking to acquire.
It’s not rare, however, when a potential client asks: how accurate is your technical due diligence? How can I trust that 8 hours with a company is enough to evaluate their technology stack? We love this question!
Due diligence, whether financial or technical is about assessing the risk the investor or acquirer is taking on by investing money into a company. It’s less about trying to identify and measure every gap and more about understanding where significant gaps exist relative to the investment thesis, calculating the risk to which those gaps expose the investor, and estimating the cost of closing the most critical gaps.
Due diligence is remarkably similar to playing poker: not any one player at the table has complete information about the cards remaining in the deck and the cards held by each player. Great poker players combine an ability to calculate probability nearly instantly with respect to the possible combination of cards as well as an ability to read the other players; looking for “tells” that inform the player as to whether their opponent is bluffing or playing with a pair of Aces heading into the “flop.” Great poker players seamlessly combine science and art.
At AKF, we’ve developed a formal checklist of questions around which we build our due diligence practice. In the big picture, this includes evaluating People, Technology, and Process. Our experience suggests that companies cannot build the right technology without the right people in charge, with the right individual contributors displaying the right behaviors to maximize success. Further, building reliable performance and predictable scalability (process, in other words) is of little value if they’re built on top of a weak technology stack.
People >> Technology >> Process
Read more about technical due diligence and AKF Partners here.
So how do we know we’re right?
First and foremost we need to understand the backgrounds, responsibilities and behaviors of the team present in the room with us. A dominate CEO that answers even the most technical questions, shutting out the rest of the team, is a red flag. We might ask specific questions to others and ask the CEO to let us listen to what others at the table have to say. If we’re still road-blocked, then our assessment will be very specific about the behavior of the CEO and we might ask for additional time without the CEO present. Another red flag: a CTO answering a technical question while the VP of Engineering’s face turns purple; an engineering manager choking a piece of paper to death while listening to the CTO review architectural principles or a senior leader refusing eye contact. . . the list of cues is nearly endless. We’ve seen all of them.
Seeing red flags early in an engagement is wonderful, and it allows us time to adjust the agenda on the fly. If we’re hearing something that sounds implausible, we will focus on the area in question and fire off repeated questions. Nothing helps like asking the same question three times in three different ways at three different times during an engagement. We can then judge the quality of the answers by the variety of answers.
Everything is Perfect
The biggest red flag of all: when things are too good. No down time; the architecture scales across all three axes of the AKF Scalability cube without human interaction; obscure or bleeding-edge technologies implemented without significant issues, and, most of all, always on time/under budget. Each of these red flags highlights an area that begs for further digging. This is a good time to start asking for real data. Let’s see the logs in real-time; demonstrate that 2-factor works as described and let’s watch a build. This is a good time to get familiar with Benford’s Law which states “in many naturally occurring collections of numbers, the leading significant digit is likely to be small.” Math is useful here just as it was for Bernie Madoff and just as it is for the poker player seeing a 5th Ace being dealt.
Assessments with significantly dysfunctional teams are a little easier and our assessments reflect this by candidly reporting that we could not validate certain facts or statements due to these dysfunctions. Either we come back and dig more deeply or we meet with a different group of people with the investor.
The Truth about Broken Things
While we occasionally see these anti-patterns, we’re much more likely to see positive patterns:
- A leader that is capable of expressing a vision and behavioral standards (a.k.a. culture) and then seeing the echoes of those standards from more junior members of the team. Huge green flag – maybe even a checkered flag for the finish line.
- Finding flaws in the architecture and watching the technical team members finally see the flaw themselves and begin to energetically discuss ways to resolve the flaws.
- A willingness to listen to different ideas and a recognition that the technology team may not have all of the answers.
Example: Dozens of times we’ve heard teams say their monolithic database is fine, peak load is 10%, no worries here. But there is no answer for how to handle a 10x event that will take the database down. There are plenty of examples of surprise 10x events: think of serving ads online when a famous singer or actor suddenly dies.
A willingness to admit that such a possibility exists coupled with a desire to build load generating tools and capacity planning processes is another green flag. Properly building these tools and then designing a credible scalability plan will absolutely reduce future operation risks. Those are critical cues we’re looking for during a due diligence session.
The best green flag of all: “I don’t know.” This is not an admission of failure, this is an admission of the fact that our systems are so complex, it’s impossible for a single person to understand all of the dependencies. “I don’t know” followed by “let me go get someone who does know” is one of the biggest green flags we see. “I don’t know” is a green flag – “I always know” (hubris) is a red flag. We seek teams that seek truth – not stories.
An important dimension to explore is the maturity of the company versus other companies in their industry as well as other companies of their size and age compared against the universe of companies. A company of 10 people that has invested significant time focusing on scale has likely not spent enough time building out a product with the necessary features to capture the market. A private company that has existed for 15 years with > $100M in sales but has no capability to perform capacity planning has underinvested in architecture. We’ve seen companies in all stages of maturity and size and our data helps structure our diligence recommendations: we can compare virtually any company against our universe of experience.
Technical due diligence is not about calculating a risk number to 6 digits of precision. It’s not just science, and it’s not just art: it’s both. The art is in ensuring alignment of people, process and technology - particularly the people component. The science is in applying a data set garnered over 11 years to help identify where the largest issues do (or are likely) to exist. The end result is a report that outlines risks and plausible solutions written by a team of people who’ve had a combined 200 years experience doing the real work.
RELATED CONTENT
- Technical Due Diligence Checklists
- Technical Due Diligence and Debt
- Security Considerations for Technical Due Diligence
- Managing Risk with Technical Due Diligence
- The Dos and Don’ts of Technical Due Diligence
- Technical Due Diligence