I have worked on integrations across public companies, private companies, and PE-backed portfolios. Part 1 covered what breaks. This one covers what separates the integrations that move from the ones that stall.

The difference isn't effort. Every team I've worked with is working hard. The difference is a small number of structural choices, made early, that either give people something to move against or leave them to fight the same battles over and over.

Every integration has at least one dependency that isn't really a dependency. It's a wall.

On one integration I worked on, a technology development decision kept getting bumped, not because anyone disputed its importance, but because something else always looked more urgent that sprint. It slipped once, then again, then again. By the time anyone stepped back to look at the pattern, the date had moved a full quarter.

The fix wasn't a harder push to finish the blocking item faster. It was making the cost of delay visible. Every workstream touching that decision got mapped against it two ways: T-minus, the days of work that had to happen before it resolved, and T-plus, the days of work that could only start after. When the blocker's date moved, the T-minus and T-plus dates moved with it, automatically, instead of the team re-litigating the schedule every time.

Some of those T-plus dependencies had hard external deadlines that didn't care when the blocker cleared. That's what made the discipline necessary instead of academic.

The real unlock wasn't the math. It was that prioritization decisions stopped being arguments and started being visible tradeoffs. When someone wanted to bump the blocking item again, the question wasn't "is this important." It was "here's what moves if we do." That's a harder conversation to win by just being the loudest person in the room.

Every integration announces a philosophy on day one. It usually sounds like "best of both worlds."

On one integration, one organization was roughly eight times the size of the other in revenue and scale of operations. The outcome of "whose way of operating wins" was not actually in question. Anyone looking at the numbers could see it. But leadership never said that out loud. Instead, the team went through the motions of "best of both worlds" as if it were a live decision, meeting after meeting, long after the math had already answered the question.

The cost wasn't the missing announcement. It was what happened underneath it. With no guiding principle at the top, every smaller decision had to fight its own battle from scratch. Naming conventions. Approval processes. Reporting formats. None of these had a default to fall back on, because the one decision that would have set the default was never actually made. So each one became its own debate, argued on its own merits, by people who had no way to know which way it was supposed to go.

Fast integrations skip this. Not because the size-based answer is always right. Because naming the guiding principle early, even an uncomfortable one, gives every smaller decision something to resolve against. "The acquirer's system wins by default unless there's a specific reason to deviate" is a sentence that saves a hundred meetings. "We're combining the best of both" is a sentence that creates a hundred of them.

The team doesn't need the size-based answer to feel good. They need it to be clear enough that they stop having to relitigate it every time a smaller decision comes up.

Co-leadership sounds like fairness. In practice, it's a tax.

On one integration, leadership appointed one person from each side to "co-lead" the effort, an extension of the same instinct that produced "best of both worlds" everywhere else. It read as balanced. What it actually did was turn every decision into a discussion that needed two people to agree, instead of one person who could hear the input and make the call.

The work didn't disappear. It just moved into meetings. Instead of someone presenting a recommendation to a single accountable owner and getting a yes or no, decisions got worked out in committee, in real time, with everyone in the room. Meetings got longer. More of them got added. The actual work of the integration kept losing time to the work of deciding who agreed with what.

None of this was anyone's fault. Co-leads weren't dragging their feet. They were doing exactly what the structure asked of them: consult each other, find alignment, move forward together. But alignment-by-committee is slow by design, even when everyone involved is competent and well-intentioned. The bottleneck wasn't the people. It was the structure that required two people to move in lockstep before anything could move at all.

Fast integrations make a different bet. One name owns the outcome. Other stakeholders get a voice, not a veto. That person is trusted to weigh the input and decide, which means decisions get made in the time it takes to walk someone through a recommendation, not the time it takes to get two schedules and two sets of priorities into the same room.

Every integration wants speed. Leadership asks for it, boards expect it, and most playbooks treat a shorter timeline as the win condition on its own.

A 2004 study in the European Management Journal pushed back on that assumption. Speed's benefit in M&A integration isn't automatic. It depends on what the organization is actually optimizing for, and whether getting there fast came at the cost of something else that mattered (Angwin, "Speed in M&A Integration: The First 100 Days," European Management Journal, 2004). An integration that hits its date but guts employee sentiment or damages the client experience along the way hasn't actually won.

Speed is one goal. It's rarely the only one. Employee sentiment, before and after the integration, is a goal. Client experience through the transition is a goal. Minimizing operational fallout while two organizations rewire how they work is a goal. These goals compete with each other constantly. Moving faster on a system cutover might protect the timeline and damage client experience in the same week.

The problem isn't having multiple goals. It's leaving them unstated. When the Integration Management Office doesn't know which goals take priority over which, every tradeoff gets decided in the moment, by whoever is in the room, based on whatever feels most urgent that day. That's how a well-intentioned team ends up moving fast in the wrong direction.

Fast integrations name the goals and their priority order before the work starts, not as a values slide but as a decision filter. When speed and client experience conflict on a specific call, the IMO already knows which one wins, because someone decided that before the conflict showed up instead of during it.

None of these four patterns are complicated. Map the real blocker. Name who wins. Name one owner. Name the goals in order. What's hard isn't understanding them. It's making the call early enough that it actually helps, instead of after the meetings have already piled up.

Part 3 covers what PE sponsors consistently get wrong in integrations, and what works instead. Subscribe to EDSO Edge so you don't miss it.

Ready to assess your integration readiness before the friction starts? Schedule a discovery conversation at edso-edge.com