You have to be a special kind of person to enjoy reading or writing Technology Due Diligences in the context of Mergers and Acquisitions. I find many of them to be rather generic, always pondering about the same set of standard issues. They are summarized, put away in a folder and never touched again. Their potential value – wasted 😢. The major reason in my opinion? People are treating Technology Due Diligences – as Engineering DDs. They are looking at how software is developed – rather than why, missing an integral part of the big picture in the process. Let me elaborate.
The True Purpose of a Tech Due Diligence
A technology due diligence in an acquisition context serves the following main purposes:
- Ensuring the technology organization is actually capable of fulfilling the role envisioned in the buying company’s investment hypothesis. To give an example: if the acquired company is mainly intended to fill a technology gap for the buying company with one particular product – then the Tech DD should primarily focus on this part of the asset and making sure it has the expected features, quality and maturity – while other products that are intended to be retired after the acquisition do not need to be looked at thoroughly. The topic of having a good and clearly spelled out investment hypothesis is so important that it deserves a separate treatment in a later post.
- Identifying risks for the buy-side. This ensures they don’t acquire assets (companies in this context) that contain substantial risks, leading to unforeseen correction/mitigation efforts or even write-offs from the asset’s value. It also prevents overpaying for such assets.
- Improving the buy-side’s position for final negotiations. Insights uncovered in Tech DDs can be leveraged by the buyer to negotiate a lower price for the asset, based on identified risks.
Of course, there are more of those – but those are the ones that I usually find most relevant. The mistake starts by having the Tech DD created by a company who may be specialized in delivering engineering services – but lacks specific expertise in the field that the acquired company is active in. This company will then focus on the engineering organization, assess the processes and find things like:
- The target does not perfectly execute agile methodologies
- They don’t pay enough attention to quality control and their automated test coverage is poor
- Roles in the organization are not sufficiently well defined
And many more in this direction, you get the point. None of which are surprising for small or growing companies when they are acquired. And none of which are helping with the above stated purposes too much – or are they?
Why Industry-Specific Expertise Matters
What is often not identified are the specific risks that the acquired company has to deal with in their product portfolio. For the area I am most familiar with, technology for commercial fleets, this could be risks around:
- Specific legislation impacting the products. While generic violations of GDPR rules are typically scrutinized (as all tech companies operating in Europe are subject to them), only an expert in the field will look at how a fleet management solution adheres to specific regulations for their market. This includes laws around working times for drivers in Europe (e.g., tachograph-related legislation) or preparing for newer regulations like the EU mobility package. How is the target solution addressing these legislative challenges? Rules and regulations can significantly aid in selling a solution if a company adheres to them correctly. Conversely, missing them can severely impact market performance. Wouldn’t you want to know as a buyer if you are acquiring a champion in this space – or rather a follower which is always late to the party?
- Is the roadmap setting the right priorities – or are there gaps in the product portfolio that limit the ability to deliver on the investment hypothesis? Are there current trends in the industry that the acquisition target should be addressing – but isn’t? In the fleet management space, if a company does not have a solution for e.g. trailer tracking or also video telematics at least in the works – this should be spotted and highlighted by a Tech DD. Questions should be asked to understand why and how those gaps are not addressed – and if this can be fixed, if needed.
- Are there industry-specific risks that should be taken care of? One example in the fleet management space: solutions often utilize numerous location-based technologies such as map-matching, forward- and reverse geocoding or the consumption of map tiles in general. All of these come with certain vendor-specific restrictions on what users can or cannot do with them – and their associated costs. It is very easy to make mistakes in this space – or to take short-cuts that are violating the terms of the location-based service providers. Those mistakes can become costly quickly and heavily impact the business case of an acquired company – so it is crucial to identify those early.
The Bigger Picture: Beyond Engineering
Once again, the key takeaway is clear – the topics highlighted extend beyond general technology use. They are highly specific to the industry in which the target operates. It is a major mistake and wasted potential to treat a Tech DD as a generic engineering exercise, while forgetting to look at the specific risks and opportunity that come from being active in a specific market. Technology is much more than engineering in this context – you need to look at the whole R&D-organization including product management and the products themselves, rather than just at the engineering processes and risks associated with them. And that ultimately means it also pays to involve individuals in those exercises who know the market, products and their specific challenges – experts in the industry and the technology commonly employed within it. They are harder to find for sure – but will make sure you get a Tech DD in return that a buyer can and will actually use for the long term – rather than merely shelving it.
