CTO Primer: Technical Due Diligence

I've taken part in a lot of technical due diligences. As both a member of the team undergoing the due diligence (12 times) and as a member of the team performing the due diligence (>150 times). These due diligences come in all shapes and sizes, and vary significantly depending on the type of investment, the stage in the subject companies lifecycle and the wants and whims of the particular investor or deal-team.

The goal of this post is to give CTOs and people at the companies subject to a technical due diligence an introduction, covering what to expect and giving some guidance on what you can prepare beforehand to make it as successful as possible.

The protagonists

There are several people who will be involved in doing a technical due diligence, representing both the investor and the subject company.

At a minimum, there will be a nominated person from the investor who'll be asking the questions and making any assessment (usually produced for the "deal team"). This person might be a full-time employee of the investor or a third-party consultant or advisor. They will ostensibly be an "expert" either broadly across technology (for example, an experienced CTO) or a specific expert in your companies' domain. For larger deals, there may be more than one person, each with their set of expertise.

From the subject companies side, it's best practice for one person to be the "point person" working the investor's expert. This is often the CTO, or another senior leader in technology. This person may be able to answer all the questions themselves, or they may provide an orchestration role, making sure the right experts within the company can answer the appropriate questions.

The outcome

The investor's expert will, when their questions have been answered to their satisfaction, produce some kind of "report" for the deal-team. This report could be as little as a short email or a several hundred-page report. Generally, the earlier the stage of the investment or the lower the dollar figure is, the less extensive the report is.

The report will likely contain a few key sections:

1. Observations. Facts and data about the subject company the expert has discovered.
2. Risks. Any risks they've uncovered during the due diligence.
3. Recommendations. Any measures they think should be put in place to mitigate risks.

It's very rare that an expert's report would say anything as explicit as "you shouldn't invest in this company", but they can frame serious risks for the deal-team to consider. Ultimately it's up to the deal team to weigh up the technical findings against all the other factors they're considering. The technical expert can think the deal team should run a mile from the company, but there are other compelling reasons to invest, for example.

It's very unlikely you, as the subject of the technical due diligence, will ever see this report or directly know its contents.

Occasionally, these experts are given explicit questions by the deal-team to answer, or concerns they might have to validate or disprove. They will very rarely share these directly with the subject company.

The process will vary by the stage of your business

A technical due diligence varies very significantly based on the stage of investment and the amount of money potentially being invested.

For example, the technical due diligence for $100k investment in a pre-product seed stage business will be orders of magnitude less than for a $500m Series D investment in a pre-IPO business. Surprisingly, this isn't always true, but it is for the majority of cases.

At early stages, the whole technical due diligence may be a single 60-minute video conference, at later stages it could be an intense, full-time, four-week exercise. As you might expect, the amount of preparation and the quality of materials expected is also significantly different.

They don't expect perfection

The biggest misunderstanding new CTOs have during this process is they think investors want to see perfection. They think they need the perfect answer for every question. They think they need to polish every turd. They need to "hide" every bit of technical debt. There's a habit of trying to paint the "rosiest" picture possible.

Don't do this. Investors aren't looking for this, and they always know when you're doing it (the person you're speaking to has likely done these dozens or hundreds of times before). It harms trust. They know as well as you do that technology is never perfect, imperfect decisions have to be made with incomplete data. There is rarely a link in an investor's mind between "perfect technology" and "successful company" in fact, they've likely seen some incredibly successful businesses whose technology is a nuclear garbage fire.

What they want to see is that you understand where the challenges are, that you're aware of them. They aim to know that you and your team have a reasonable chance of being to be able to solve them when they need to be solved. This is often why they spend time understanding who the people in the team are, do they trust that these specific people can solve these specific problems?

There are very rarely objectively "wrong" answers to any questions they ask you. They very likely won't think that way, and will try to have empathy for why decisions were made, and not just the outcome of those decisions.

As the stage or value of investment increases, you do get less leeway. They want better answers. They want to see evidence of change. Likewise, they set a higher bar.

What will they want to know?

There are plenty of context-specific things that might be part of a technical due diligence, but below I try to give a high-level list of things that are covered in most of these engagements. Your mileage may vary, but expect to cover all of these, at least superficially. I also try to lay out some assets you might consider producing to make this process easier.

Roadmap, strategy, and delivery

Quite a lot of time will spent on your roadmap, strategy, and delivery to understand what it is you're building and how you build it. There might be an overlap with a separate (but less common) "product due diligence".

