Technical Due Diligence

Technical due diligence (TDD) is a process that aims to assess a company's technology capabilities prior to Merger & Acquisition (M&A). Below are several questions that TDD attempts to answer. Despite being somewhat generic, I find these questions very important for a successful M&A process.

• Are the claims made by the team about the technology accurate?

• Is the tech team competent and credible? Is the company mature enough and capable of executing on their tech roadmap?

• What are the tech strengths, weaknesses and risks of the company?

Oftentimes executive team members will make ambitious statements about proprietary algorithms, special people or data, so a VC may want to get an independent opinion about such claims.

I believe that TDD is a vital necessity and VC’s duty and responsibility to their own investors, rather than just a box to check. TDD helps investors to know what they are getting.

The rate of execution failures in startups is very high, yet many VCs skip TDD or just have some non-technical partners interviewing the company's CTO for a couple of hours. The fact that VCs are ready to put their and their investors’ money in some company without a proper TDD always surprised me. Especially, given the fact that in parallel the financial auditing of a company's books is usually a thorough and lengthy process. TDD establishes a more fact-based and realistic view of the company's technology and can help avoid a lot of surprises during the first board meeting after the investment. Moreover, TDD costs are usually by order of magnitude lower than the costs of the lawyers involved in any deal.

A fundamental part of TDD before doing any work is agreeing on the high-level goals of the assessment as well as on its size and length. 

In general, for seed round investments I will take a 1-2 hours meeting or a call with VCs I already have a relationship with for free, but for anything more serious I will commit a day of paid work. TDD can be potentially done remotely for a large seed or a Series A, and a few days, including an on-site visit, for Series B and anything bigger than that.

My typical TDD process includes:

1. Preliminary research into the company’s business and people.

2. Interviews with senior staff members, on-site or remotely.

3. In-depth overview of company’s technology and assets (made available by the company).

4. A “first impression” summary of each conversation throughout the process.

5. A final report detailing company’s technology and people.

Usually, the expected hours for TDD process are split into phone interviews, travel and on-site visits, summaries of findings, asset evaluation, reports, debrief, and follow-up on various questions, charge my usual hourly rate for actual work and expect all transportation and accommodation to be organized and paid for by the customer (VC).

Once an engagement letter, NDAs and other paperwork is signed, we can kick off the TDD process. Typically, I should be introduced to the CEO and the CTO, first. I will reply to the intro email with a thank you and an invitation to set 45 minutes or so for a chat. For remote due diligence we will set up a video call.

Sending me any material upfront is greatly appreciated as it makes the process and the conversation more efficient and useful for both parties.

During the calls I try to speak as little as possible and take a lot of notes. Then, I write up a quick summary of the most interesting findings in an e-mail to the VC. Ultimately the one question I am trying to answer is whether I would work for this CEO and CTO. I’ve been impressed by quite a few and it’s very inspiring to talk to bright, often younger and more ambitious entrepreneurs.

I always follow-up with a standard Thanks for taking the time for the call today, it was very

informative and educational. Please don’t hesitate to reach out if there’s anything I can be helpful with.

CEO

Things I look forward to hearing about and discussing:

• A very brief overview of the company

• The problem you’re trying to solve

• The solution and how that solution becomes a business

• What did you do before and how you ended up here?

• Your team and its history.

• How did your CTO end up in their current role?

• The role of technology in your company’s culture.

• Your view of company’s technical operation: strengths, weaknesses and risks.

CTO, VP of Engineering/Head of Engineering

A simple, well-functioning and transparent process is very important to the organization. It says a lot about the maturity of the company and its leaders. In the CTO interview I quickly dive into

technology so my list of topics to discuss differs from the ones mentioned in CEO Interview section. For larger companies with a number of Engineering leads I will pick my topics for discussion from the list below. After finalizing the agenda, I will circulate it in order to set the expectations in an email one or two days prior to the meeting.

Things I look forward to hearing about and discussing:

• The company you joined, the challenge as you saw it then, how you feel about it now, and what has changed.

• Your understanding of the problem the company is trying to solve, the solution you’re trying to implement and how that solution becomes a business.

• History of the company’s software and systems and how that is evolving.

• Developer and other workflows and processes.

• Infrastructure and architecture of your systems, including network, data, software and hardware systems, platforms and tools.

• Operations, COGS, budgets.

• Technology roadmap, plans and major initiatives.

• Your own team, people you rely on, general technical staffing, hiring, training, organization and plans around people.

• The relationship between the Engineering team and other teams.

• Company culture and the role technology plays in it.

• A personal view of your technical operation, weaknesses, strengths and risks.

