The AO Method

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 it

Reversible & 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.

Read the Greiner × VSM comparison Get the AO Platform Playbook

Further reading: Principles of the AO Method · Full Menschgeist catalog on Payhip

The AO Method

9 problems the Adaptive Organization helps you solve.

A field guide to the organizational tensions the AO Method diagnoses and redesigns — beyond framework compliance.

Problem 01

Framework theater: teams “do agile,” the org stays rigid

Scrum, SAFe, Kanban, and DevOps run perfectly at team level — while decision rights, interfaces, and structure never change. AO reads coherence of the whole system, not compliance of a single practice.

Framework vs. system Operating model design Structural coherence

Problem 02

Change that never becomes transformation

New roles, rituals, and reorganizations — without any shift in identity, decision rights, or culture. AO separates surface change from transformation of operating logic.

Decision rights Operating logic Identity shift

Problem 03

Strategy that never reaches the front line

Leadership intent stalls before it becomes local decisions and trade-offs. AO uses Hoshin Kanri, catchball, and a vision–strategy–tactics cascade to keep intent traceable to action.

Strategy deployment Hoshin Kanri Vision–strategy–tactics

Problem 04

Blurred ownership and executive decision bottlenecks

Escalation paths are unclear and authority pools at the top, creating latency everywhere below it. AO maps decision flow the way VSM thinking maps value flow.

Decision flow Authority mapping Escalation design

Problem 05

Local agility, global chaos

Individual teams are fast and adaptive — the enterprise around them stays incoherent. AO’s five-dimension lens (Deliver, Demand, Capacity, Capability, Organisation) names the systemic constraint before prescribing a fix.

Five-dimension diagnostic Systemic constraints Value-stream fragmentation

Problem 06

Politeness that hides the real conflict

Nice meetings mask misalignment, conflict avoidance, and undiscussables. AO diagnostics separate surface civility from substantive candor.

Candor vs. politeness Psychological safety Undiscussables

Problem 07

M&A integration that stalls after day one

Two systems merge on paper but never truly integrate decision flow or culture. AO applies a Diagnose–Design–Pilot–Scale loop with flocking primitives — alignment, cohesion, separation, avoidance — for day-one coordination.

M&A integration Diagnose–Design–Pilot–Scale Day-one coordination

Problem 08

A business that can’t survive without its founder

Growth, expertise, and authority stay trapped in one person. AO redesigns decision continuity over 24–36 months so the system outlives its owner.

Founder dependency Decision continuity Reversible delegation

Problem 09

Transformation fatigue and AI-driven change that dictates people

Another initiative, another tool rollout — trust and adaptive capacity erode with each cycle. AO treats ERP and AI as accelerants that must land on redesigned human decision flow, not replace it.

Transformation fatigue Human-agent governance Adaptive capacity

One method, read as a design problem — not a checklist.

The AO Method diagnoses decision flow, culture, structure, and adaptive capacity as one connected system — then redesigns it with you, not for you. Curious where your organization sits? Start with an AO Health Check across the Deliver, Demand, Capacity, Capability, and Organisation dimensions.

Start an AO Health Check

AO METHOD · WORKING PAPER · OWNER RETIREMENT

Preparing to Step Away

Using the AO Method to design your retirement as a system change, not a transaction.

Working paper · First edition 2026 · Menschgeist · AO Method

This paper is written for owners who built something and now want to leave it well. Not sell it well. Not exit well. Leave it well — with the confidence that what you built will still be alive, coherent, and adaptive on the day your name is no longer on the door.

Most retirement advice treats a departure as a legal event with people topics attached. Lawyers draft, bankers price, tax advisors optimise, and a change consultant is added to soften the human edges. That is not wrong. It is insufficient. It confuses a transaction with a transformation.

Our practice uses the same diagnostic frame here that we use for merger integration, executive succession, and post-founder restructuring — because the underlying problem is identical. A living system has to keep living after a defining actor leaves it.

CONTENTS

Why most exit plans confuse three different problems
The question to replace “who will replace me?”
The five-dimension diagnostic, read twice
Where authority is actually stored
What to measure — and which metrics will lie to you
A defensible twenty-four to thirty-six month arc
Ten failure patterns worth naming in advance

Three layers most exit plans confuse

When owners speak about retirement they are usually holding three different problems in one hand and treating them as one. Separating them is the first move.

Ownership transfer

The transactional layer. Shares, price, structure, earn-out, warranties, tax. Well served by existing advisors.

Role transfer

The poietic layer. Who takes the CEO chair, the board seat, the client-facing figurehead. Well served by executive search and governance work.

System redesign

The praxis layer. Decision flow, interaction rules, cultural conditions, adaptive capacity. Rarely served at all — and the layer the other two depend on.

The first two layers can be delivered on time by competent professionals. The third determines whether the company is still viable eighteen months after you close the door. Every retirement failure we have observed has been a third-layer failure dressed up as a first- or second-layer surprise.

Ownership transfers on a signing day. Role transfers over a quarter. Systems transfer over years — if they transfer at all.

The right question to start with

You are probably asking who will replace you. That question is too small. It tempts you to look for a copy of yourself, which does not exist and, if it did, would not want the job on your terms. The AO question is different, and more productive:

Which parts of my organisation only work because I am standing in them — and how do we redesign those parts so they no longer need me?

The reframing matters because load-bearing points routed through a person can be redesigned. A copy of that person cannot.

The five dimensions, read twice

