So you bought a tech company, now what?

So you found an acquisition target, put them through tech diligence, and closed the deal yesterday. 🎉CONGRATULATIONS 🎉!!!

Now what? Are you closing the old business down, integrating it, or letting it run as-is? What should you do with the diligence report now that it's done? There are a lot of new questions if this is your first rodeo, and even if it isn't, every company acquisition you preside over as a technology leader is in a different state and has simple and not-so-simple answers to these questions.

The first questions are really for the C-Suite, and you've probably already answered them by the time the deal closes:

• How is the acquired business going to be run (or closed down) post-acquisition?
• What was the market opportunity or risk that made acquiring the company attractive?

The first question tells you what playbook you're going to be running: run it as-is, integrate it, or close it down. The second one tells you what collapses out of your product roadmap.

Keeping it going

I'll cover the "shut it down" option in the next post on this subject. First let's talk about the case where the target continues under your company's banner. As soon as your acquisition announcement comes out, its customers are going to start asking:

• What is this going to do to the product?
• If I'm using both the target product and the company's product, is integration going to make my experience better or worse or the same?

Your customers are going to ask:

• Is this acquisition going to distract them from improving their core products?
• Am I going to see any benefit from this acquisition?

Depending on the user and their overall change-tolerance, there's a lot of anxiety hiding behind these questions, and you want to quell that immediately and drum up excitement in both user bases for the merger. Marketing will help with this immediately, but Product Development's follow-through will ultimately be the determining factor on both products' success and whether the two together are greater than the sum of their parts.

So where do you start?

The due diligence report is going to expose the glaring technical debt, and you will need to tackle the urgent work from that in time to avoid disaster, but except in extreme cases of tech debt or the relatively rare case of "nothing's changing about the product but the owner," the most important thing to do is start showing momentum on integration to those customers.

If you don't, then users will start to think about an exit strategy for the product. They'll assume that the marketing hype is just that, and that the new parent company isn't committed to it. In particular, if the product roadmap is thrown into disarray by fronloading everything the diligence brought up, most of the improvements you're making will be invisible to users. Their perception of your commitment to product won't match the work you're putting in. Cynicism is hard to recover from. If it's set in by the time you make a major new release it won't have the impact you want it to have and you'll do twice as much work releasing features that half the number of people will use.

Don't try to be creative. I know, hard right? You're reading this as a Product Manager or CTO or Engineer, and you want to lunge for the big vision you see for integration. Do that, but make it splash a year to 18 months from the acquisition announcement. The first things you ought to do are the things that will touch everyone and that will be the most obvious to them:

• Eliminate duplicate data entry.
• Eliminate redundant logins.
• Propagate profile information.
• Unify permission settings.
• Eliminate bounces to a home-screen or multiple browser tabs.
• Eliminate jarring switches between branding.
• If your target was struggling, make some much-requested improvements that got backburnered by their lack of resources.

Integration is as much a psychological exercise as a technical one. Some of these things may seem unimpressive and like they're really low-effort, but you're shaving complexity out of your user's day. For the people who have always used both products, they're going from double data entry to single. They effortlessly switch between applications. They don't have to remember two logins or go through four factors of authentication before they're fully able to do the job they opened your apps for to begin with.

In a very real sense, this is the technical debt that the diligence report will never tell you about. It's created immediately upon merger. You had one system and a simple workflow for getting users in, keeping them engaged, and getting their work done and now you've gone to two. Everything that's duplicated between the two systems that's intended to work the same way for the same people is tech debt, and it's highly impactful tech debt because it's either putting a burden on your support team or your users to manage it.

A little momentum goes a long way. Once you've established your commitment to the product you can start to tackle the more invisible tech debt. Keep the momentum up, but don't let the stuff in the diligence report fester.

People priorities.

How do you take two engineering cultures and make them into one? Honestly, it's more art than science. I can tell you what I did, but you might do it better or do something entirely different that works just as well. No two human relationships in the world are alike, and the same goes for relationships between groups of people.

BUT.

You're acquiring some number of people who are going blind into your company and engineering processes. This is your chance to review habits and practices on both sides and disrupt the unproductive ones. If you disrupt them in the right way, and make sure that everyone gets credit for the improvements you'll naturally start to build bonds between the teams.

You'll have new experts. Maybe you grab someone who knows Python better than anyone else on your team. Maybe you'll end up with a crack data scientist or AI guru that wasn't fully utilized on the other product. Maybe you'll be able to bolster your strongest engineer with a backup when they get a question or run into a bug that they're normally the last resort for.

All I'm really saying here is "identify opportunities and capitalize on them quickly." The longer that you go without actively trying to federate the teams, the more they'll have ingrained the habit of not talking to each other. You just want the teams to each each other as value-adds. The rest of the cross-collaboration will happen as a result of that naturally.

• Make your technical SMEs available to consult across teams.
• If you have a site-reliability or security team, get them intro-ed to the target's team early and have them help the new team clean up any tech debt that's affecting reliability or creating security risk.
• And of course there's always team-building exercises and on-sites (if you're a fully remote org). These may feel wishy-washy and hard to justify, but it's typically important to at least get a few key members together in person whom you think are likely to be bridge-builders as the two companies build a shared future.

People risks.

What I would say don't do is to force changes rather than foster them. A lot of people are tempted to do things like "put a seasoned engineer from the parent company's team onto the new team," which is likely to garner suspicion rather than foster collaboration. The same thing goes with "we use Spotify Squads here so you're all now squads." Without some experience with the parent company's engineering culture you're telling them to make a change they don't have context for, and it's going to feel forced and take twice as long to achieve.

The other thing not to do in my experience is hold off on staffing changes or cuts if you know you intend to do them. You've just shocked the whole target team by acquiring their company. If you run things for six months and then cut people it's going to feel like a judgement against the team and their product as a whole. And it's going to be two hits to morale, cohesion, and productivity instead of one. If your diligence report or revenue plan identify cuts that need to be made, make them. Work with the target company's leadership to make sure they're the right cuts, but don't "wait and see," or you'll simply hurt the people you want to keep.

Wrapping it up.

All in all, the job of post-acquisition is a balance of using the shock to your users and your product development teams to your best advantage, and mitigating the harmful effects of the shock. Rather than breaking ground on the grand vision for what the companies will achieve together, the first few months post-acquisition are all about building trust by showing momentum and commitment.