So You Wanna Buy a Tech Company

I've run the tech side of the M&A playbook now I think 10 times. I want to talk to fellow tech executives who are looking at acquiring a company about tech diligence and what it's for.

In 2021 we bought a 30 acre hobby farm. Our house was built in 1947, and it was maintained largely by DIYers for the last quarter century. When we had our home inspection done it wasn't to decide whether or not to buy the house, but to lay out for us clearly what work would likely need to be done, and to help us prioritize it. The well needed replaced. The basement needed shored up in one place. The heating system memorably involved a heat pump, an electric emergency coil, a heating-oil switchover, and a wood burning furnace.

But ultimately, we bought the house. The inspection was important, but it didn't carry much weight with us in terms of whether to buy. It just helped us understand what the purchase implied about where our money was going to go in improvements.

As the technical executive running diligence – whether you do it yourself or you contract it out to a company that specializes in it – what you're ultimately doing is the same thing. You need to know how to get the new acquisition incorporated cleanly and quickly and at what cost.

So then, if not "whether to buy," what do you want out of tech diligence?

• An assessment of the technical strengths, debt, and risk.
• A orderly plan for incorporating the team and the technology post-acquisition.
• A clear understanding of the likely costs to budgets and timelines of the above.

That's it. It's not about whether you're going to buy that house that comes with the 30 acres, mature walnut grove, and spring-fed pond. Diligence is about strategy. And honestly? I don't think most people really understand that. It's about being able to hit the ground running as soon as the deal closes.

In the series of blog posts starting with So You Wanna Buy a Tech Company, I will develop deep-dives on the different aspects of technical diligence and what the CTO and parent, and target tech team's roles are in them.

But first I want to spend the rest of this post talking about how to get your money's worth out of tech diligence. I'm going to talk about what kinds of questions to ask, and how to build those three bullet points above.

Building a Post-Merger Plan with Tech Diligence

Okay, first thing's first. There is an occasion where you tell your fellow executives to run screaming. It's possible for a company to be so underwater technically that they're teetering on the precipice of disaster and inviting that company into your organization will drag you down with them. But it's unlikely.

Most of what can go wrong after acquisition boils down to poor planning or poorly set expectations. Regarding expectations, the second goal of technical diligence is to introduce the target team to the culture, and to the way engineering leadership thinks about building, and how they lead.

Before I continue, it's of utmost importance that you're open and nonjudgemental throughout your interactions with the tech and product teams. And it's important that you do interact, even if you've hired an outside firm for the diligence work. They need to get a feel for your company, and you need to see how their team is reacting to the prospect of working with you.

With that out of the way, let's talk about how you make a plan.

Product

Something that almost never gets covered in tech diligence is unwanted overlap or redundancy. When you buy a company and don't kill their product, there will be some announcement from marketing that "Company X is excited to join the Y family of products!" This implies integration to customers, and they will expect it. What will that integration take to achieve?

There's a big emotional component to this. It's less important that the guts of your product are seamlessly integrated than that your customers get the experience of integration in a timely fashion.

Determine what constitutes the experience of integration, and develop a plan for it. Use your tech diligence people to ask questions like:

• How is auth handled? Do they support SSO?
• How are profiles stored and updated?
• Are there "conflict-prone" resources of the user that the product keeps track of that our product also does, like calendar appointments?

In general, scarce or conflict-prone resources are things about the customer's experience that can come into conflict between your product and your acquisition target's product.

The important things to make customers feel like the acquisition was of value to them are

• Avoiding double entry
• Avoiding conflicts between systems
• Giving them a clear choice of which product to open.

The quicker you reduce redundancy and confusion, the faster you get to added value. You should also be careful when you take features away from the target product and direct people into your own. It should feel natural and not be something someone has to remember. Also, they won't want to lose history from the product with the lost feature.

You should talk to their product team about their vision for integration. How they're thinking about this will tell you a lot about how they're going to work with the rest of your team. Then talk to the tech diligence team about that vision and brainstorm questions to ask to figure out feasibility, horizon, and cost.

Technology

Every piece of software has tech debt. If the tech team tells you theirs doesn't that tells you a lot about them. Ask them to define what tech debt means to them, as well. I have another post which talks about tech debt in-depth, and their own definition ought to align with it on some level. The more their view of debt aligns with aesthetics and trends and the less impactful it is on business the more direct leadership they will need.