AO uses a five-dimension diagnostic frame. For retirement work, run the scan twice: once for current performance, once for founder-dependency — how much of it collapses if the owner is removed tomorrow.

Deliver	Which delivery decisions still route through me? Pricing exceptions, discounts, quality overrides, delivery-date promises.
Demand	How much of the pipeline is owner-relational — my network, my reputation, my seat on the association board?
Capacity	Who actually protects flow when things go wrong at night, on a weekend, in a crisis?
Capability	What critical know-how is tacit and lives only in my head?
Organisation	Where are decision rights formally documented — and where are they exercised informally by me?

The founder-dependency delta

Score each dimension from 1 (works without me) to 5 (collapses without me). Do it alone. Then have your top three people do the same, blind.

You score 2, they score 5 — you have a hidden dependency. You score 5, they score 2 — you are quietly redundant already, and that is good news. The gap between the two scores is your retirement backlog.

Map the decision flow, not the org chart

The org chart tells you what the company intends. The decision flow tells you what it does. Three instruments make the difference visible.

The decision map

Take the twenty recurring high-consequence decisions. For each, write who formally decides — and who actually decides. The delta is where your authority is stored.

The informal power map

Who calls you, for what, how often. Every recurring call is a delegated decision right that has not yet been delegated.

The undiscussables

The topics only your presence is holding. They detonate in the first year post-exit unless surfaced on your terms, while you can still shape the answer.

Transactional metrics will lie to you

“Successor named. Valuation agreed. Legal drafted.” Those tell you the process is on schedule. They do not tell you whether the system is becoming viable without you. Six indicators do.

Decision latency — with and without the owner in the room — the gap should close
Owner-untouched decisions — live decisions you have not joined in ninety days
Reversibility test — three months absent without key indicators drifting
Candor readings — politeness is not evidence of health; candor is
Learning velocity — how fast retrospectives close without you blessing them
Role-borne relationships — key contacts held by a named role, not by you

You do not sign on a date. You sign when the indicators are green.

A twenty-four to thirty-six month arc

A working transition follows the same four-phase loop our practice uses for merger integration. The arc below is defensible, not decorative — six months is enough for a legal transaction, never for a system redesign.

Months 0–3

Diagnose

Five-dimension scan with founder-dependency overlay
Decision-flow map for the top twenty recurring decisions
Informal-power and calling-pattern map
Cultural read: values alignment, entropy, undiscussables

Months 3–6

Design

Target operating model as decision rights and interaction rules
Delegation sequence based on the autonomy-risk boundary
Strategic spine with owner-independent metabolism
Owner supervision cadence established

Months 6–15

Pilot

Small, reversible experiments in delegated authority
Owner absent from selected decision cycles by design
Indicator discipline instead of calendar discipline

Months 15–36

Scale & step away

Progressive withdrawal on a documented timeline
Legal transaction placed on top of a working system
The owner’s own transition designed, not improvised

Ten failure patterns worth naming

These are the patterns we see repeatedly in transitions that stall or reverse. Each one is a specific violation of the design principles above. Naming them in advance is cheaper than diagnosing them after.

Successor cloning — hiring someone who resembles the owner and expecting the system to run unchanged
Late diagnosis — starting six months out — enough for a transaction, not for a redesign
Silent scaffolding — out of the meetings, still called at night and on weekends
Unnamed undiscussables — leaving without surfacing the topics your presence was holding
Handshake pipeline — discovering post-exit that demand was almost entirely owner-relational
Governance theatre — a board correct on paper, never designed to hold the decisions it now holds
Successor over-supervision — staying on as chair with unclear authority, colonising the successor’s space
Identity vacuum — not designing what you retire into, then undermining the transition to protect an identity
Cultural drift — the operating model transfers, the cultural conditions do not
Timeline theatre — the withdrawal timeline is published, celebrated, and quietly ignored

Each one is a design failure, not a people failure.

A different kind of legacy

Legacy is not a plaque or a preserved product line. It is the system that still works when you are gone. It is measurable — in decision latency, in the shape of the pipeline, in the candor of the leadership team, in the resilience of the client relationships. It cannot be plaqued. It can only be designed.

The company you built is a scaffold that held you up.

The company you leave behind holds itself up.

The work between the two is the retirement.

Download the field paper

The full working paper in three languages — twenty sections, three working canvases, ten failure patterns, and the phase-by-phase arc.

English · PDF

Preparing to Step Away

Download the English edition ↓

Français · PDF

Se retirer, avec méthode

Télécharger l’édition française ↓

Deutsch · PDF

Loslassen mit Methode

Deutsche Fassung herunterladen ↓

NEXT STEP

Working with our practice

Menschgeist is a partner practice. We run AO diagnostics, design target operating models, and accompany owners through the withdrawal arc — alongside the lawyers, bankers, and tax advisors who handle the transaction layer. If you are two to three years from stepping away, the diagnostic is the place to start.

Start a conversation

menschgeist.com · pierre@menschgeist.com

Working paper released under the Menschgeist practitioner licence: free to read, cite, and use in engagements with attribution to Menschgeist and Pierre E. Neis. Redistribution requires attribution.

Menschgeist · AO Method · Pierre E. Neis

Download the English version >>

Download la Version Française >>

Deutsche Version runterladen >>

BPMN in Traditional Transformation vs. the AO Method

A comparative analysis · Pierre Neis, Menschgeist · AO Method

BPMN 2.0 is a notation, not a method. What differs between a traditional transformation programme and an AO-led one is not whether BPMN is used, but what BPMN is asked to represent, who owns the model, and what decision it feeds.

