Merging Frontend Teams Without Breaking Them

The conversation that started this whole initiative wasn't about architecture. It was about duplication — specifically, several teams across the company maintaining effectively the same frontend, built with slightly different choices, owned by groups that had grown up independently and had little reason to talk to each other.

The business case for consolidation was obvious. The human case was not.

The resistance was real

Most teams don't love being told that what they've built needs to be merged into something else. Even when the rationale is sound, the instinct is defensive: our way works, the other team's approach is messier, this is going to slow us down. That's not unreasonable — these teams had shipped real things, had opinions forged from experience, and weren't wrong that consolidation carries risk.

What I've learned is that the moment you treat this as a purely technical problem, you've already made it harder. You can produce the most well-reasoned tech strategy in the world, but if the teams who have to execute it don't feel ownership over it, the implementation will be slow, half-hearted, or quietly subverted. Not out of malice — just out of the natural friction that comes from having something imposed rather than decided.

So before we talked seriously about architecture, we talked to people.

Making space for the real conversations

The approach we took was to use structured workshop formats to give every affected team a seat at the table. Not a feedback round where decisions had already been made — actual working sessions where the direction was genuinely still open.

In practice, this meant bringing representatives from each team together to map out what existed, what was working, what wasn't, and what everyone was worried about. We were explicit that there was no predetermined answer. That built credibility. People showed up differently when they believed their input would actually shape the outcome, rather than just being documented before a decision landed from above.

We ran alignment sessions where teams could challenge each other's assumptions directly — which occasionally got uncomfortable, but produced better results than any steering committee would have. The goal wasn't harmony. It was a shared understanding of the constraints and trade-offs, so that when a technical direction was eventually proposed, the reasoning was legible to everyone who had been in the room.

The result was a common technical strategy that all the involved teams were genuinely motivated to tackle. That last part matters more than it sounds.

The technical decision followed from the constraints

Once you have a coalition of teams with real skin in the game, the architectural conversation changes. The question shifts from "what's the best technical solution?" to "what can we actually execute together, across teams, without stopping everything else we're doing?"

That framing led us naturally to a micro-frontend strategy. Not because it's fashionable, but because it was the only approach that fit the reality: multiple teams, distributed across locations, each with ongoing product commitments, none of whom could dedicate six months to a big-bang migration.

Micro-frontends allowed us to merge the applications iteratively. Teams could contribute incrementally, applying the shared approach to new features or defined areas of their codebase while continuing other work. Synergies became available almost immediately — a shared component didn't have to wait for a full merger to be useful. And no single team carried the whole migration burden, which was important for keeping people engaged over what was going to be a long-running effort.

What actually made it work

Looking back, the thing that mattered most wasn't the choice of architecture. Micro-frontends solved the delivery problem, but the strategy would have stalled at the first real conflict if the teams hadn't trusted each other and the process.

The workshops were the lever. They were slower than just deciding and announcing. They required facilitating real disagreements rather than smoothing them over. But they produced something a top-down mandate cannot: people who felt they had made the decision and were fully committed to the plan.