How do you organize shared services?
Mapping Finance, HR, IT, Legal, and Procurement onto Platform, Plexus, and Swarms — the AO Method’s answer to a false binary.
“Centralize or decentralize?” is the wrong question. Shared services rarely fail as a function — they fail as a decision-flow design. The AO Method distributes a shared function across three layers instead of parking it in one department with a ticketing system, then tests the boundary between them before redesigning anything.
01 · System 3
Platform
Shared backbone · enables, does not command
Holds infrastructure, standards, and guardrails so no Swarm rebuilds compliance, security, or financial controls from scratch. The diagnostic question: is Platform enabling flow, or has it quietly become a command center?
- Owns what must stay uniform: compliance, security, brand, financial controls
- Provides self-serve capability, not approval gates
- Flags sign-offs required for decisions with no correlated enterprise risk
- Passes the continuity test: survives the departure of one expert or sponsor
02 · System 2
Plexus
Coordination layer · negotiates the interface
The layer almost every shared-services model skips. Without it, every interaction defaults to a rigid ticket queue or an informal favor economy.
- Negotiates SLAs, priority, and capacity between Swarms and Platform
- Triages non-standard requests without a manager-to-manager standoff
- Sequences competing demand across Swarms on explicit criteria
- Surfaces where informal power is filling a coordination gap
03 · System 1
Swarms
Delivery units · consume and own locally
The teams actually using the shared service. If a Swarm waits on Platform for a decision with no correlated risk, that’s a decision-rights problem wearing a shared-services costume.
- Owns every reversible, contained decision without escalation
- Escalates only what is irreversible, high blast-radius, or sets precedent
- Names one accountable owner for each shared-service interface
- Audits where waiting has no risk-based justification
Autonomy–Risk Boundary
Draw the line, don’t default itReversible & contained → Swarm decides
No correlated enterprise risk. Self-serve, cheap to reverse, no precedent set. Platform provides tooling, not approval.
Irreversible or high blast-radius → escalate via Plexus
Sets precedent, correlated risk across Swarms, or hard to reverse. Requires an explicit Platform decision — not a silent default.
One method, read as a design problem — not an org chart.
The AO Method diagnoses decision flow, culture, structure, and adaptive capacity as one connected system, then redesigns it with you. See how this same three-layer lens reads Haier’s RenDanHeYi and Bayer’s Dynamic Shared Ownership, or work through your own shared function with the AO Platform Playbook.
Further reading: Principles of the AO Method · Full Menschgeist catalog on Payhip
Discover more from Menschgeist
Subscribe to get the latest posts sent to your email.