Section 1

1.Framing the question

In traditional transformation, BPMN is typically deployed as an artifact of control: a standardised description of how work should flow, used to align people to a predefined process, automate steps, or satisfy compliance.

In the AO Method, BPMN is used as a diagnostic and negotiation surface: a partial map of the value and decision flow that helps a system see itself, expose ambiguity, and redesign interaction rules — never as the definition of the organisation.

The comparison below is written from that stance: BPMN is welcome, but it sits inside a design method, not the other way around.

Section 2

2.Side-by-side comparison

Dimension	Traditional transformation with BPMN	AO Method use of BPMN
Primary purpose	Standardise, automate, and control processes; align people to a target “to-be” flow.	Reveal decision flow, coupling, and ambiguity; support redesign of interaction rules and authority.
Unit of analysis	The process (activities, tasks, gateways, swimlanes).	The system: decision rights, feedback loops, informal power, culture, capacity — with process as one signal among several.
Direction of fit	People are fitted to the process. Deviations are treated as non-conformance.	Processes are organised around people and around what the system needs to sense and decide. Deviation is treated as diagnostic evidence.
Model status	Prescriptive. The “to-be” BPMN is the truth the organisation must converge to.	Provisional. The BPMN is a hypothesis of current flow; the “to-be” is a bounded experiment, not a target state.
Ownership	Process owners, BPM CoE, PMO, and automation/IT. Business is a “stakeholder”.	Distributed. The people doing the work co-model with facilitation; sponsors own enabling conditions, not the diagram.
What gets modelled	Happy-path activities, exceptions, hand-offs, systems, RACI.	The same, plus decision rights, escalation and reversal paths, informal power, and the boundary between reversible and irreversible calls.
Metrics	Cycle time, throughput, cost per case, automation rate, SLA conformance.	Deliver, Demand, Capacity, Capability, Organisation — the AO five-dimension lens read through the process, not compliance to the drawn flow.
Relationship to autonomy	Autonomy is a residual: whatever the process doesn’t specify.	Autonomy is designed: reversible, contained decisions stay local; high-blast-radius decisions get explicit guardrails and escalation, and both are visible in the model.
Change logic	First-order change: redraw the diagram, retrain, deploy, enforce.	Second-order change: shift identity, decision rights, culture, and operating logic. The diagram follows the redesign, not the other way around.
Tooling posture	ERP/BPMS/workflow engines as the destination — the model exists to be executable.	Tools (BPMS, ERP, AI agents) treated as accelerants that must land on redesigned human decision flow rather than dictate it.
Handling of exceptions	Modelled as edge cases; ideally removed or automated away.	Treated as information about where the system’s real intelligence lives and where standardisation would destroy adaptive capacity.
Success signal	Adherence to the “to-be” model; automation coverage.	Healthier flow, shorter decision latency, higher candor, reduced dependency, growing team self-sufficiency — regardless of diagram conformance.
Typical failure mode	Framework/process compliance without organisational change: the BPMN is clean, the system is unchanged.	Over-modelling: producing rich diagnostics without converting them into bounded redesign experiments.

Section 3

3.Where the two approaches actually diverge

Three points matter more than the rest.

1. What the model is of

Traditional BPM models the work. AO uses BPMN to model the decisions the work requires — who can decide, under what constraints, with what reversibility, and against which feedback. A traditional swimlane says “Legal reviews the contract”; an AO reading of the same lane asks whether that review is a real decision, a rubber stamp, or a substitute for missing authority elsewhere.

2. Prescriptive or provisional

Traditional programmes treat the “to-be” as the answer; deviation is defect. AO treats every “to-be” as an intervention-as-hypothesis: a bounded, reversible experiment against a named constraint, expected to teach the system something and to be redrawn.

3. Who the model is for

Traditional BPMN serves owners of standardisation (PMO, BPM CoE, IT, audit). AO BPMN serves the people who have to make judgement calls inside the flow — it exists to give them a shared picture of coupling, ambiguity, and authority so they can negotiate better, not to remove their judgement.

Section 4

4.When each approach is appropriate

BPMN in its traditional form is genuinely useful when…

the work is high-volume, low-variance, and regulated (payments, claims, KYC, statutory reporting);
the decision content of each step is low and the value is in consistency, auditability, and automation;
the organisation needs a common language with vendors, auditors, or ERP integrators.

The AO reading of BPMN becomes necessary when…

decision rights are unclear, disputed, or invisibly held by informal power;
the process on paper and the process in practice have diverged, and standardisation would freeze the wrong version;
the transformation is coupled to ERP, AI agents, or an operating-model change, so the tool will otherwise dictate the organisation;
the organisation is stuck in local-agility / global-chaos, executive decision bottlenecks, or transformation fatigue — the AO problem families where redrawing flows without touching authority reliably fails.

In practice, most serious transformations need both: BPMN as a language for the standardisable layer, AO as the design method for the decision and interaction layer that BPMN cannot represent on its own.

Section 5

5.A practical integration pattern

The pattern I use with clients — including in ATAVA-style multi-partner design and in AO Master Diagnostic engagements — sequences the two deliberately.