It's unlikely to go into the deepest level detail, so a high-level summary is often sufficent. The reason for this is pretty straightforward, this "expert" is not an "expert" in your business so they're unlikely to be able to form valuable opinions at the detail level. They can comment at high-level and can certainly comment about how your roadmap is formed and executed against.

Example questions

• What is on your roadmap? In your opinion, what's the most important thing?
• How do you decide what to build? How do you prioritise?
• What timeframes do you plan against?
• What process do you use for building? What's the "workflow"? Who has which roles in that "workflow"?
• Who is responsible the roadmap? Who is accontable for it? Who is accountable for it's delivery?
• Is there a difference in how you roadmap "technical" vs "product" items? Is technical debt captured in the roadmap? Is it prioritised differently than anything else?
• How do you measure your teams' performance against this roadmap?
• What do you want to improve about this process?

Organisation, leadership, and people

These questions are about understanding the choices that have been made about how you organise your people and teams, the quality of people that work for you and how good you are at hiring. They'll tend to spend more time on senior people, sometimes asking for CVs.

Example questions

• How are your people/teams organised? How are they aligned to product/technology/capability?
• Who are your team? What are their skills? What are their backgrounds?
• How do you hire?
• Is everyone an FTE? Do you use contractors or outsourcers?
• How do you compensate people?
• How do you measure and improve performance?
• How do you onboard people? How long does it take?
• Are there any bottlenecks in your people/hiring processes?

Architecture and infrastructure

Expect to spend the majority of time on this subject. Unfortunatley, it's often quite hard to prepare all the artefacts in advance, as you can't tell where the person your working with will want to go deep, so expect this to be the area with the most churn.

Example questions

• Tell me about your architecture? How does it work internally? Can you provide specific examples of how $FEATURE flows through your system(s)?
• How is your software built?
• What technology do you use to build your software? Why did you make that choice? Is there any third-party/proprietary software used? How is it licensed?
• Where are you hosted?
• How do you do incident management and disaster recovery? Have you had any incidents?
• How do you do CI/CD? What is your SDLC?
• What tools do you use?
• How do you deploy? How often do you deploy?
• Do you have SLAs/SLOs? Do you meet them?
• How is performance defined? How do you measure it?
• How does operational cost scale?
• What are the barriers to scale? Where the system likely break?
• What changes do you want to make? Do you have technical debt?

Quality

This subject might be included as part of a wider technology discussion, but expect to be asked about how you ensure quality in your technology.

Example questions

• How do you ensure the quality of your code and products?
• Who owns "quality" in your team?
• What types of automated testing do you have?
• How do you measure quality?
• Do you track defects and rework?

Cybersecurity and Compliance

This subject is becoming more common, even in early-stage companies, as investors often see it as an existential threat to their investment.

Example questions

• What are your threat models?
• How do you mitigate your threat models?
• How is security handled in your org? Who owns security?
• What technical controls do you have in place to improve security?
• How do you test your security? Can you share pen tests reports?
• Are you under any regulatory or compliance obligations?
• Have you obtained any third-party audit compliance? SOC2 etc
• Have you had a security incident?
• How do think about "data compliance"? What type of data do you store? How do you use it? Where is it stored?

Software licensing and IP

This is a critical subject, and it's usually the one new CTOs spend the least time preparing and the one that needs the most time to get right. If you prepare anything before a technical due diligence, start here.

Example questions

• Who owns the IP for your product?
• Do you use any third-party tools to deliver your product? What contracts do you have in place for them?
• Are you licensing anyone else's IP?
• Is there any risk you know of that you infringe on anyone else's IP?
• How do you use open source? Do you use any code with copyleft licensing? How do you make sure you don't?

Corporate IT

This might not come up, depending on if the technology team owns this, but it's worth bearing in mind that someone will need to answer it.

Example questions

• What do you use for productivity software? Corporate chat? Video conferencing?
• Do you use SSO?
• How much do you pay for all these tools? What's your "cost per year per employee"?
• What laptops do you use? Do you own them? How are they managed? Do you have an MDM?

Stress and timing

These technical due diligences can be time-consuming and stressful, often requiring tight turnaround for answers to questions. You might also need to be several of them at once, each with subtly or radically different subjects and questions, which is why preparation can be so useful. Create documents beforehand, steer conversations and questions to answers you already have.

"I don't know, but let me come back to you with the answer" is always a better answer than trying to bullshit your way through an answer.