Preparing for an M&A: 5 Tips for VP of Engineering
Table of Contents
Over the years, I have been involved in several startups as a founder, advisor, and investor. I also had the good fortune of being part of a couple of acquisition processes.
When an acquisition offer is made, time is usually short to successfully complete the due diligence process. A lot is at stake, and the entire executive team must work around the clock to contribute to the successful completion of the process.
In many acquisitions, the technology represents a significant part of what is being acquired, and so the VP of Engineering is often required to respond to many of the software due diligence subjects and, as always, it is easier if all material is prepared in advance. The good news is that being ready and prepared is not difficult, and in fact being on top of these things will make you a better VP of Engineering, even if a due diligence process is not yet in your horizon.
I’ve divides my suggestions to 5 categories: Technical description, IP, people, process and your roadmap.
Technical Description
In the “How it Works” part you will be required to describe and document the technology, providing documentation such as architectural charts and scalability and performance indicators. In some cases, you will also be asked to compare your technology and product to that of the competitors’.
Suggestions: To prepare, you should archive documents such as product design documents, architectural descriptions that you have created over the years (e.g. for partners), API documentation, PoC results and operational metrics. You will be asked to describe the development and deployment environments and the tools used – for example programming languages, configuration management and build tools, open source components, and third-party tools and libraries, deployment and patch tools. Where relevant, you will need to show interoperability with common standards and integration with other products in your eco-system.
Security is very important for people these days, so document any security vulnerability scans and penetration tests that you have performed. For some areas, automated tools can collect this information for you and provide reports in a click when needed. Don’t forget to provide security assurances also with regard to the open source components in your code.
Scalability is also a key area, especially when acquiring startups that have not yet deployed their solution at very large customers. Make sure to keep the data of all empirical tests that your team has performed, e.g., in the selection of a specific component or library.
You will also have to provide a copy of all source code, but this is usually easy to provide and does not require preparation.
Intellectual Property
This is probably the second most important asset that the acquirer buys (after the team, of course). As part of the software due diligence, you will need to demonstrate the strength of your technology and barriers to entry. You will need to show patents that protect your IP, as well as the freedom to operate, i.e. that you are not infringing on the intellectual property of others. You will also be required to provide a list of third-party components used in your software, including both open source components and commercial libraries, and of course that you are complying with their licensing requirements and pay royalties where due.
Suggestions: To prepare, keep full documentation of your own patents, as well as patent searches that demonstrate freedom to operate. Track the open source components used by your team, including all dependencies, licenses, and source, and be prepared to demonstrate compliance. For third-party components, keep the agreements and payment documentation.
People
Smart acquirers know that the strength of a software company is primarily in its team. You will be asked to provide an organizational chart with roles and to highlight key players. You will also be asked about contractors and outsourced skills. Some acquirers can be more or less concerned about people that work from home.
Suggestions: To prepare, keep an updated org-chart. Keep the resumes of all employees and contractors, and their employment agreements. Maintain a list of people and their skills, matched against the different parts of your product, and against development, maintenance, operations and support roles.
Processes
In this part of the software due diligence, you will need to provide details on the development, quality assurance, and security testing, as well as deployment, operations, and support processes. You will be asked to demonstrate that your processes are effective, cost-efficient and that they are suitable for the continued development of your products. You will need to demonstrate that they provide adequate support to your customers, salesforce, and others interest holders.
Suggestions: To prepare, document each process, including the people involved, resources, costs, and timetable. Keep all MRD/PRD documents that you have created and implemented. Where possible, use automated systems to track each of these processes (e.g. bug tracking, quality assurance). Track and be ready to report performance parameters such as time to release a new version, time to respond to a support request, and time to fix a major bug or security vulnerability.
Roadmap
Until the point of acquisition, you will most likely have only realized part of your grand development plan. The acquirer would want to know about your future plans and which new products and features you deem more important.
Suggestions: Maintain a document with release history and future planned versions of your products. Document all roadmap options that were considered by the company, and an analysis that shows which ones are more strategic for you, more desired by your customers, more or less difficult to execute, etc. This is also the place to provide any PRD/MRD documents for future product directions. Keep a wish list of features requested by your customers.
Being Proactive is The Key To a Successful Software Due Diligence Process
As I have already alluded to, I recommend that many software due diligence deliverables be continuously collected during the ordinary course of business. This will reduce the time it takes to complete the due diligence process, and the effort and pressure involved. More importantly, early attention to these management practices will allow you to be proactive and reduce actual risks to the actual acquisition. Where possible, I recommend that you deploy automated tools to continuously track various processes and metrics. This will help you in the day-to-day management and will allow you to produce due diligence reports quickly and easily when you need them. Many of these modern tools are now available in an easy-to-deploy-and-use and very affordable SaaS form and integrate directly to your development and operations environments.