AO framing first. Name the system’s purpose, the five-dimension read (Deliver, Demand, Capacity, Capability, Organisation), and the decision-flow hypothesis. This defines what the BPMN should see.
BPMN as diagnostic. Model current flow at macro-chain level (typically 5–7 processes), with swimlanes that include decision authority and escalation, not only functional roles. Treat the model as evidence, not truth.
Read the gap. Compare the modelled flow against decision latency, exception patterns, informal power maps, and the five-dimension signals. Name where standardisation helps and where it would destroy adaptive capacity.
Bounded redesign. Convert the highest-leverage gap into a small, reversible experiment with an explicit constraint hypothesis and exit criteria — not a full “to-be” rollout.
Standardise only what has stabilised. Move a sub-flow into executable BPMN / BPMS / automation only after the human decision flow around it has been redesigned and has held under load. Tool follows design.

This keeps BPMN’s strengths — shared notation, executability, auditability — while refusing its usual failure mode: mistaking a clean diagram for a changed organisation.

In one line

6.Summary

Traditional transformation uses BPMN to fit people to processes. The AO Method uses BPMN to make the decision system visible so processes can be organised around people, and standardises only what the redesign has proven safe to standardise.

Published 2026 Transformation Achievements

Evidence-backed transformation cases for adaptive organization design

A curated set of 2026 public examples showing how organizations are redesigning operating models with digital platforms, AI, automation, and end-to-end service integration.

What these cases have in common

The strongest 2026 transformation stories are not tool-adoption stories. They show architecture becoming operating model: legacy systems are consolidated, workflows become observable, AI augments throughput, and digital access expands who can participate in the service.

8published cases

2026achievement focus

5diagnostic lenses

Transformation achievement cases

Each card captures the published achievement, key metric, and why the case is useful for transformation work.

Enterprise digitalAI at core

Prysmian: Cloud migration and AI-enabled operating model

Prysmian’s SAP transformation story reports a four-month move to cloud, automation of up to 70% of repetitive activities, an 80% reduction in new-solution implementation time, a 50% faster time to market, and more than 100 AI use cases.

70%automation

80%faster implementation

100+AI use cases

Use this case to discuss how enterprise architecture modernization compresses delivery cycles and creates an AI-ready platform.

Open SAP/Prysmian source

Digital governmentCyber resilience

UK Government: Modern digital government roadmap

The UK’s modern digital government reporting highlights faster remediation of serious security weaknesses, GOV.UK app pilots, and legacy data-centre closures.

6xfaster fixes

2026roadmap report

GOV.UKservice modernization

Use this case to connect digital transformation with security posture, shared platforms, and public-service modernization.

Open UK roadmap source

AI transformationFinancial services

Nu Holdings: AI-native banking operating model

Nu Holdings’ 1Q26 materials describe a shift from AI adoption to AI transformation, with engineering throughput up 50%, testing cycles 90% faster, and AI Private Banker features reaching more than 15 million monthly active users.

50%throughput

90%faster testing

15M+AI users

Use this case to explore AI as an operating-system shift rather than an isolated productivity layer.

Open Nu source

AI workforceProductivity

PwC AI Jobs Barometer: Productivity gains in AI-exposed companies

PwC’s 2026 AI Jobs Barometer reports that “super-star companies” most exposed to AI achieved 163% labour productivity gains, with stronger headcount growth among AI-exposed companies.

163%productivity signal

52%headcount growth

36%least-exposed growth

Use this evidence to frame AI transformation as a productivity and organizational-capability question.

Open PwC source

AI operating modelFuture of work

Microsoft Work Trend Index: Frontier firms redesign work around AI

Microsoft’s 2026 Work Trend Index describes “Frontier Firms” rebuilding operating models for the AI era, based on large-scale workplace signals and survey data from AI-using workers.

20,000workers surveyed

365work signals

AIoperating-model shift

Use this case to discuss roles, coordination, workflows, and team design around AI.

Open Microsoft source

Digital justiceAI-enabled service

India e-Jagriti: Paperless consumer justice platform

India’s e-Jagriti platform won a 2026 National e-Governance Award after consolidating OCMS, e-Daakhil, NCDRC CMS, and CONFONET into a single AI-enabled paperless ecosystem.

2.29Lcases filed

2.07Lcases disposed

90.75%disposal rate

Use this case to show how architecture redesign, access redesign, and performance observability combine in public-sector transformation.

Open PIB source

EuropeDigital decade

EU Digital Decade: Enterprise adoption and infrastructure progress

The European Commission’s 2026 Digital Decade reporting shows progress in 5G coverage, cloud adoption, data analytics adoption, and AI application deployment among EU enterprises.

96.8%5G coverage

46.7%cloud adoption

~20%AI app deployment

Use this as a macro benchmark for Europe’s digital transformation progress and remaining adoption gaps.

Open EU source

Agile lensCaution

Agile transformation: Stronger as a lens than as 2026 proof

Agile-specific 2026 achievement publications are less concrete than digital and AI cases. The Agile Business Consortium’s 2026 awards page was still a nomination and announcement process at the time of review.

2026award cycle

Octannouncements

Lensnot hard evidence

Use agile to interpret adaptability, flow, and feedback loops rather than as the strongest source category for 2026 proof points.

Open agile source

Five diagnostic themes for transformation design

01Fragmentation: how many systems must one journey cross?

02Throughput: where does work slow down?

03Observability: can leaders see bottlenecks in time?

04Access: who is excluded by the current design?

05Absorption: can the organization learn fast enough?

CSS Agile Transformation >>

e Jagriti Transformation >>

Nu Holding >>

Prysmian SAP >>

UK Government >>

Digt AG >>

MSC >>

SWISS RE >>

There are a few recurring “families of problems” where the AO method, as an organizational operating system, is especially useful in practice.

To keep it concrete, here is a first cut, phrased as problems leaders actually feel:

1. Chronic misalignment between strategy and operations

Many organizations have a nice strategy deck, but daily work is driven by local priorities, legacy structures, and firefighting.
AO helps by:

Making the value-creation pathways explicit (who serves whom, with what promises, via which capabilities).
Creating clear, minimal service contracts between units, so strategic intents are translated into concrete, testable expectations.

In other words, AO can address the “strategy theater vs. operational reality” gap.

2. Silo conflicts and unclear accountabilities

Classic functional or project structures often create blurred ownership: multiple teams touching the same domain, but no one truly accountable for outcomes.

AO helps by:

Defining stable, end-to-end service domains (or platforms) with explicit outcome ownership.
Clarifying what is “mandatory” vs “optional” in collaboration, reducing endless negotiation and escalation.

So, AO is good at reducing political friction and making collaboration more contractual and transparent.

3. Scaling agility without scaling chaos

Many organizations “go agile” in teams, but fail to design the surrounding system (governance, interfaces, escalation paths), leading to local agility and global chaos.

AO helps by:

Designing an integrated architecture of units where autonomy is bounded by clear service expectations and economic logic.
Providing patterns for how to scale (replicate, split, federate, or platformize) when demand or complexity grows.

It’s particularly strong when the question is: “We have agile teams; how do we make the whole organization behave coherently?”

4. Overloaded leadership and decision bottlenecks

Executives often become bottlenecks because every exception, escalation, or cross-silo issue ends up on their desks.

AO helps by:

Distributing decision rights along value flows and service domains, rather than hierarchy alone.
Creating explicit escalation and arbitration mechanisms embedded in the design, so fewer things require heroic leadership intervention.

This tends to reduce cognitive overload at the top and increase local problem-solving capability.

5. Transformations that never “stick”

Many change programs launch with enthusiasm and then regress to old patterns once the consultants leave.

AO helps by:

Focusing on structural and contractual changes (how work is organized, who serves whom, which promises are made) rather than only mindset or process coaching.
Giving a stable reference model that leaders can continuously refine, instead of a one-off framework that fades after the project.

So it is well-suited to organizations that have “transformation fatigue” but still need deep, systemic change.

Go to AO Website

Get the book here

Book a Conversation

Most organizations I meet are not short on feedback. They have engagement surveys, NPS scores, customer complaints, ticket tags, retrospective notes and escalation emails. They lack feedback loops. These are places where signals reliably lead to small adjustments in how the system works. Here, people can actually see that connection. When feedback disappears into a void, people eventually stop offering it. They may offer it with a shrug, assuming nothing will change.

From an AO and systems‑thinking perspective, feedback loops are not an HR topic or a nice‑to‑have. They are crucial for a living organization to learn and adapt. The process involves regularly comparing intentions with actual outcomes. Then, adjustment of structure, flow, and behavior is done in small steps. In this issue, I share a story of a team. They improved their work by moving from tired rituals to a simple, tight loop. I also provide a concrete AO move you can try. This move is helpful if you sense feedback in your system is getting stuck rather than closing the loop.

From the field: from tired retros to a living loop

A cross‑functional product team told me they were “doing retros” but not really learning. Every two weeks, they spent an hour filling a digital board with sticky notes. They noted what went well, what didn’t, and ideas for improvement. At the end, they picked a couple of actions. By the time the next sprint ended, nobody remembered what those actions were, or whether anything had changed. The ritual was there; the loop was not.

When we looked closer, two patterns stood out. First, the scope of their retros was too broad. They tried to talk about everything at once: coding practices, stakeholder communication, deployment issues, team dynamics, long‑term strategy. Second, nothing outside the team room changed. Many of their frustrations were about upstream and downstream parts of the system. They dealt with unclear priorities, last‑minute requests, and release policies. However, their “actions” stayed within their own bubble.

Rather than abandoning retros, we narrowed and repurposed them. For a month, we focused the team on one specific flow for learning. This was the journey of one particular type of change, from idea to live usage. We also invited one person from customer success. Another was invited from operations. They joined for a short part of the session. This way, the loop included those who saw the impact outside the team.

We introduced a simple visual that became the backbone of their new loop. It was a board with three columns labeled “Signals”, “Experiments”, and “Effects”. Each week, rather than listing generic “went well/didn’t go well” items, they identified 2–3 specific signals about that flow. These signals could include a recurring support ticket pattern, a delay hotspot, or a positive surprise in customer behavior. For each important signal, they designed one small experiment. It could be a tweak in how they coordinated. They might also adjust how they sequenced work. Another option was tweaking how they checked quality. Alternatively, they could change how they communicated changes.

Crucially, the board stayed visible in their team space and in their digital workspace. The following week, they didn’t start from a blank slate. They returned to the same board and asked: “What did we actually do? What did we see? Do we keep this change, adjust it, or drop it?” Over time, some experiments became the new normal, others were retired, and new ones appeared.

Within a few iterations, their energy shifted. The team started noticing patterns earlier. They could see that a change in how they handled handoffs reduced a certain kind of support ticket. They also noticed that a change in release timing created new issues elsewhere. Customer success felt heard because their signals were now explicitly part of the loop, not an afterthought. One team member summed it up neatly: “We used to collect feedback about the past. Now we have a place where feedback changes what we do next.”

Try this AO move this week – design one tight loop

You don’t need to redesign all your feedback processes to start tightening your loops. You can begin by creating one simple, explicit loop around one important flow, and running it for a few weeks.