I like to see the CTO and the VP of Engineering have their acts together and to send me a lot of information upfront, including links to internal documents that weren’t created yesterday for this specific due diligence process. And as with the CEO I take lots of notes during the conversation and gather highlights in an e-mail to the VC immediately after each interview.

The 3 most important questions I am trying to answer are the following.

• Would I trust this CTO or VP of Engineering with my own company?

• Do I respect the technical and organizational abilities of the technology leadership?

• Would I theoretically want to hire any of the technical people into my own Engineering team?

CPO, CMO and Heads of Product, Marketing and Design

When given the opportunity I like to spend time with other executives. These are likely to be the heads of Product, Marketing or Design, which are often the biggest areas of contention. The relationships between these teams are critical for the success of the company.

The 3 most important questions I am trying to answer are the following.

• Where are ideas born, how are requirements driven and how are they designed and turned into product features?

• What kind of relationships do the Product, Design, Marketing and Engineering organizations have and do they have respect for each-other?

• How technical are the non-technical organizations and do they understand and consider internal challenges of Engineering, such as technical debt?

Some companies provide me with read-only access to code and document repositories such as

GitHub or Confluence. This often requires some back-and-forth and not everyone agrees to show their source code (that’s a mistake in my opinion). Unless I was granted access to the source code, my assumption is that the software is the “ball of mud” quality typical to any startup.

Access to the assets such as source code is critical and without it the TDD is limited. However, absence of assets doesn’t make this process useless. An experienced technical evaluator will easily see holes in a technical story and ask all the right questions that will surface the biggest areas of risk.

During code review I am looking for consistency in implementation, open dialog about technical choices and issues, evidence of agile approaches, levels of quality, testing or clarity in documentation. I try to put myself in a shoes of a new team member being onboarded and think about how I would feel as a new team member. Finally, I seek evidence of the operational infrastructure of the product, the practices around deployment, security and monitoring.

The key questions I am trying to answer are as follows:

• Are processes, systems, collaboration and code at the level I would typically expect to see in a company at this stage?

• How much time the team spends on software maintenance vs. producing value for the customers of the company?

• Is the executive management over or under-selling its technical capabilities and are there solid foundations for any future growth?

The final report is a lengthy document that includes a summary of the technology developed by the company and its underlying infrastructure, technology advantages and risks, external dependencies, an evaluation of whether the technology is best in class and its future roadmap, a summary of the organization and the team’s technical credibility and capability across all product and technical areas, product quality and development process and the degree at which future plans seem viable.

I use the following structure.

Overview

A high-level overview of the process followed, the level of access provided, and the amount of time spent talking to people and evaluating assets (what I had to work with).

Objective

The purpose of the technology due diligence report, typically to determine whether the company is in a position to execute on its roadmap and objectives from the technology point of view, evaluate the software and hardware platform, determine technical debt, understand and uncover technical risks, highlight technical advantages and provide an independent evaluation of the team in place and its relationships within the larger company organization.

Executive Summary

A description of the business problem and typical technical challenges of such business. An end-to-end explanation of how the product works from the technical point of view, whether the proposed idea works, and a summary of the current state of the systems and people involved, including a take on senior leadership, its track record and current progress. The company in its context and time line, compared to other enterprises of similar size, scale and stage. A clear evaluation of confidence in the overall ability of the team.

The important takeaway from this section is whether this report will express a fairly high level of confidence in the team’s ability to continue delivering on the company’s product roadmap, while incrementally improving the underlying technology.

Technology Platform

A detailed overview of the current technology platform, architecture diagrams and as much detailed information as possible along with an evaluation of the system. The important takeaway from this section is whether the current system is messy or clean and whether it’s typical to see such a system at a startup in this stage.

An overview of the next technology platform iteration. The important takeaway for this section is whether the team has a clear idea of what to do next from the technology point of view.

Technology Organization

A walk-through of the organizational chart. The important takeaway for this section is whether the distribution of the team makes sense, whether the team is too small or too large, how the team grows, promotes, develops and hires and whether organizational plans seem reasonable.

Technology Collaboration

A deep dive into how the CEO and other teams collaborate with the technology organization, company culture around technology, where ideas are born, how they are turned into code and how they make it into the production used by customers. The important takeaway from this section is whether the team is standing in its own way to enable success.

Risks

Risks from the technology perspective. The takeaways from this section are the possible scenarios that would cause the organization to fail to execute and some basics, such as whether the code contains any polluting GPL-licensed software.

Conclusion

A recommendation on the overall solidity of the technology organization. The takeaways from the entire report include the level of risks and my personal confidence in the leadership team, based on the conversations and available data.