Why coordination gets hard
A large organization is rarely one business. It is often several, each with its own customers, products, regulators and history. One unit may sell to consumers in a single country while another serves corporate clients in a dozen. Some units were built internally; others joined through acquisition and still carry their own systems and habits.
Business unit coordination is the work of getting these parts to cooperate without erasing the differences that make each one effective. The aim is usually not uniformity but enough common ground that the whole organization can report, buy, secure and plan sensibly. How much common ground is enough is a judgement call, and reasonable people disagree.
Start by sorting what actually needs to be common
A useful first step is to separate three categories:
- Must be common. Things where inconsistency creates legal, financial or security exposure for the whole group, such as how access is granted or how financial results are consolidated.
- Better if common. Things where sharing saves money or effort but local variation would not cause harm, such as some purchasing or routine back-office processing.
- Local by design. Things that depend on the unit’s market, customers or craft, such as product features or local service practices.
Many coordination problems come from treating everything as the first category. Others come from treating everything as the third, and then discovering that nobody can compare results or share a supplier.
Common coordination mechanisms
Organizations tend to combine several mechanisms rather than rely on one.
Shared standards. A small set of agreed rules, for example on data definitions, security baselines or reporting calendars. Standards work best when they are short, written plainly and explain why they exist. A long rulebook is often ignored.
Governance forums. A steering committee or council with representatives from each unit can settle cross-unit questions, agree priorities and resolve disputes. The risk is that forums become slow or dominated by the largest unit. Clear membership and agendas help, and the idea of a systems governance framework describes how roles, forums and decisions can fit together.
Decision rights. Writing down who decides what, and who must be consulted, prevents the same argument from recurring. Decision rights are often more valuable than any tool because they make escalation predictable.
Shared services. Pooling routine functions such as payroll or IT support can reduce duplication. A shared services model also shifts power: units become customers of a central team, and that team has to earn their trust.
Shared platforms with local configuration. One system, configured differently by unit within agreed limits. This gives consistent data while allowing local processes, though configuration can drift if it is not managed.
Networks of people. Informal links between unit leaders, specialists and process owners often do more day to day than formal structures. Regular contact lets people learn what others are doing before conflicts arise.
How much coordination is too much
More coordination is not automatically better. Each mechanism has a cost in meetings, approvals and waiting. Signs that coordination has become heavy include:
- Local managers routinely work around central processes because the official route is slow.
- Units spend more effort preparing for reviews than doing the work reviewed.
- Exceptions are the main way things get done, and nobody remembers why the rule exists.
- Decisions about small local matters are made far from the people affected.
Signs that it is too light include the opposite: several units buying the same service separately at different terms, group figures that cannot be reconciled, or a security incident in one unit that exposes others because standards were never agreed.
Handling exceptions deliberately
No set of standards fits every unit. A standards exception process lets a unit say “this does not work for us because…” and get a considered answer. A workable process usually records the reason, the risk accepted, who approved it, and when it will be reviewed. Without this, exceptions pile up silently and the standard loses meaning. With too many exceptions approved by default, the standard is not really a standard at all.
Balancing central direction with local input
Local input mechanisms are the counterweight to central control. Units that feel unheard tend to resist, delay or quietly diverge. Practical measures include:
- involving unit representatives when standards are drafted, not only when they are announced
- piloting changes in one willing unit before wider rollout
- publishing the reasoning behind decisions
- reviewing standards on a schedule so that outdated ones can be retired
Change resistance is often a signal about a real problem, such as a requirement that ignores a legitimate local need, rather than simple stubbornness. Listening carefully tends to improve the standard as well as the relationship.
When a different structure fits better
For some groups, tight coordination is the wrong aim. If units serve entirely different markets, share few customers and have little overlap in suppliers or systems, the benefits of common platforms may be small. A lighter model, in which the centre sets financial reporting and risk limits and leaves the rest to the units, can be more appropriate. Other groups use a federated approach with shared principles and local ownership.
There is no universal answer, and the balance can shift as the organization grows, divests or acquires. Reviewing coordination arrangements every so often, rather than assuming they are permanent, helps keep them proportionate to the actual risks and benefits.