Pick one flow that really matters.
Choose a concrete slice of work where better learning would help. It could be Onboarding a certain type of customer. It might involve handling a particular class of incidents or claims. Consider delivering a type of feature or running a recurring service. Make it narrow enough that everyone can picture real examples.
Define 2–3 signals you will look at every week.
Ask: “If this flow were getting healthier or sicker, what simple signs would we see?” These signs could be things like repetition in support tickets. You might also notice a specific delay point. A satisfaction indicator may appear. There could be a handoffs that often goes wrong. Alternatively, you might hear a frontline story from customers or staff. Keep the list short and easy to see at a glance.
Install a small, regular loop into an existing meeting.
Instead of adding a new ceremony, use a meeting you already have. Reserve 15–20 minutes in that meeting. For example, use the end of a weekly team meeting, service review, or leadership huddle. Use that slot only for this flow and these signals. Every time, follow the same pattern:
- look at the signals;
- choose at most one small adjustment you will try before the next loop;
- write it down where everyone can see it.
Keep a tiny “signals → adjustments → effects” log.
On a physical board or a shared document, track three things. First, note which signal you reacted to. Next, record what adjustment you decided to make. Lastly, write down what you noticed by the next meeting. You don’t need perfect data; you need enough observation to see whether your system responds.
Review the loop itself after 3–4 cycles.
After a few weeks, step back: Is this loop giving us useful learning? Are the signals still the right ones? Are our adjustments too big or too vague? Do we need to involve someone else (e.g. another team, a function) to make the loop complete? Adjust the design of the loop as well as what you do inside it.

If you repeat this pattern across a few important flows, you’ll discover that your AO work doesn’t rely on big initiatives anymore. It starts to feel like part of how you move. Signals come in, small experiments go out, and everyone can see the connection between the two.

You want more?

If you’d like help designing feedback loops and lightweight review practices tailored to your AO work, you can book a short conversation with me.

Book a conversation

AO E-books

AO METHOD

Traditional Organizational Change Management (OCM) typically drives toward a predefined target state. In contrast, Agile Organization (AO) treats the “target” as an evolving, adaptive organizational capability. This difference is clear when viewed through a BPM lens. Traditional OCM adjusts people around processes, while AO organizes processes around the people doing the work.

Short reminder: what BPM is

Business Process Management (BPM) is a management discipline. It involves analyzing, designing, implementing, monitoring, and continually improving end‑to‑end business processes. The goal is to enhance performance and customer outcomes. It treats processes as repeatable flows of activities that can be modeled, measured, and optimized across the organization. A classic BPM initiative focuses on mapping processes. It defines owners and standardizes work. Governance and tools are used to control and improve those flows over time.

Target solution: fixed state vs evolving capability

In traditional OCM, the target solution is usually a relatively fixed “to‑be” state defined upfront. This includes new processes, structures, roles, and systems. The change effort is about moving people from the current state to the target state. This creates a linear narrative. First, diagnose the gap. Next, define the future state. Then build the change plan. Finally, drive adoption until the new state is “embedded.” AO, by contrast, assumes the environment changes faster than any fixed blueprint. Therefore, it treats the “target” as an adaptive organization. This organization can continuously sense, decide, and reconfigure itself.

This leads to different questions. Traditional OCM asks, “How do we get everyone to the new operating model and keep them there?” AO asks, “How do we build structures, practices, and agreements that make continual reconfiguration safe, fast, and purposeful?” In OCM, you measure success by the degree of compliance with the designed target. In AO, you measure success by the organization’s adaptive capacity. This includes the speed of learning, the quality of decisions, and the ability to re‑shape work as conditions change.

Change logic: gap closing vs pattern evolving

Traditional OCM is gap‑closing. It involves defining the desired end‑state. Then, assess readiness and treat resistance. Afterward, roll out communications and training. Finally, stabilize into BAU. This often assumes relatively stable strategy, technology, and process architectures, even if they are complex. Governance, templates, and standardized toolkit become very important. The organization is encouraged to align with the one approved solution.

AO works with evolving patterns instead of final states. It creates conditions where multiple hypotheses can be tried in parallel. Teams experiment with structures, roles, cadences, and interfaces. The most effective patterns are then scaled. The focus changes from managing resistance to engaging people. They become designers of their own context. Explicit mechanisms help retire obsolete structures and practices. These prevent defending them as the “new normal.”

BPM lens: process‑centric vs people‑centric organization

Seen through BPM, traditional OCM tends to be process‑centric. You begin with the process map. You then define the optimal flow. Next, ask: “How do we align people, roles, and org structures around this process so it can run efficiently?” People play roles in predefined sequences. Change management ensures they execute the new process correctly. It also ensures they do it consistently. The process is the primary object; people are variables to be aligned to it.

AO almost inverts this perspective. It treats people as the core organizing principle. This includes teams, networks, and communities of practice. Processes are used as flexible instruments. These instruments can be shaped, combined, or dropped by the people. Instead of “adjusting people around business processes,” AO focuses on the people in the BPM. This includes who actually carries the work, who holds the knowledge, and how they collaborate to create value. Processes become boundary objects and agreements. They are not cages. Teams can adapt workflow, sequencing, and interfaces as they learn. They must respect purpose, constraints, and minimal interoperability standards.

Concretely:

In traditional OCM+BPM, a process redesign project defines the new flow, roles, and KPIs. Then, OCM ensures training, communication, and adoption. This continues until variance is minimized.
In AO+BPM, the teams that own the work continuously define and refine their processes. The BPM artifacts are deliberately kept light and revisable. This makes it possible to change them when the work or context changes.

Organizational design implications

You tend to get functional or process‑tower structures if you start from a fixed target and process‑centric BPM. This approach leads to strong central governance. There is also a heavy emphasis on standardization and control. This works well for high‑volume, low‑variety work and for environments where predictability matters more than innovation. However, it struggles when customer needs, technology, or regulations shift frequently. Every change implies a new “big” OCM program to move from one fixed state to another.

AO’s adaptive target and people‑centric BPM logic lead to modular, networked structures. These consist of small, semi‑autonomous units. They are linked by minimal essential constraints, such as common principles, standards, and interfaces. AO embeds change into the operating model, instead of running a sequence of large OCM initiatives. Local changes are expected and supported. BPM provides just enough shared scaffolding for coherence and coordination. This reduces the dependency on central change programs and increases the organization’s ability to reconfigure itself from the edges.

Examples of companies using Traditional OCM successfully

Several well‑known companies have used traditional, plan‑driven OCM successfully, especially for large technology and process roll‑outs.

Illustrative company examples

A leading retail pharmacy chain introduced a new point‑of‑sale system. It used a classic OCM playbook. This included early stakeholder involvement, structured communications, and role‑based training. Within six months, it achieved 70% faster transactions. Customer satisfaction increased by 25%. This success shows how traditional OCM can work well for clearly bounded system changes.
A global pharmaceutical company implemented a new data management platform and faced strong initial resistance. By applying a standard methodology (sponsor coalition, communication plan, training, and incentives for early adopters), significant progress was made. It reached 80% user adoption in the first year. Data quality and decision speed improved.
A Fortune 500 chemical company followed a structured, multi‑phase ERP change management approach with defined phases, deliverables, and KPIs. The program delivered around a 25% gain in operational efficiency. Another firm in the same material reduced month‑end closing time from 15 to 5 days. This was achieved after optimizing ERP usage under a traditional OCM framework.
A public‑sector agency (the U.S. General Services Administration) migrated to Google Workspace using extensive up‑front training, communication campaigns, and a phased cut‑over. Within weeks, help‑desk call volume dropped below the prior baseline. Most users who attended training adapted quickly. This illustrates how standard OCM tools can smooth a large collaboration‑suite rollout.

These cases all share the typical traditional OCM characteristics. They include a predefined target solution such as POS, ERP, data platform, or collaboration suite. The methodology is structured for change. They have strong executive sponsorship. Success is measured as stable adoption of the designed end state.

Implementation steps for Adaptive OCM emphasize less on delivering a single change project. They focus more on building a system capable of continuous change. Here is a concise step set you can reuse and adapt.

1. Diagnose adaptiveness, not just readiness

Assess current culture, leadership behaviors, and structural constraints for adaptability (decision speed, psychological safety, learning habits, autonomy).
Map change fatigue, existing OCM practices, and where people already self‑organize successfully; treat these as seeds to amplify.

2. Define adaptive intent and guardrails

Clarify why you need an adaptive organization now (market volatility, digital pace, etc.) and what “more adaptive” means in concrete behavioral terms.
Set a small number of non‑negotiable constraints. These include principles, ethics, compliance, and customer promises. Within these, local units are free to experiment and redesign.

3. Create distributed change roles and capabilities

Shift from a central “OCM team that implements change” model. Develop a distributed network of change agents embedded in teams. Provide these teams with coaching from OCM specialists.
Design targeted training on adaptability skills (experimentation, feedback, conflict, facilitation) rather than only “how to use the new process/system.”

4. Implement iterative change planning and delivery

Replace big upfront change plans with rolling, lightweight plans that are revisited every few weeks based on feedback and impact.
Use small experiments like pilots or A/B testing in ways of working. Implement micro‑structural tweaks and scale what works. Do this instead of committing early to a single solution.

5. Build continuous feedback mechanisms

Install regular pulse checks, retrospectives, and qualitative sensing (focus groups, open forums) as a permanent feature, not just during “projects.”
Close the loop visibly. Show what was heard. Indicate what is being changed. Explain what will not change and why. This approach will maintain trust in the adaptive process.

6. Align operating model elements with adaptiveness

Adjust governance to allow faster local decisions, clear accountabilities, and simple escalation paths; avoid over‑complex approval chains.
Rework structures, roles, and BPM artifacts. This allows teams owning the work to modify processes within agreed boundaries. They can do this without launching a major program each time.

7. Reinforce and normalize adaptive BEHAVIORS

Recognize and reward experimentation, constructive challenge, and cross‑boundary collaboration, not only short‑term efficiency.
Integrate adaptive OCM practices into BAU. Use quarterly sense-and-respond cycles and establish standing change communities of practice. This ensures that “doing change” becomes “how we work.”

Get the full workbook

Book a conversation

Change & Agility Coaching (OCM meets Agile)

BPM & Operating Model Coaching with AO

In many insurers I meet, the real trouble is not the straightforward claims that follow a clear path. The real trouble lives in the complex cases. These include big accidents, business interruptions, edge cases, and disputes. Such cases suddenly cut across underwriting, legal, operations, IT, and external experts. On the outside, the customer experiences long silence. They receive generic status emails. Customers also need to call three times to “find someone who knows my case.” On the inside, teams see the claim bounce from inbox to inbox, with nobody quite owning the whole journey.

