Why organizations reverse course
Centralizing a function is often presented as a one-way journey, but many organizations move back. The reasons are usually practical rather than ideological. A central team that once made sense may have grown slow, lost touch with local needs, or become a bottleneck as the organization changed. Decentralization reversal is the deliberate return of some or all control to units.
Reversal is not an admission of failure. Conditions change: a business enters new markets, acquires differently run companies, or finds that the original case for consolidation no longer holds. Revisiting the decision is part of sensible governance.
Reasons to consider it
Several signals may suggest that handing control back is worth discussing. Typical signals include:
- Units regularly work around the central function.
- Requests take long enough to cost real business.
- Standard solutions fit some units badly.
- The central team has become hard to staff or has lost expertise.
- The benefits expected from centralization were not realized, or have faded.
Before deciding, check whether the cause is the model itself or how it is run. A slow central team might need more resources or a better process rather than dissolution. Decentralizing a function that is simply under-resourced can move the problem rather than solve it.
Remember why it was centralized
The original reasons for centralizing are the best guide to what could go wrong. If the function was consolidated because of inconsistent data, duplicated cost or weak controls, those problems may return when control passes back. Write down the original motives, then ask for each one: does it still apply, and how will we deal with it after the change?
This protects against the most common mistake, which is swinging fully back to the previous arrangement and rediscovering every old problem.
Decide what to keep shared
Reversal does not have to be total. Many organizations hand over decisions and operations but retain a thin shared layer. Candidates for staying shared include:
- Standards that others depend on. Common data definitions, security baselines and reporting formats.
- Platforms with real scale benefits. Where separate versions would cost more and add little.
- Specialist skills. Scarce expertise that units can draw on.
- Controls with wide consequences. Areas where one unit’s failure affects the rest. Seek advice from qualified security, legal and compliance professionals here.
- Contracts. Where combined buying brings real advantage.
The result often looks like a hybrid or federated design rather than a return to pure independence.
Plan the transition
A staged approach lowers the risk of disruption.
- Define the target. Describe which decisions, systems and staff will move, and which will stay. Agree decision rights in writing.
- Check readiness. Each unit needs the people, skills and budget to take on what it is receiving. A unit without them may need support or may be better served by staying central for now.
- Pilot with willing units. Starting with one or two units shows what needs fixing before the rest follow.
- Transfer knowledge. Documented procedures and handover time prevent expertise from disappearing with the central team.
- Handle systems carefully. If a shared system is to be split or retired, treat it as a proper migration, with testing and a way to go back if needed.
- Keep communication open. People in the central team may worry about their roles, and units may worry about the extra load. Honest, regular updates matter, and organizational change management applies in both directions.
Avoiding the old problems
The aim is to gain local control without losing what centralization fixed. Some practical safeguards:
- Minimum standards. Agree a short list of requirements every unit must meet.
- Shared definitions. Keep key data terms common so that reporting still adds up.
- Visibility. Maintain a simple way to see what each unit is running, so duplication and risks are noticed.
- Regular review. Check at set intervals whether the new arrangement is working, and adjust.
- Exception routes. Allow units to raise issues and request changes to shared rules.
- Clear accountability. Each decentralized function needs a named owner locally.
Measuring whether it worked
Compare outcomes against a performance baseline taken before the change, using measures that reflect the reasons for the reversal: speed of response, local satisfaction, cost and consistency. Expect some adjustment time, since results can look worse before they improve as units learn new responsibilities.
Be prepared for mixed results. Some functions may thrive when returned to units, while others may show the old problems quickly. In that case, moving one function back toward the center is a sensible correction and not a contradiction. The organization is learning which functions suit which model.
A caution on cost
Decentralizing is not free. Units may need to hire, buy tools or train staff, and the organization may lose economies of scale. Estimate these costs honestly beforehand. If the costs seem to outweigh the benefits, a partial change or a service-style arrangement, where the center keeps running a function but under tighter local influence, may achieve most of what units want at lower cost.