Running a Technical Due Diligence: the Details
- Sergio Visinoni from Sudo Make Me a CTO <makemeacto@substack.com>
- Hidden Recipient <hidden@emailshot.io>
Running a Technical Due Diligence: the DetailsYou've read the previous article, and you have a better understanding of what's expected from you. But you have little to no idea about how to get there. No panic! This article is all about that!A few weeks back I published an article introducing the concept of technical due diligence, focusing on the basics:
If you missed it, shame on you, but nothing is lost. You can catch up with a simple click. 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. Now, let’s go back behind the curtains of the A quick recapBefore you go out and waste precious tokens², let me remind you what is going on here.
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 stepsThe 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:
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-earthIf 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.
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 togetherIf 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 RecommendationThe 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 AnalysisThis 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 PlanThe 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. 1 The measure of success is obviously the % of code written by AI. If you think this is nonsense, you’re absolutely right. 2 I don’t care about the intrinsic value of tokens, be it crypto tokens or AI tokens (and don’t get me started on how much the choice of the same world says about the underlying ethics), because there is none. I’m more worried about the energy cost associated with burning them, especially in a time of war around oil supply. 3 Sometimes with exclusivity, sometimes without. Don’t care about it for now. 4 Seriously, I'd love to know who is responsible for coming up with such weird names for M&A projects. 5 If not, complain with your CEO. I’m just a guide here. 6 Be prepared for people abusing acronyms you’ve never heard of. Feel free to play the novice and ask. And remember to answer kindly to such questions once you’ll no longer be the rookie. Be kind to your past self, we’ve all been there. 7 Yes, somewhere on this planet there exist people who come up with such exciting headlines for extremely boring concepts. I guess the lesson is that everything can be marketed. That, or maybe that AI has a point in trying to replace us all. 8 Where did I hear about that one again? 9 Like it happens in interviews, there is no point in asking very difficult questions just to prove you’re knowledgeable in an area. You’re not here to prove your worth. You’re here to learn about the company you’re looking into acquiring. Open questions followed by deep-dive enquiries are a lot better for that. 10 OK, part of me is not fully comfortable with that statement, for a clear reason. Sometimes DD processes serve the purpose of process theatre, providing an appearance of thoroughness to a decision that had already been taken ahead of the whole process. In such cases you might be told that you’ll just have to deal with whatever problems you identify, and please don’t make such a big deal of them. 11 If you’re already feeling miserable, hear me out. Most of the time such internal services are poorly documented or are managed by people you’re not allowed to talk to during the due diligence process—because of confidentiality—or have so many layers of legacy that even Indiana Jones would hesitate to pull them apart. But sometimes you are lucky and none of that is true. Sometimes. 12 or not. 13 If you’ve never heard about this metri, I won’t invest in your company. But you can fix the gap by checking out this famous comic. 14 Hence, I don’t recommend asking small, medium or large language models to do that on your behalf. 15 Any reference to FTX is purely intentional 16 Yes, synergies ’ can be a fancy name for indicating looming layoffs You're currently a free subscriber to Sudo Make Me a CTO. For the full experience, upgrade your subscription. |
Similar newsletters
There are other similar shared emails that you might be interested in:

