Lessons from 100 technical due diligence processes

The Visma group is currently expanding at a rate of 50 companies a year. Before any deal is finalized, many types of due diligence are performed, including financial, commercial, legal, HR, and technical.

Visma has a core team who works full-time with M&A, but due to the federated structure of Visma and the diverse expertise required, quite a lot of people across Visma become involved in this work, like Managing Directors and different types of subject matter experts. In most technical due diligence processes, there are 2 to 6 participants from Visma, but in the overall M&A process there might be 15 to 30 people involved.

I participated in my first technical due diligence process back in 2017, and this week I participated in my 100th. I thought I would mark the occasion by summarizing some lessons learned.

Lesson 1: Selling Visma is easy and effective

In a job recruitment process, it's not only about evaluating the candidates critically, but just as importantly, you need to "sell" the position and your company to the candidates. Why should they want to work with you instead of someone else? What's in it for them?

Similarly, in an M&A process, it's always useful to give a good impression of Visma. Why would the company do better by joining the Visma group, and what can we offer the employees - our future colleagues?

The ability to collaborate with similar companies inside of Visma is super valuable, whether it's companies in the same domain, in the same geography, in the same customer segments, or something else. There is so much to learn and gain from simply exchanging experiences. New perspectives can be gained by benchmarking a new company against other Visma companies. Add opportunities for common commercial activities on top of that, and it's easy to see the value.

Similarly, the target companies we talk to are always excited to hear about Visma's Growth, Business and Tech Hubs - centralized teams that offer standardized tools and services and customized support and guidance in so many areas - from digital marketing to pricing and packaging, to security, product management and architecture. The Visma Hubs deliver a lot of value adding services and capabilities that smaller companies don't have - and can't afford to have on their own.

Finally, we have so many communities of practice where people can get together across companies to get new ideas and learn from each other whether it's?the Security Guild,?the Software Testing Guild,?the Product Management Academy,?the Product Development Architecture Board,?the AWS, Azure and GCP Forums,?or the dozens of other examples I could have used.

These really are the superpowers of Visma.

Lesson 2: Small companies are often struggling with security

I speculate why and offer some solutions in this talk?from Visma Sec Con 2021 and NDC Security 2022.

We ask companies about their security organization, processes, policies, certifications, etc. We also perform Static Application Security Testing (SAST) and Software Composition Analysis (SCA) in all technical due diligence processes. We drill into details to go beyond simply "security on paper" to get a sense of the actual security maturity of the organization and the security level of their product(s).

This is also an opportunity for us to show the strong Security Program we have in Visma, and how we can add value by guiding and helping them to improve their security a lot in a short amount of time. The feedback from the companies is always very good.

Lesson 3: The importance of clarifying common misunderstandings

Sometimes, companies prefer talking about their plans and a future state rather than today's situation. While both are interesting and important to our business case, we need to understand the costs and risks we potentially take on when a deal is signed. Plans can always change, so it's important to specifically ask about timelines, current progress and how things are right now.

Secondly, I would guesstimate that about 10% of people I meet in the technical due diligence process confuse single tenancy and multi tenancy, so I have learned to double check what they actually mean when it's not obvious. An easy way to remember:

• A multi-tenant system can handle multiple tenants = lots of people in the same building
• A single-tenant system can only handle a single tenant = each person needs a separate house

Confusing encryption and hashing is also common. Sometimes a company will say that they have encrypted user credentials in their web application, implying they could be decrypted (which would be bad). Usually they mean that they have hashed the passwords with a one-way hashing algorithm. But beware, once in a while maybe they actually mean encryption!

When in doubt, it's better to double check than to assume.

Lesson 4: Trust and transparency feed each other

Being evaluated, audited and "looked in the cards" by another company is not a daily occurrence for most people, and has the potential to be a stressful and uncomfortable experience. While we are interested in understanding the company's ability to execute and identify and understand any significant potential risks and costs to Visma, the M&A process itself and any potential onboarding to Visma goes much more smoothly if we act as future helpful colleagues, rather than critical auditors who think we know better and are looking for any simple mistake to "get" them.

I often try to lower expectations by being open about our own challenges and imperfections in Visma, and that we are very familiar with the prioritizations and trade offs that are done in most organizations. I will ask follow-up questions, but I never criticize. I may question a specific decision, but I will explain my thinking and stress that I don't have the same context as they do, and that I'm not an expert on their business.

This typically leads to more trust and openness on both sides.

One of the standard questions we ask all companies is: What do you consider your most significant technical debt?

Some companies say that they don't have any technical debt, which may sound like a good thing, but is actually the scariest answer of them all. Technical debt is unavoidable. So to me, this says that either the company is not aware of their technical debt, or they are aware, but they are not willing to tell us. If it's the first, it's easy to question their competence or culture, if it's the second; what else are they not telling us?

Luckily this is an extremely rare occurrence. Most of the time I meet excellent people who are super excited to talk tech. People who are proud of what they do, people who are excited to share their strengths, but not afraid to be honest about their weaknesses. I am extremely pleased to say that many of them are now my colleagues.