Subsidiarity
People close to the work need the power and support to make the decisions they understand best.
Let the smallest group that can handle a decision well make it, then move it up only when it affects others or needs shared support.
Waiting for approval from someone with less context
There's a particular frustration in being closest to a problem, knowing what needs to happen, and still waiting for approval from someone further away.
Moving every decision upward can look like control and feel like distrust. Pushing everything downward can be equally careless when local teams receive responsibility without information, capability or support.
Subsidiarity sits between those failures. Keep a decision with the smallest group that can handle it well. Move it up when it affects other groups, creates a shared risk or needs skills and support the local group does not have.
Decide what stays local and what stays shared
Keep local: Country teams choose the steps people go through when signing up, support hours and local payment language because they understand their market and live with the result.
Hold in common: A central team owns security rules, financial checks, identity and the basic systems every country depends on.
Escalate when: A local choice affects another country, changes a shared system, or creates risk beyond the local team's authority.
The central team still needs to give local teams the information, tools and safety rules they need, plus a way to challenge a bad call from the centre.
The decision moves when the consequence moves
In government, a local institution can adapt because it sees the problem and lives with the result. The decision needs to move upward when it affects rights, public money, defence or another region. The hard part is showing that the effect really reaches beyond the local boundary, rather than taking control because the centre prefers it.
Software teams face the same tension. A team should decide what happens inside the part of the product it runs, while login, security and system monitoring may need shared rules because one local failure can affect everyone. A team that maintains the shared technical systems becomes a problem when it takes product decisions without the context those decisions need.
Healthcare and education show why being closest is not enough. The professional near a patient or student knows things a central policy cannot capture, but shared safety and fairness rules still protect people from harmful local choices. Local authority needs skill, evidence and a way to appeal, not only permission.
A quick ownership test
Ask:
- Who has the best context?
- Who lives with the consequence?
- Which effects spill across the boundary?
- What capability or protection must the centre provide?
Are local teams coordinated enough to avoid breaking shared systems? Is the central team limiting itself to decisions that genuinely need shared control?
When the smallest unit is still the wrong unit
A local team can have the best context and still push cost onto another team, ignore a right or lack the skill to manage the risk. In those cases the decision should move upward or stay local under a shared rule.
Centralisation has its own failure mode: decisions become slower and less accurate because the approver is far from the work. The question is which level can handle the consequence well, with enough context, capability and accountability.