Mainly your job here is to get the tech team to talk about their debt, give you their gut impressions of impact and priority, and to get them comfortable with the idea that you're not judging them for doing what was necessary to get their business to where it is.

The important thing here isn't so much that there might be "gotchas" like AGPL licenses or production data on Dropbox, but that you find them and have a plan to do something about them.

At a high level you need to understand:

• How and where their software is deployed.
• How resources with an ongoing cost are divided between customers.
• The basic ongoing cost profile per customer, commonly called Cost of Goods Sold or COGS.
• How customers receive updates, and whether there are special customers with leverage over the update process.
• Whether there are looming deadlines that pose a significant risk to the software.
• How the tech team develops software. That is, their SDLC.

There are clearly other details you need, and I'll go over this top in depth in another post, but at a high level this is what I consider the most important take-away.

Security

Most of the time you'll be acquiring a company that's significantly smaller than you. They're at an earlier stage in their journey, and as such they will have security risks you've already mitigated. You want to ask yourself and your tech diligence folks, "If we incorporate their technology, will it materially impact our security posture or certifications?" You don't need them to be perfect, but you do need to know how far off they are from your own standards. A very non-exhaustive list of good things to understand are:

• Do their code repositories contain private keys or passwords?
• How is tenancy handled?
• Do they keep dependencies up to date?
• Do they review CVEs regularly on the tech they use?
• Where all does PII end up? Ask the hard questions here, because people do do things like put PII in application logs, even though they shouldn't.
• Are they externally or self-certified for SOC2?
• If they deal with specially classified data (e.g. health or education or data about EU citizens) what level of compliance do they maintain? They need to have a non hand-wavy answer about FERPA, HIPAA, GDPR, etc.

A lot of acquisitions will have a "bring things up to standards" period immediately post-merge where they cannot release new features or provide any evidence to customers of integration with your products. You want to know how long this period will be so you can inform customer and your colleagues' expectations. To get at that, what you're really after is:

• What are the remedies needed to get them up to our standards?
• Is their tech team capable of implementing them, or do we need to pull resources?
• What is the priority order to mitigate critical vulnerabilities to our preexisting business if we incorporate them?
• What is the likely cost of that to timelines and budgets?

Team

When you acquire the company, you acquire the team. Its trust issues in its own leadership, in your leadership, its overall sentiment and culture. The size, strength, independence, and makeup of the team gives you your strategy for incorporating them. Diligence here is about determining that and about first impressions.

You're not (likely) up front deciding who you're going to keep and who you're going to lose. That puts the cart before the horse. You want an incorporation strategy first and foremost.

• Are there people with ridiculously high "bus factor?"
• Who are the people on your team who are most natural partners for the leadership post-merger? E.g. are they reporting to you or is there a director that you think is a great fit to work with them?
• Is the team excited about this opportunity or worried. No really, what do you think the balance is there? Are there detractors who hate your company or the whole idea that their product might not "win?"
• Does the target tech team trust their own leaders?

And here alone, more than answering questions you have, it's more important to establish trust. They're going through a big change, and you and your fellow executives are the architects of that change. They need a sense that they're participating in that plan and that it's not being made for them. They need to get a feel for what's likely to happen on day 1, 30, 60, 90, and forward. Does their product have a trajectory or is it likely to be sunset? You don't have to tell them, but they're going to walk away with a theory anyway, so it's best if you establish trust and rapport early.

This is the most important part, but it's also the part I have the least advice for. It's not because I don't have an opinion but because the questions you have to ask are so culture and team dependent. You should work with your diligence folks to get the facts about the team and use your impressions to create questions that the get answered. But it's all going to be highly dependent on whether you're acquiring a couple of founders or a 50-person tech team, and what the state of their culture is.

Your overall goals, though don't change.

• You need a plan to pair your leadership with theirs.
• You need a way to gauge whether the merge is progressing well down the road.
• You need a set of strategies to employ if it needs to be brought on track.

Wrapping up

This doesn't go half into the detail I'd like it to and it's still probably too long. In future posts on this subject, I'm going go into detail about each of the subjects and talk about what I look for, what questions I've asked in the past, and what my experiences have been good and bad in incorporating companies into the fold. I'm not going to give horror stories. There's plenty of clickbait on the internet for that if you want it. But I can talk about what mistakes I've made and what I think I'd do again.

I love the process of technical diligence. I love meeting new teams, talking about cool technology, and figuring out how to make the best marriage out of two companies on a course for greatness. If you'd like to talk to me in depth about this, send me a note and we'll set something up!