Every M&A press release promises the same thing. "Seamless" roadmap acceleration, instant "alignment", everything just works! You never see the version that says the new company now has four conflicting identity systems, three incompatible data models, and an engineer in Shanghai who is the only person on earth who knows how to run an over-stretched and under-resourced billing system.

In my experience, a lot of companies struggle after the deal closes. I’d say at least six out of ten. The tech stack often takes the blame, but the real issue is how we treat the people. We usually spend millions on brilliant negotiators to close the deal, and then hand the integration work to whoever happens to have free cycles on their calendar. And it's often too late.

At Unity, when we were pulling together more than a dozen acquisitions, we started the way most companies do: pick the “best” system, shut everything else down, and force everyone to migrate. (Btw, “best” doesn't always mean the best tech; depending on your environment it could be a proxy for the most influential pitch, the laziest option or the one with the most job security. Those debates are fun to watch!)

As someone new in the role at the time without a pre-existing bias, it was obvious to me that approach wasn’t going to cut it. None of the existing systems were built for that scale. The so-called strongest one hadn’t really been maintained in years, only a handful of people understood it, and had been patched over the years into an "everything, everywhere, all at once" system.

So instead of forcing a winner, we built something new. A shared cloud foundation that all teams, acquired and legacy, could move onto together. We did that while still keeping everything running (and in the middle of quarterly layoffs, which made it… interesting).

But the technical engineering was only half the battle. When you tell 17 distinct teams that none of their systems "won," you have to spend a lot of time listening. Our engineers spent time with actual users - not just other engineers, but the people ultimately using these systems - sales, marketing, support, legal, and some random dude in accounting, listening to what they actually needed and what they were terrified of losing. The platform we built reflected that feedback, which is why voluntary adoption happened faster than we expected. 

I often look at such inflection points as an opportunity to address ignored long term technical debt. Integration is a cultural problem with a technical component, not the other way around. 

If you want to make an acquisition work, the integration process should flow from the people who actually have to live with it. That means starting with their pain points, not your roadmap. It means resisting the urge to pick a single winning system, because the moment one team wins, the other 16 feel like they lost. And it means measuring success by voluntary adoption rather than forced migration. Forced compliance is not integration; it just creates resentment. (Someday I'll tell you about forced cloud migrations. Those are also fun).

At Unity, this meant not picking the strongest legacy stack, but building one for the future. Getting teams aligned around a shared future is what really decides whether a deal creates value or destroys it. If you haven't done that, you have failed at step 0.

So if you’re heading into an integration, it comes down to one question: are you building something together, or trying to force a square peg into a round hole because it looks like the easiest path?