Why Multi-Location Businesses Struggle With Consistency

Why It Happens

The coordination need the meeting originally addressed was caused by a temporary staffing gap that no longer exists. But over eighteen months, the two teams have built real dependencies on information the meeting provides — information that is not available anywhere else in the organisation’s systems. A temporary mechanism has become load-bearing. Removing it now would cause genuine disruption, even though the original justification for it is gone.

This is a distinctive way that multi-location consistency erodes. It does not require anyone to deviate from a standard on purpose. A location introduces a locally sensible, temporary fix. The fix works. Time passes, and the organisation’s other systems and processes quietly adjust around the fix’s continued existence, rather than the fix being folded back into, or reconciled against, whatever the standard process was meant to be. By the time anyone asks whether the fix is still needed, the honest answer is complicated: the original reason for it is gone, but a new, genuine dependency has grown in its place, and that dependency is now real, whether or not it was ever officially decided that it should be. Jay Galbraith’s 1974 paper in Interfaces, “Organization Design: An Information Processing View,” describes lateral relations as one way organisations cope with rising information-processing demands. A meeting that carries information available nowhere else is doing that work, whether or not anyone planned it.

Multiplied across several locations, each of which may have developed its own temporary fixes for its own temporary reasons, this produces exactly the pattern multi-location businesses recognise as an inconsistency problem — sites operating differently from one another — even though no single decision to diverge was ever taken anywhere. Each site simply adapted locally, and those local adaptations became structural in different, uncoordinated ways.

This connects to a broader consequence worth naming directly: the cost of reconciling this kind of divergence rises considerably with time, and rises faster than the divergence itself. In the first few months after a local fix takes hold, reversing it or reconciling it with a shared standard is relatively straightforward, because few genuine dependencies have yet formed around it. Eighteen months later, as in the example above, reconciliation is a fundamentally different and more disruptive undertaking, because real operational dependencies have grown up around the fix in the meantime. This creates a difficult asymmetry: the earlier a divergence is caught, the cheaper it is to address, and yet the early stage is exactly when a locally sensible fix looks least like a problem worth addressing — it looks, correctly at the time, like a good local decision.

A further misconception is worth naming here: multi-location consistency is often treated as though it were primarily a communication problem — sites simply need to be told, more clearly or more often, what the standard is. The pattern described above suggests the more persistent driver is not a communication gap about the standard, but a structural one: each site facing its own local conditions, each adapting sensibly to them, with no shared mechanism for reconciling those adaptations against each other before they become entrenched.

This also varies by how visible a given site’s local adaptation is to the rest of the organisation. A fix introduced at a site that reports regularly and in detail to the centre tends to surface relatively quickly, even if it is not immediately understood as a divergence. A fix introduced at a more autonomous or less closely monitored site can persist for considerably longer before anyone outside that site is even aware it exists, which means the true scale of accumulated divergence across a multi-location business is often larger than any single central report would suggest.