A few weeks back I published an article introducing the concept of technical due diligence, focusing on the basics:

• Understanding what a due diligence is

• The common terminology

• Understanding the underlying investment thesis

• How to approach different types of investments

If you missed it, shame on you, but nothing is lost.

You can catch up with a simple click.

How to Run a Technical Due Diligence? Sergio Visinoni · Feb 11 Read full story

Given the success of that first article¹, I decided to follow up with some more details on how to actually conduct a tech due diligence. What should you do once you have clarity on the investment thesis, and what is included in the scope?

Before we move on with the details, I have an important reminder for you.

Tomorrow, April 16th, at 5pm CEST, I'll hold an open session for the Sudo Make Me a CTO community. It’s an hour-long free session open to anyone who would like to see what the community looks like on the inside. There is already a good group of people who signed up for the event, but there is still room. Don't miss this opportunity to help accelerate your growth as a leader and as a person in these changing times. Claim your spot via this button.

Claim Your Seat!

Now, let’s go back behind the curtains of the Dark Data Room.

A quick recap

Before you go out and waste precious tokens², let me remind you what is going on here.

• Your company has started a process³ to potentially acquire another company.

• Someone, most likely the CEO, tricked you into signing an NDA.

• After signing it, you’ve been let in the small circle of people who know that what everyone is referring to as Arrakis is not a sci-fi guild but the codename for the potential acquisition project. Quite a big downer for the nerd you are⁴.

• To add insult to injury, you have been gifted with the responsibility of conducting the technical aspect of the DD process, i.e., you share a non-trivial part of responsibility for deciding whether to proceed with the deal. And a massive liability exists to ensure the integration is successful, should the deal be closed.

• Given that, according to the draconian terms in the NDA you signed, you’re not allowed to talk about the Arrakis project with anyone, not even your partner or kids, you frantically read the first article I published on the subject.

• You’re left wondering how exactly you’re supposed to handle it, and while you might have been cursing me for omitting those aspects from the original article, you’re holding your hope that this one will give you the keys to the realm.

I’m sorry to disappoint you: those keys don’t exist. The realm doesn’t exist either. In fact, tt’s not a realm. It’s a hostile land, full of predators, legal traps, and deadly obstacles. But there’s no need to abandon all hope as you're entering the Data Room.

Dante managed to go through the Inferno without a map, relying on his own mind, heart, and the caring oversight of his guide Virgilio.

Likewise, with some guidance I’m sure you’ll find a way out of the tar pit and will be able to confidently assess whether your company should make the investment and what that will represent for you and your team in terms of integration pains.

So, let’s get on with the journey. I’m sure you’ll enjoy it⁵.

The first steps

The first steps might feel daunting, but in reality they’re the easiest ones. You might feel you don’t know where to start, and you’re probably right. The good news: it doesn’t matter where you start. Just start somewhere. Pick one thread, be it organisational setup, technical stack, processes, metrics, or whatever. Eventually you’ll want to cover all those aspects (in more or less detail depending on the investment thesis), so don’t sweat it too much about the exact first step. Motion is more important than direction as a way to get started.

Now, chances are you’ll be asked to put together a series of requests or demands to be submitted to the target company. This is often called the Initial Request List, or IRL⁶.

You might want to do online research for more details on how to craft a perfect IRL⁷, but ultimately this boils down to a list of documents you’ll request from the seller/selling company. The main keyword here is initial, as this won’t be your last chance at requesting additional information. Otherwise it would be called something like Unique Request List, or Your Last Chance at Not Forgetting Anything You’ll Regret Forever, aka YLCNFAYRF.

You will have plenty of opportunities to discuss the content of the documents and request additional or complementary information as you make progress. Therefore do your best job but definitely do not aim for perfection, as that will likely slow down the whole process.

For a tech DD, a good IRL should include requests covering the following aspects:

• Organisational Setup The bare minimum should be the org chart clarifying reporting lines and team allocation. On top of that it’s a good practice to request information about roles and responsibilities across teams, breakdown of seniority levels and tenure, and interactions or interdependencies with other functions. Particularly with Product, Marketing, Operations and Sales.

• Technology Stack This is the most obvious part, I suppose. You want to get details about the infrastructure setup (cloud, on-prem, etc.), the high-level architecture, frameworks and languages used across the whole stack, a full inventory of owned platforms (websites, mobile apps, etc.), and so on and so forth. Later on you’ll want to get a sense of where the main sources of pain or inefficiency are, but in the IRL it’s enough to get a full map of the landscape you’re looking at. Chances are that your intuition and experience will tell you already where to investigate further, such as that old PHP framework or that Cassandra instance running in a closet.

