Technical Due Diligence

From the beginning there is a temptation to treat the assessor as hostile. It’s quite often the case that the assessor is seen as being someone who can sink the deal. It’s simply not the case. The assessor is not looking for reasons to kill the deal, they are looking for reasons to say yes to the investor.

It’s common for the assessor to have been in the entrepreneur’s position and therefore understand the level of anxiety that the investigation will be generating around the company. That understanding and the first-hand experience of the challenges and realities of running a start-up will ensure both empathy and realistic point of view that nothing will be perfect under scrutiny.

Ultimately the assessor works for the VC and must report honestly and accurately about any deficiencies or concerns made visible during the investigation. Not to do so would put the assessor at risk of a lawsuit for being negligent in the event the deal is completed and something that should have been highlighted wasn’t and subsequently causes a loss to the investor.

Whereas being able to answer questions in detail about your business and how it works is critical, there is also a secondary set of factors about how you engage with those questions, think quickly and how well you deal with the overall process. These give insight into the human behind the business opposed to just seeing the business as a series of process based interactions.

The primary purpose of the assessment is to evaluate four key aspects of the business from a technical standpoint. Vision, Scalability, Maintainability and Continuity.

Vision

The company was (probably) founded by someone with a vision. A future for the tech and for the company. The first question then should be does that vision still exist, how is it described, is it road-mapped and what does that future look like.

• Sometimes the ownership of the technical vision has been transferred and the responsibility is with someone other than the founder.


• Does the company’s management share the same vision of the where the tech is taking them?


• Does the vision make commercial sense and can it be correlated with other parts of the tech
spectrum?

The quality of the leadership within the company is critical. Every successful tech company has someone at the head of the organisation with a real vision for the technology. The assessment needs to show and understand how well (or not) that leadership is working.

Diversity is another key indicator. If the entire leadership of the company comes from essentially the same personality types, then the company will become one dimensional. Business leaders, technology types and others must combine to give a complete outlook on delivering the companies vision.

Sample questions around the company’s technical vision might include:

• Do you have a clear road map for where you want the product to be in one month, six months?


• What is your recruitment ratio for technical staff? How many interviews does it take to find a new recruit?


• What is the employee turnover for the company on a yearly basis and what factors do you attribute that turnover to?


• Do you look to recruit people you know from previous jobs? If not, why not?


• Are you using Cohort Analysis or some other methodology for user feedback and testing?


• What is the product tempo? How many releases or update every month/quarter/ year?


• What are the number 1, 2 and 3 concerns over the current product or service?


• What is the recruitment process in detail (How many stages? Code tests?)

Scale

This would seem obvious at first glance but getting a tech business to scale effectively can be more difficult than just adding more servers or connectivity. There is some science, some methodology and even some philosophy that needs to come together to make a business scale in a frictionless way.

Sample questions on scaling might include:

Maintain

There are a number of concerns that an investor will have over any tech acquisition when it comes to the existing tech.

• Will the existing staff depart once the company has changed hands, meaning that all the experience is leaving the business?


• Will new staff joining the company just find a mess of spaghetti code that takes months or even years to understand?


• Has any documentation been created in a meaningful way that will support the continued development process?

One of the common issues is that these questions are answered differently by the business types running the company versus the technical types involved in the tech creation process. The assessment must clarify the issues around the existing code base and what will happen when the team attempts to write new code by new team members.

These sample questions seem like common sense but they still do form the basis of an investigators basic train of thought:

• Do you use any form of source/version control and if so, which one and why?


• Do you build/check-in on a formal timetable - daily, weekly, whenever?


• Do you insist comments on check-in?


• Do you use Continuous Integration or create unit tests?


• Do you have formal code reviews?


• What development methodology do you use and why?


• Can you deploy a build to staging or production with a single click?


• Do you have dedicated and qualified testers?


• When do you deploy?


• Does the software automatically notify you of errors?


• Do you have a bug tracking system?


• Could you walk me through some code if required?


• How many defects did you close last month?


• How many open defects are there?

Continuity

Continuity is essentially about disaster recovery, back up plans and contingencies. If we assume that everything runs as we would like and does so forever, then we’re setting ourselves up for a fall.
There are digital failures to assess. What happens if your data centre goes off line, if a server fails or if connectivity is lost?

There are physical disasters to understand. What happens if the building floods, the power to the building fails or the building burns down overnight?

Disaster recovery planning within most tech businesses is weak and is frequently cited as a concern in technical due diligence reports.

Typical questions around continuity are:

• Do you have a documented and tested Disaster Recovery plan?


• Do you have a documented and tested Business Continuity Plan?


• Is there any part of the product or system that is understood by only a single person?


• Is your Version Control system backed up, where, how often?


• If the Database Server exploded how much client data would be unrecoverable?


• If there was a fire at the Data Centre how much client data would be unrecoverable?


• Do your staff have laptops and if so how is data and applications secured on them?

Closing Summary

An experienced assessor will start each new assessment with a framework of points or questions and then use their experience to start to focus down on key areas dependent on what responses they are getting. The best ones will be able to think on their feet and drive the investigation on a case by case basis.

Hopefully this article will give you a starting point to think about how you can prepare for the due diligence process before being face to face with an assessor and feeling under pressure.