How to Prepare for a Technical Due Diligence
Conducting technical due diligence engagements on technology-enabled product companies is a key service AKF Partners provides to our clients. We have done literally hundreds of them over the years. Our technical due diligence checklist is one of the most visited pages on our site. What advice do we have to offer a company about to undergo a technical due diligence? Let’s walk through a few points.
Before the Engagement
AKF Partners asks for information in advance of the engagement – doing so makes the meeting (in person or virtual) more efficient. This is important since the timelines for the potential investor(s) are usually short and the engagement typically lasts 1 full day or several shorter remote sessions on consecutive days. The amount of information the due diligence target can provide will vary according to the size, tenure, and maturity of the company. We consider the stage of the target as part of the due diligence process and do not expect startups to provide as much documentation as a Fortune 500 company.
What do we ask for and why?
- Architectural diagrams depicting the software and infrastructure components of the products or services. A person speaking to the diagrams should be able to guide the audience through the flow of data for the entire transaction, from the customer to the persistence tier. Diagrams are the fastest way to convey how a tech stack works and identify potential strengths and weaknesses to be discussed during the engagement. The story of the product availability and scalability is largely told by the diagrams and discussion.
- Organizational chart for the technology team. This provides some insight into ratios amongst resource types (Developers, QA, Product Owners) and signals if the structure matches the PDLC methodology. Companies claiming to be Agile while having a functional structure will trigger some questions that a product aligned Agile organization would not. There is not a right or wrong answer, rather degrees of optimal alignment. The chart can also provide hints on whether the organization has a product focus, or a traditional IT mindset trying to create products.
- Technology team budgets for the previous 3 years, planned and actual. The budgets are primarily reviewed for unusual spend amounts or ratios that would trigger follow up questions. There are some industry norms for technology spend as a percentage of revenue. Unusual spend amounts for hosting, bandwidth, or software licensing and support could indicate issues to be explored.
- Product and Technology roadmaps for the previous 2 years and future year. Roadmaps help tell the story of company priorities as they morph, the ability of the engineering team to deliver value, and the interaction of product and technology priorities. Seeing technology needs (technical debt, maintenance, tech refresh) consistently de-emphasized in favor of product feature desires is a clue to dig deeper. Delaying technology needs for a defined term to shorten product TTM is a viable business decision. Delaying to the point where software is no longer supported by the OEM or open-source community is a risk and indicator of problems in the prioritization process. Additionally, companies touting their Agile methodology with firm dates on feature to be delivered 18 months out would trigger some questions. Iterative market discovery and firm release dates over a year out are strange bedfellows.
- Incident list for the previous 2 years, including customer impacting incidents, infrastructure failures, bugs found in production, and security incidents or breaches. This information helps tell the story of product availability, infrastructure reliability, product release effectiveness, operational processes and security posture. Obviously, a startup would not be expected to have this information. An established company should. Comparing the incident list to availability measures can at times create an uncomfortable moment for those attempting to pencil whip KPIs. An important take away is understanding what is being done to prevent incident recurrences, reduce impact, and shorten time to detect.
- Software and technology partner list. The types of software in use and the story behind their selection or decision to deprecate them provide insight into technology strategy. Software can also have a significant impact on the cost to scale infrastructure and operating margins. The degree of offshoring or outsourcing in use provides information of cost, but also the degree of alignment on shared outcomes.
During the engagement
Due diligence engagements are most effective when they are a conversation, not an IRS audit.
Thoughts to consider;
- Feel free to ask clarifying questions without being argumentative.
- Its ok to say you do not know. Ideally this would be followed by a commitment to check on the topic and get back to the questioner in a defined time.
- Add concise context to answers – understanding the situation when a choice was made improves understanding. Would you make the same choice today? If the answer is no, what changed?
- Ask for an explanation of an unfamiliar concept or rubric used during the session – better comprehension leads to better responses.
After the Engagement
AKF Partners provides our clients with a written report within a week of a technical due diligence engagement. This report belongs to our client and AKF Partners cannot share the report with the target – only the client can do that. If you are provided with the report, read through it with an open mind. Some of the findings may cause umbrage and discontent. Honestly ask yourself “are they right, or close to right?”. AKF Partners is always willing to review the report with the target with the client’s blessing. Some such discussion have led to training engagement to benefit the target.
What about code quality and spot checks?
A request we often field from clients is the quality of the target’s code. “Is their code good?”. We tend to discourage such requests as the value derived pales in comparison to the cost incurred.
Factors incenting the avoidance of code quality characterization;
- The target will carefully pick which code sections the offer up for analysis and review, potentially something newer and prettier than legacy code. Gaining access to the entire code base is extremely unlikely. Reviewing cherry picked code sections will not adequately characterize the code base.
- What makes code “good” or “bad”? These types of judgments tend to devolve into style points debates resembling sectarian arguments. Does the code do what it is supposed to do in the time and manner it is supposed to do it? Would the effort needed to make the code “better” yield enough business value? What else could engineers be working on and at what business value?
- Analyzing code repositories for cyclomatic complexity, average class and method size, and dependencies can provide useful information, but the cost of doing so starts in four figures and often runs into five figures. Is the information worth the cost?
The subjective quality of code can be easily overshadowed by other factors. Code so pretty it would make Alan Turing weep in admiration that is deployed as a monolith will be expensive to scale. Average code already segmented into independently hosted and released services will be easier to scale than a monolith.
Interested in learning more about the due diligence process and how the right partner can add value? Check out our services page. Buy side or sell side, AKF Partners can help.