• Processes It’s helpful to get a detailed sense of how software implementations are born and come to live. From the way the company sets priorities and goals to how they trickle down to product prioritisation and then how they go from idea to plan to code written to code running live in production. You will typically include questions covering different aspects of the end-to-end process, such as:

  • How are priorities set and who decides them?

  • What’s the journey of a project from a ticket to being live in production? Who are the people involved at each step of the process?

  • How do you integrate technical improvements with product improvements?

  I like to ask fairly open questions here, as the depth and quality of the answer are in themselves data points. I’ll get back to it in the next point.

• Operational Metrics Here, you want to really get a sense of two things. The first one is whether the team has a culture of using metrics as first-class citizens in the way they operate. The second one is to get a sense of what these metrics look like. That’s why I’m generally vague on the request and prefer very open questions such as:

  • Please provide the full set of key metrics used in the engineering department to measure impact of initiatives, quality of service and team’s effectiveness

  Rather than something very specific, such as uptime, DORA metrics and % of code written by AI⁸. The list of metrics and the way they are presented is a precious data point in and of itself. It tells you a lot about the maturity of the team. If all you get back is “this is our uptime, and this is our average velocity”, it will be a hint to dig deeper into engineering maturity later on⁹.

• Cybersecurity Here too your first need is to develop a sense of the maturity around the topic, rather than having a detailed list of all the open vulnerabilities. Ask the counterparty to provide details about the framework(s) they use to govern cybersecurity topics, the reports from their most recent audits/penetration tests, and a list of activities they’ve undertaken in the past 6-12 months in the space. You’re looking for signals that the company is taking the topic seriously and that the team is equipped to deal with it. And, of course, you want to know if you’re looking at a ticking time bomb, as that would be a clear red flag for the acquisition in most cases¹⁰.

• Costs This is another area where you want to get information at two levels. One is, obviously, how much money the technology organisation costs overall. You want to get all the costs, from salaries to licences, third parties, cloud bills, etc. Ideally broken down to a granular level. And the second signal you’re aiming for is regarding the maturity of the organisation when dealing with costs and FinOps-related activities: do they have clarity? Are they allocating costs in a way that makes sense? Are they generally on top of their spending? This is another case where asking them to provide budgets, forecasts and actuals as they’re using them in their day-to-day job is the best initial approach.

• Dependencies This aspect can vary significantly whether you’re looking at a standalone company or a subsidiary of a bigger group. In the former case, you’ll map out dependencies mainly in terms of third-party vendors offering services at various levels across the organisation: enterprise systems, third-party platforms, etc. But when the company is part of a bigger group, you’ll need to get a full map of all the internal dependencies: systems and services provided by the parent company that you’ll need to disconnect from and replace with alternative solutions if the deal is closed. In this second case, this becomes a critical area, as a big part of the effort to carve out the target company and integrate it with your systems will have to do with cutting ties with all these dependencies¹¹.

• Plans Last but not least, it’s important to get a sense of the biggest items the team has planned to work on in the upcoming six to twelve months. At this point you shouldn’t be surprised that this exercise too will provide signals on two levels. The obvious part is getting a sense of some of the work the team is already committed to doing, which will occupy significant resources during the months following the acquisition. Secondly, this view will provide insights into the team’s ability to plan for future investments, the rationale, and the overall roadmapping and planning process.

While you can always add more, I recommend finding a balance between being comprehensive and quickly initiating the process. Getting the data back from the selling company will take time, and the longer your initial list, the longer the waiting period before you start getting something to look at.

Now that you’re waiting for them to produce all the required documentation, you can start preparing for the next step.

The Middle-earth

If you thought coming up with the perfect IRL was hard, I have bad news for you: that was the easiest step. After all, you just had to come up with some well-thought-through questions. What happens after that, in Middle-earth, is what I consider the hardest part of the whole process.

Soon¹² after you’ve submitted the IRL, documents will start appearing in the Data Room. They will generally appear in sparse order, they’ll be often largely incomplete and will have a tendency to magically appear in batches on Friday afternoons. But that’s not the worst part of it.

The worst part is that as soon as you start digging into the documentation, you’ll observe a Cambrian explosion of new questions in your mind. That, and if you’re particularly unlucky, you’ll witness a significant increase in your average rate of WTF per minute¹³.

So, what are you supposed to do now? In essence, all you need to do is to make sense of the information you’re collecting and dive deeper in areas that feel unclear, challenging, messy or all of them at the same time.

