Security in the M&A process: Have you done your technical due diligence?

Company acquisitions are common in the cyber security market. Whether you are attempting to bolster your strategic position or looking to acquire the best talent, chances are if you’re company is growing, you’ll find yourself on a deal team at some point.

In late 2015 Distil Networks began the process of acquiring managed security provider Scrape Sentry. As the business team worked through the nuances of purchasing a Swedish company, the technical team snapped into action. Before the deal could close, we needed to perform thorough technical due diligence to validate the assumed technical capabilities of the target company as well as identify any significant integration hurdles. The results of this process could directly impact deal terms, so it was critical to get right. Below outlines the process and considerations needed to move this initiative forward in the most effective and accurate manner.

The goal of technical due diligence: Trust but verify

Before anything else, it is important to establish the goal of due diligence. The goal is not to aggressively search for reasons to kill the deal. You would not be at this stage if there was not demonstrated value in the target company.

Instead, the goals of due diligence are to assess the following:

• Technical capabilities of the target product
• Technical capabilities of the target team
• Technical debt incurred by the target team
• Integration effort required – both product and team.

No company will have perfect marks – that’s reality. A helpful check is to think “how would my company fare in this process?” It’s important to scale expectations based on the maturity of the target company. Is the deal a two man pre-product acquihire or a multi-million dollar business unit acquisition?

Technical due diligence in five steps

Loosely speaking due diligence can be broken down into five steps:

• Establish a plan
• Architecture averview
• Perform code reviews
• Interview the developers
• Culture crash course
• Bonus – be respectful.

Step 1: Establish a plan

It’s critical to have a plan going into the diligence process. There are many areas that need exploration and time will be short. Pull together an itinerary with scheduled blocks designated for each task. Take copious notes while on the ground. This constant flow of information keeps the deal team in the loop, and later, it proves helpful for integration planning and tasking.

Share the plan with the acquiree ahead of time. Many of the items can be executed remotely. Having answers ahead of time helps keep on-site time focused on high value conversations rather than administrative overhead.

Sharing the plan also removes uncertainty from the process and helps put the acquiree at ease. Teams are nervous during this process. It’s best to reduce uncertainty so you can focus on product not nerves.

Step 2: Architectural overview

Start the diligence process with an architectural overview. This will provide a high level understanding of how the target product was constructed and provide insight into the team’s process. Treat this as a design review, question architectural and technology decisions, including the exploration of any explicit design trade-offs (e.g. space-time or performance-complexity).
This is a good time to discuss integration options. Identify the logical integration points between the two products as well as potential friction points.

Step 3: Perform code reviews

Once you understand the high level architecture, dive into the code. This will deepen your understanding of the target product and help forecast maintenance costs. Sit with the developer and review a system she owns. Ask her to show you how specific features were implemented. What is she most proud of? What areas need attention?

Apply standard code review practices to these sessions:

• Is the code easy to read, self documenting and well organized?
• What level of test coverage exists?
• Heuristic – would you want to maintain this code?

Step 4: Interview the developers

Assuming the deal closes, some or all of the target team will join your company. These potential hires need to be vetted like any other job candidate – technical aptitude, career aspirations, cultural alignment, etc. Fortunately diligence offers a unique interviewing opportunity – rather than the usual four hour stress test, you can see developers in their native environment solving real problems. Spend time with each developer. Pick a bug off the backlog and pair together. How do they approach the problem? What language and tools do they turn to? Have lengthy discussions about the product and other topics. Apply the Airport Test. Quality of work will be readily apparent.

Step 5: Culture crash course

Most integrations fail not because of technical reasons, but due to culture differences. This is an important area to explore during diligence. Trade war stories by sharing experiences that encapsulate the core principles of your company. Do you have alignment? Talk about hiring and what the target company searches for. Discuss how they handle transitioning people out. Apply the smell test to these conversations. It’s critical to get this part right.

Trust but verify, with respect

Technical vetting should be thorough and complete, but don’t overlook the human element. You’re dealing with real people and your process will have a direct impact on their livelihood. You have a job to do but you’re also a guest. Approach the process systematically and without compromise – but also with integrity, respect and an utter lack of hubris. Applied properly, this method will de-risk your deal and allow for a confident acquisition process.