The usual response is to add more: more rules, more exception codes, another steering committee, a new case‑management system. Sometimes that helps for a while. Often, it just gives the work more places to get stuck. From an Agile Organization (AO) perspective, a complex claim is not a ticket to be pushed through departments. It is a flow that requires the right people to be around it at the right time. These people should have enough authority to act. In this issue, I share a story from a mid‑size insurer. They created a small “complex‑claim swarm.” I also share a simple move you can try if you recognize similar patterns in your own organization.

From the field: a small swarm for big claims

A few years ago, I was invited to work with a regional insurer handling health and property claims. They were not a global giant. They had a few hundred thousand customers and a few dozen people in claims. Their world had become complicated. New products, tighter regulations, and more demanding customers meant that the number of truly complex claims was rising. These cases were exactly the ones leadership cared about most. They were also the cases most likely to blow through the promised timelines.

When we looked at one of these complex claims in detail, the journey was sobering. A customer reported a serious incident through the call center. The front‑line handler opened the case and requested documents. Once the first papers arrived, the file went to a more experienced handler. This handler involved underwriting to check coverage. Then, legal reviewed the wording. Next, an external assessor and sometimes a medical expert were consulted. Each person worked from their own queue. Questions came back to the handler, who sent more emails, requested more documents, and updated the system fields. Weeks later, the customer still had no clear answer – but the case had touched six or seven desks.

From an AO perspective, nothing was “wrong” with any individual. Each function did its job. The system, however, had no real swarm around the work. So we proposed a small experiment. We worked together with the head of claims. We defined a narrow slice, focusing on complex cases. These cases were above a certain size and had specific characteristics. For that slice, we created a “complex‑claims swarm”. It included one senior handler, one underwriter, one legal contact, and one operations/IT liaison who understood the workflow rules. They got explicit authority over that slice for eight weeks.

The rules of the swarm were simple. First, every new complex claim in that slice was reviewed together in a short huddle. Second, the swarm met briefly three times a week. They decided on next steps, resolved questions on the spot, and adjusted sequencing across their queues. Third, the head of claims committed to backing their decisions inside the wider organization.

Within a few weeks, the data started to move. Average cycle time for that slice dropped, the number of “where is my claim?” calls went down, and escalations to the head of claims all but disappeared. But the most interesting effects were not in the metrics. In one session, the legal contact identified a standard clause. This clause caused a loop of reviews in almost every complex case. In another session, the IT liaison realized that the workflow engine forced a return to an earlier step. This happened even when the decision was actually clear.

At the end of the pilot, the senior handler said something that stayed with me. “For the first time, I feel like we are looking at the same claim together. We are not looking at five different versions of it in five different systems.” That sentence contains the AO question I’d invite you to reflect on. In your complex work, can a small, committed swarm focus on a narrow slice of cases? Could it provide more help than another rule? Could it offer more than an additional meeting? Could it be more beneficial than another system?

Try this AO move this week – for complex claims

You don’t need a big reorganization to change how complex claims flow. A good first AO move is to look closely at one real claim. Then design a small swarm around that type of work. Avoid pushing it through the usual departmental hops.

Pick one real complex claim. Choose an actual case from the last few months that was painful. It could have been high value, involved multiple parties, had a long duration, or included repeated complaints. Avoid a theoretical example – the point is to see your real system at work.
Map the end‑to‑end journey on one page. From first notification of loss to final payout (or closure), identify each person or group who touched this claim. This includes call center, front‑line handler, senior adjuster, underwriting, legal, external assessor, medical expert, IT, and suppliers. Draw the steps in the order they really happened. Include back‑and‑forth loops, extra checks, and manual spreadsheets. Add workarounds that never appear in the official process.
Circle the 1–2 worst friction points. Identify where the claim waited the longest. Notice if it bounced between people or kept coming back for “one more clarification.” This might be due to waiting for documents. It could also be because of legal wording debates. Unclear medical opinions might also contribute, or system blocks that forced re-work. Circle just one or two hotspots and note what seemed to be happening there.
Ask the complex‑claim swarm question. For those hotspots, consider this: “If we formed a small swarm around this kind of claim, who would we need? Who should join the conversation from the beginning?” In many insurers, the swarm typically includes a senior handler, an underwriter, and a legal contact. It also includes someone who understands workflow/IT rules. Sometimes, a medical or supplier liaison is part of the swarm as well.
Run a small, time‑boxed swarm pilot. For the next 3–5 complex claims of this type, invite that swarm into a short huddle when the claim comes in, plus a brief regular check‑in (e.g., two or three times a week). Allow them to make end‑to‑end decisions for this slice. Ensure this is within your existing policies and risk appetite. Do this without adding a new permanent committee.

If you try this, don’t only watch the average cycle time. Pay attention to what your swarm starts noticing about rules, systems, and handoffs. These are insights you could not see from a single desk. That is usually where AO’s work on complex claims really begins.

You want more?

If this experiment sparks something, please reach out. You may want to explore how AO could look in your own organization. You can book a short conversation with me. Book it here: https://menschgeist.youcanbook.me/.

If you prefer to read first, you’ll find AO e‑books and materials here: https://payhip.com/menschgeist .

If you want to dive deeper into the broader #AO Method, #Training, #Coaching, and resources, visit https://agile-organization.com.

The AO Method (Agile Organization/Agile Organizations Method) is Pierre Neis’s own framework. It is distilled from more than a decade of agile coaching. This work includes organizational transformation across many companies, cultures, and contexts. It is based on Practice-based patterns, “Agile as system dynamics,” Organic/anthropomorphic view of organizations. Initial consolidation in 2018.