How do you integrate teams after an acquisition when they don’t want to integrate?

After an acquisition, each team defends its territory, and each does it differently. Good integration doesn’t always mean breaking through that defense. Sometimes it’s enough to understand what each team is protecting, and agree with them on the interfaces. Here’s a story about two such teams, one in Germany and one in Iceland.

After an acquisition, one of the most dangerous signs isn’t a loud argument. It’s the moment both teams nod politely — and share nothing.

I was Chief Architect at the time. My task was to integrate the products of two acquired companies, one German and one Icelandic, into our core system.

An architect’s job seems clear enough: look at what stands on both banks, and build a bridge.

Except it quickly turned out that nobody on either bank was waiting for our bridges.

Both teams were afraid of roughly the same thing.

That we’d learn how their system worked, take the idea, and rewrite everything in the technologies we were used to. That we’d start telling them what to do and how. And that in the end we’d decide the people themselves were no longer needed.

This wasn’t my guess. In one-on-one conversations I heard different versions of exactly this fear, more than once.

But the two teams defended their territory in completely different ways.

The Germans opened the gates — but refused to move the walls.

Relations settled. They showed us the code.

“Look as much as you like. But our system stays the way it is. We’re not writing new APIs for you. And we’re not learning your technologies either.”

So we had to learn.

We figured out their rather ancient scripting stack and built our own translation layer between the systems. It was harder than we’d have liked.

But once the rules were set, the Germans kept to them very carefully. If they changed an API, they warned us and updated the script.

With the Icelanders it was the other way around.

There, the gates were shut.

Emails went unanswered for weeks. People came to our office in Israel, drank coffee, smiled — and managed to answer technical questions in a way that left us knowing about as much as before.

So I stopped trying to look over their wall.

Instead, I invited them to design the territory outside it, together with us. We were working on the architecture of a new system their product was supposed to become part of. Formally, they weren’t even developing that feature. But I brought them into all the architecture discussions.

They saw how decisions were made. They could argue. They could shape the future architecture.

They never let us inside their system. And it turned out we didn’t need to go in. Let it stay a black box.

We agreed on which doors that closed box should have. They built exactly the APIs the integration needed. Technically, this system turned out to be even easier to work with.

In the end, both systems became full parts of the larger company. Both integrations ran without failures.

We had to build one bridge from our side. For the other, we didn’t even need to cross the border — it was enough to agree together where the doors would be.

As Chief Architect, I could formally have required both teams to carry out the architecture decisions.

But you can’t implement architecture through a job description.

If people believe you’re building a bridge so you can come across it and tear down their house, they will defend the bank.

My job wasn’t to break that defense, but to understand what exactly each team was protecting — and to design the integration so the whole could work without destroying the autonomy of its parts.

After an acquisition, integration doesn’t have to mean unification. Sometimes good architecture starts with understanding which walls don’t need to come down at all.

Have you had cases where the best solution wasn’t to build a bridge, but to agree on doors?

If you’re dealing with an integration between teams that isn’t moving the way you planned, send me a message on LinkedIn.