This phase is messy and hard to distil in a series of steps. It often reminds me of the famous “How to Draw an Owl” meme

You’re somewhere in between those two steps, when stuff has to happen.

Even though there isn’t a ready-made recipe for this stage, some methodology can go a long way in helping you navigate it. These are a set of activities and approaches I recommend for survival.

• Distil the information into your own notes. Write down your observations, summarise and reprocess what you’re receiving. This will ensure you have a deeper understanding of the material¹⁴, and it will uncover gaps in understanding or in the data, which you’ll then promptly review with the target company.

• Collect all your questions and submit them to the selling party. Data Room software has support for submitting specific questions. Don’t be shy and use that. Ask all the questions needed for you to really understand the material. Make sure you prioritise them, especially in the initial phase when you’ll probably have a tonne of them.

• Organise deep dive sessions in which you’ll explore specific areas with the experts from the counterparty. As you process the material, some elements will emerge as worthy of your attention: complicated dependencies, team issues or areas of accumulated technical debts. These are good candidates for setting up dedicated deep-dive sessions aimed at providing a lot more details and nuance around them. Unless the process is in a rush, you should be OK with having multiple sessions as long as they provide clarity in murky areas.

• Start drafting your conclusions early on. Don’t wait until the end, but start very early in drafting your recommendation. Do not focus on the form; instead, take your notes and observations from the deep dive sessions and start organising them into categories. You can start with a simple traffic light system, making an inventory of each topic and indicating whether it’s in a green, yellow, or red state.

At some point you’ll either run out of time or questions to ask, and that’s a good moment to move into the final phase of the DD process.

Putting it all together

If you manage to come out alive from Middle-earth, I’m happy to confirm you’ve survived the hardest step of the DD process. Now you’re supposed to formalise all your findings in a final document, including your analysis and recommendation.

Different companies have different norms and standards for producing this closing document, but it will essentially include the following three elements.

Your Recommendation

The document will generally start with a synthetic appreciation from your side as to whether you recommend or discourage moving ahead with the deal. Generally speaking, lack of major red flags on the technology side will mean you’re not seeing reasons to oppose the deal. Conversely, if you found out that the company stores all passwords in clear text, has not upgraded a library in a decade, and the CTO tends to engage in pair programming while high on Adderall or ketamine¹⁵, your conclusion might be a clear and firm objection to the deal moving forward. Whether or not your opinion will be taken into consideration will depend on how much appetite there is for the deal in business terms, but at least you will have done your part.

After the opening recommendation, your document will usually include a detailed analysis.

Detailed Analysis

This is where you’ll provide an overview of your observations on the different dimensions you have evaluated: technical stack, organisation, processes, etc.

You can reuse your traffic light assessments from the working notes to group them by criticality areas or use thematic grouping. This part will serve as the rationale for the overall recommendation you put in the opening. Be detailed, as those details will become handy for you and your team when you’ll eventually proceed with the integration.

The last part is where you’ll see the most variance depending on the company you’re in and how the overall DD process has been set up. Regardless of the level of detail, you’ll be asked to include some information about how you’re planning to integrate the new acquisition into your company’s ecosystem.

High-Level Integration Plan

The level of detail here will vary significantly from company to company.

The bare minimum is to provide a directional indication of which systems will be kept as they are, which systems will be dropped, and which ones will require complete integration work to merge them with the existing systems in your company.

Depending on your context, this high-level classification might suffice, or you will be required to also provide more detailed effort and cost estimates. In some cases you’ll be required to estimate synergies too, i.e., cost savings that can be captured by deduplicating systems or teams¹⁶. If you have a choice, try not to err on the side of too many details, as, no matter how thorough your DD work has been, this is a stage in which you still have very limited context and data. Chances are most of the people who will be involved in doing the work do not know about the deal yet, meaning their perspectives and knowledge have not found their way into the plan yet.

A good idea is to give high-level coarse estimates and reserve the right to come up with detailed plans once the deal is closed, involving the relevant people from your team.

What’s next?

Unless further iterations are required, you’re probably done with the bulk of the DD work. But that doesn’t mean you’re done with preparing the deal and the transition. If, at the outset of the DD process, the transaction is aborted, then yes, you’re done, and you can go back to your normal life.

In the case where the deal is confirmed, then a new set of activities awaits you. But you must be tired now of all the efforts drawing that owl.

We’ll discuss the following steps in an upcoming article.

In the meantime, don’t forget that the April issue of Something Big Is Happening is coming out soon. If you don’t want to miss it, make sure to upgrade to the paid plan.

It helps immensely in securing my time for writing all the free content too.