The observation
Two years after an acquisition, the acquired business is still running its own systems, its own processes, its own reporting. The two organisations sit alongside each other more than they operate as one. The natural explanation is that integration was under-resourced — not enough people, time or budget allocated to the work of actually bringing the two businesses together, so it stalled somewhere along the way.
This explanation is intuitive because under-resourcing is a common and genuine cause of failed integration. It is also, on closer inspection, frequently not what actually happened. A different and more specific pattern is often visible instead: an integration plan exists, is well-documented, and is largely complete — on paper. What remains outstanding is a set of items each individually justified as needing the acquired business’s specific capability, systems or way of working to continue as-is, at least for now.
What leaders usually conclude
Under-resourcing is the default explanation partly because it is comfortable — it locates the problem in an allocation decision that can be revisited (more budget, more people, more time), rather than in a set of choices that were each, individually, reasonable at the time they were made. It is also sometimes accurate: genuine integration work is demanding, and organisations regularly underestimate what it requires.
But the exception-by-exception pattern is structurally different, and worth distinguishing, because the remedy is different too. Under-resourcing is fixed by allocating more resource. A pattern of individually reasonable exceptions accumulating into something close to non-integration is not fixed the same way, because no single exception, examined on its own, looks like a problem worth escalating. Each one has a specific, defensible reason: this system handles a regulatory requirement the group system doesn’t yet support; this process reflects a client relationship that predates the acquisition and would be disrupted by change; this reporting format is what the acquired team’s management actually needs to run the business day to day. None of these are unreasonable. The issue is that nobody ever assessed them together.
What the evidence suggests
Consider an organisation in exactly this position. The integration plan is substantially complete. What remains is a list of exceptions, each with its own sound rationale, that collectively amount to most of the acquired business’s operating model remaining untouched. Every exception was reasonable, and the aggregate effect of all of them together was never reviewed as a single question. Integration did not fail through a dramatic breakdown or an obvious resourcing shortfall. It failed by increments, each of which was formally approved.
This is a recognisable instance of a more general organisational blind spot: individually rational decisions, made by different people at different times without visibility into each other, can add up to an outcome that nobody would have chosen deliberately if it had been presented as a single decision. Nobody in this scenario decided the acquired business should remain substantially separate two years on. That outcome emerged from a sequence of narrower decisions, each defensible in isolation, that were never aggregated and re-examined as a whole.
The mechanism has a structural cause worth naming plainly, without dressing it as a formal finding: exception approval, in most organisations, happens locally and incrementally — a specific request is raised, a specific person or committee approves or declines it, and the process moves on to the next request. Almost no organisational process exists specifically to periodically step back and ask “what is the cumulative effect of every exception we have approved so far?” — because that question does not belong naturally to any single approval, only to the pattern across many of them, and patterns across many decisions are exactly the kind of thing that falls between the responsibilities of individual approvers.
There is a genuine tension underneath this that is worth naming rather than resolving too quickly. Forcing every exception to be revisited and potentially reversed carries real costs of its own — disruption to a working relationship, loss of capability that the exception was protecting, and a signal to the acquired business that its judgment about what genuinely needed to stay different is not trusted. Leaving every exception untouched indefinitely carries the opposite risk: an acquisition that, years later, still behaves as two organisations sharing a name, with duplicated systems, duplicated overhead and none of the coordination benefits the acquisition was originally intended to produce. The evidence does not point toward a rule for resolving every exception one way or the other. It points toward the narrower but still significant claim that the decision should be made deliberately, as a reviewed whole, rather than allowed to simply persist by default because no single exception was ever quite important enough to force the question.
Contextually, this pattern tends to be more pronounced the more genuinely different the acquired business is from the acquirer — different sector norms, different regulatory environment, different systems that are each individually hard to justify replacing quickly. It is less pronounced, though not absent, in acquisitions of closely similar businesses, where fewer exceptions have a strong independent justification in the first place. The size of the acquired business relative to the acquirer also matters: a small acquisition absorbed into a much larger organisation has less standing to accumulate exceptions, while a large or strategically significant acquisition often retains enough internal weight that its exceptions are taken seriously on their individual merits, which is precisely what allows them to accumulate.
Looking for your own sector? The Other Sectors page points to the closest match.
Questions worth considering
- Has the current list of approved integration exceptions ever been reviewed together, as a single question, rather than only individually as each was raised?
- If every remaining exception is individually reasonable, what would make the aggregate outcome unreasonable — and has anyone actually asked that question?
- Who, in this organisation, has visibility across all integration exceptions rather than only the ones relevant to their own function?
This perspective is part of Growth.
Your team is facing similar challenges?
Subscribe to The Riddle Ledger
Perspectives are sent as they are published, with no promotional email, and you can unsubscribe at any time.