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.

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.

01

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
02

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
03

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
04

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
05

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
06

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
07

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
08

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
09

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

  1. Why most exit plans confuse three different problems
  2. The question to replace “who will replace me?”
  3. The five-dimension diagnostic, read twice
  4. Where authority is actually stored
  5. What to measure — and which metrics will lie to you
  6. A defensible twenty-four to thirty-six month arc
  7. 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.

01

Ownership transfer

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

02

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.

03

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.

DeliverWhich delivery decisions still route through me? Pricing exceptions, discounts, quality overrides, delivery-date promises.
DemandHow much of the pipeline is owner-relational — my network, my reputation, my seat on the association board?
CapacityWho actually protects flow when things go wrong at night, on a weekend, in a crisis?
CapabilityWhat critical know-how is tacit and lives only in my head?
OrganisationWhere 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.

01

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.

02

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.

03

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 latencywith and without the owner in the room — the gap should close
  • Owner-untouched decisionslive decisions you have not joined in ninety days
  • Reversibility testthree months absent without key indicators drifting
  • Candor readingspoliteness is not evidence of health; candor is
  • Learning velocityhow fast retrospectives close without you blessing them
  • Role-borne relationshipskey 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.

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

BPMN in Traditional Transformation vs. the 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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

MENSCHGEIST · PIERRE E. NEIS

The Adaptive Organization Credo

What I believe about designing organizations that can keep learning.

I have spent my practice with teams, executives, and systems that were told they were “agile” while remaining unable to adapt. Out of that work, a set of beliefs has taken shape — beliefs I am willing to stand behind, regardless of the method, framework, or vocabulary an organization has chosen.

Four Beliefs

Where I stand, and what I stand against.

  1. I believe in adaptive systems, not compliant frameworks.

    A team can follow any method perfectly while the surrounding organization stays rigid. The coherence of the whole system matters more than the correctness of any single practice.

  2. I believe in decision flow, not process flow.

    Value cannot move faster than decisions. Making authority, ownership, and escalation visible matters more than optimizing tickets, ceremonies, and cadences.

  3. I believe in transformation, not change.

    Renaming roles, rearranging teams, and adding rituals are surface moves. What matters is a shift in identity, decision rights, culture, and operating logic — not cosmetic reorganization.

  4. I believe in candor, not politeness.

    Nice meetings can hide misalignment. Substantive truth-telling — including surfacing what usually goes unsaid — matters more than the surface civility that keeps systems stuck.

Twelve Convictions

The working principles behind the beliefs.

  1. Diagnose before you prescribe.

    Read the organization as a whole system — its purpose, its constraints, its history — before choosing an intervention.

  2. The organization is the design object.

    Purpose, governance, structure, culture, and how work actually flows are what we design. Tools, methods, and rituals serve them.

  3. Decision rights must be explicit.

    Every recurring tension is a signal that authority, ownership, or escalation is unclear. Name it — don’t route around it.

  4. Autonomy is proportional to consequence.

    Reversible, contained decisions belong close to the work. Irreversible or far-reaching decisions require shared awareness and boundaries.

  5. Direction, strategy, and action form one loop.

    Leadership answers why and toward what; strategy is the shared plan; action belongs to the people closest to the work. Break the loop and adaptation dies.

  6. Strategy is translated locally.

    Execution is translation — from broad intent into the specific questions, trade-offs, and feedback loops that guide distributed decisions.

  7. A team is more than a label.

    A team exists when it has a shared purpose, meaningful authority, a real value contribution, and the right to fail cheaply and learn. Anything less is a group of people with a name.

  8. Informal networks are evidence, not noise.

    Change moves, stalls, or mutates through relationships and trust. Read them; they tell the truth that org charts hide.

  9. Human sense-making is not delegable.

    Tools, data, and increasingly capable agents can inform decisions, but accountability, ethics, and meaning remain with people.

  10. A system needs regulation as much as delivery.

    Producing output is not the same as sustaining the capacity to produce. Coordination, feedback, and identity need attention alongside execution.

  11. Stability is a means, not an end.

    Structures — teams, roles, processes — should be reshaped when the situation asks for it. Preserving form at the cost of function is a quiet failure.

  12. Every intervention is a hypothesis.

    Diagnose, try, sense, adjust. The organization is never “done” — the ability to keep learning is the real deliverable.

Pierre E. Neis

Menschgeist · Agile Organization

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?

Executive Summary

Internal coaching supervision for agile leaders presents a set of challenges that are structurally different from external coaching supervision. When a coach operates inside an organization — whether as an embedded agile coach, a leader-as-coach, or an internal AO practitioner — the layered power relationships of hierarchy, role ambiguity, organizational loyalty, and confidentiality create tensions that can undermine both the quality of coaching and the psychological safety of all parties. This report identifies the unique challenges, maps the dominant power dynamics at play, and provides practical frameworks and strategies to navigate them effectively.


Why Internal Coaching Supervision Is Uniquely Complex

Internal coaches operate in dynamic, constantly changing organizations and face multiple unique challenges not common to external coaches. The core structural tension is the dual role: the internal coach is simultaneously an employee and a coach, which creates inherent conflict around confidentiality, neutral positioning, and organizational loyalty — especially when the organization’s priorities conflict with individual client needs.

For agile leaders specifically, this complexity is amplified. They are often “stuck in the middle,” holding simultaneous pressure from executives above who expect delivery and alignment, and from teams below who need psychological safety, empowerment, and autonomy. Adding a supervision relationship to this structure introduces yet another layer: who holds power over whom, and in whose interest does the supervision serve?

Without proper supervision support, these dynamics lead to predictable failure modes: loss of perspective, enmeshment in organizational conflicts, erosion of coaching quality, and ultimately burnout.


The Power Dynamics at Play

1. Hierarchical Power

Even when an agile coach or leader-coach has no formal authority over a supervisee, their organizational rank creates implicit power. Supervisees may withhold sensitive cases, avoid bringing “failure” stories, or self-censor when they fear that information will circulate in performance evaluations, team assignments, or leadership assessments.

The supervisor’s rank — whether they are a senior leader, an organizational development expert, or a designated internal coach supervisor — carries inherent authority that can “lead to anxiety on the part of the supervisee, and even fear”. The risk is that supervision becomes an evaluative relationship rather than a reflective one, shutting down the very vulnerability that makes supervision valuable.

2. Dual Relationships and Role Confusion

Coaching within the same organizational system heightens power dynamics even when formal authority does not exist. When an agile leader coaches their own team members and simultaneously receives or provides supervision, multiple relationship layers overlap. Supervisees may be unsure which “hat” is being worn — colleague, coach, supervisor, or peer — leading to confusion, mistrust, and compromised safety.

Dual relationships introduce specific risks:

  • Blurred boundaries: Harder to keep interactions within the contracted scope of the coaching or supervision relationship.
  • Conflicts of interest: The agile leader’s organizational role may unconsciously influence how they coach or what they bring to supervision.
  • Loss of objectivity: Pre-existing knowledge of colleagues or organizational politics makes neutral presence difficult.
  • Unconscious games: Leader-coaches are susceptible to parent-child dynamics with team members, which can replicate in the supervision relationship itself.

3. Confidentiality Under Organizational Pressure

Confidentiality is both a practical and ethical challenge in internal supervision. Clients (coachees or leaders in supervision) may reasonably question whether their reflections could influence promotion decisions, performance reviews, or team restructuring — even if the supervisor has no formal mandate to share information.

The question is not only “what is kept confidential” but “is absolute confidentiality even possible inside an organization?”. When supervision is embedded in an internal coaching program, there is often an implicit expectation from the organization (sponsor) that some accountability information will flow back. Without explicit contracting, this ambiguity corrodes trust and safety.

4. Systemic Enmeshment and Loss of “Balcony” Perspective

Internal agile coaches and leaders risk becoming so entangled in the organizational system that they lose the “balcony view” necessary for effective coaching and supervision. This manifests as:

  • Normalization of toxic dynamics (accepting dysfunction as “just how things work here”)
  • Unconscious collusion with leadership narratives that serve the organization at the expense of teams
  • “No-one speaking truth to power,” where coaches internalize a culture of silence around senior-level bullying or political behavior

The longer the coach is embedded in the system, the more their perception becomes shaped by the system’s own assumptions, making the external supervisor (or external supervision element) essential.


Key Challenges in Practice

ChallengeInternal ContextSupervision Risk
Dual loyaltyCoach serves both organization and individualSupervision colluded into organizational agenda
ConfidentialityInformation circulates within same systemCoachees self-censor; cases not fully explored
Power imbalanceSupervisor may be senior in hierarchySupervisee withholds vulnerability; fear of evaluation
EnmeshmentCoach absorbed into system dynamicsBlind spots normalized; balcony view lost
Role confusionMultiple hats worn simultaneouslyBoundaries erode; psychological safety compromised
Ethical ambiguityNo clear separation between coaching, management, consultingStandards drift; harm risk increases

Strategies for Navigating Power Dynamics

1. Name the Power Dynamic Explicitly

The first and most important step is to make power dynamics visible rather than leaving them latent. At the start of a supervision relationship, the supervisor should explicitly acknowledge:

  • The natural hierarchy within the relationship and what it does or does not imply
  • How the supervisor and supervisee feel about sharing vulnerable or uncertain topics in this organizational context
  • Moments when the supervisor recognizes they are “leading” rather than co-exploring

Naming the dynamic removes its invisibility and creates space for open, honest dialogue. This is a relational act, not a procedural one: it must be revisited regularly, not just stated once at contracting.

2. Invest Deeply in Tripartite Contracting

Arguably, the most common cause of problems in organizational coaching — and therefore in supervision — is a mismatch of expectations at the contracting stage. For internal coaching supervision involving agile leaders, a tripartite contract between supervisor, supervisee-coach, and organizational sponsor is essential.

The C.O.N.T.R.A.C.T. model offers a structured map:

  • C – Context & Purpose: Why is supervision happening? Who commissioned it and why?
  • O – Outcomes & Objectives: What does the supervisee-coach want to develop?
  • N – Norms & Ethics: Which ethical framework applies (ICF, EMCC, AC)? How will ethical dilemmas be handled?
  • T – Terms & Practicalities: Frequency, format, duration, virtual or in-person
  • R – Roles & Responsibilities: What does the supervisor do? What does the supervisee bring?
  • A – Agreements on Confidentiality: What is shared with the sponsor, and in what form?
  • C – Closure: What are the review points and exit conditions?

In the three-way contracting meeting with the organizational sponsor, key commitments to establish include: that the supervisor will not provide performance feedback to the sponsor unless explicitly agreed with the supervisee; that coaching insights will not be used in evaluations; and that the sponsor’s role is support, not oversight.

3. Use the 7-Eyed Model as a Systemic Navigation Tool

The Seven-Eyed Model (Hawkins & Shohet) is one of the most widely used frameworks in coaching supervision and is directly applicable to agile leadership contexts. It offers seven lenses through which to examine what is happening in the supervision space:

  1. The client and their story — What is the coachee (the agile team or leader) actually bringing?
  2. The coach’s interventions — How is the agile coach/leader working with the situation?
  3. The coach–client relationship — What dynamics exist between coach and coachee?
  4. The coach’s own process and feelings — What is being triggered in the supervisor?
  5. The supervisory relationship — What is happening between supervisor and supervisee right now?
  6. The supervisor’s own process — What is the supervisor bringing from their own system?
  7. The wider organizational context — How is the organizational system shaping everything above?

For agile leaders, Eye 7 (the organizational system) is particularly important and often under-examined. Using this lens helps supervision avoid being only a “case clinic” and instead examines how structural power, culture, and transformation pressures shape both the coaching work and the supervision conversation.

4. Separate Supervision from Performance Management

A clear structural distinction must be made between supervision (developmental, reflective, confidential) and performance management (evaluative, organizational, hierarchical). Without this separation:

  • Internal coaches will self-censor and bring only “safe” cases to supervision
  • The supervision space becomes contaminated by organizational politics
  • Ethical dilemmas will not surface until they become crises

In practice, this means the supervisor should hold no formal evaluative power over the supervisee in the organizational hierarchy. Where this is not structurally possible — as in many lean agile organizations — the supervisor must make the developmental intent of supervision explicit through contracting, re-contracting regularly, and modeling the humility and vulnerability they wish the supervisee to bring.

5. Introduce External Supervision as a Complement

For cases involving toxic dynamics, conflicts of interest, or deep enmeshment, external supervision is often the most responsible option. External supervisors bring:

  • A fresh, independent perspective untainted by organizational history
  • Ability to challenge assumptions that internal supervisors may share
  • A safe container for ethical dilemmas that are “forbidden to discuss with a colleague”
  • Accountability and quality assurance outside the organizational reporting structure

A blended model — internal group supervision for routine developmental reflection, plus periodic external individual supervision for high-complexity cases — offers both accessibility and independence.

6. Build Psychological Safety Through Preparation and Co-Creation

Group coaching supervision in agile contexts faces particular challenges: differences in coaching styles, personalities, cultural nuances, and power differences between participants can lead to conflict, misunderstanding, and rupture. Strategies to address this include:

  • Psychological contracting at setup: Establish clear ways of working, including confidentiality norms, respect, and active listening, before any case work begins.
  • Surfacing rank and privilege: Explicitly discuss whether power, rank, or organizational proximity may be affecting participation.
  • Preparation rituals: Ask supervisees to reflect on their practice, identify a challenge, and set a session intention before each meeting.
  • Regular feedback loops: Build in structured feedback — not only on cases, but on the group’s own dynamics and the supervisor’s facilitation.

7. Model Supervisory Reflexivity

Supervisors have a responsibility to model how power can be used constructively. Supervisors who demonstrate humility, curiosity, and openness — including naming their own uncertainties and blind spots — create permission for supervisees to do the same. This is especially important in agile cultures that espouse transparency and learning but often struggle to enact these values at the leadership level.

The supervisor of supervisors (meta-supervision) dimension is equally important: supervisors of internal agile leader coaches should themselves receive supervision, ensuring that the reflective practice loops outward rather than terminating at the internal layer.


Specific Risks in Agile Transformation Contexts

Agile transformations add layers of complexity not present in standard organizational coaching:

  • Framework pressure: Agile leaders are expected to adopt and role-model specific practices (Scrum, Kanban, OKRs). Supervision cases may be unconsciously filtered through “are we doing agile right?” rather than “what is this person actually needing?”
  • Sponsor–coach collusion: An agile coach acting as internal supervisor may reinforce an organization’s agile “story” rather than challenging it, especially when the transformation is tied to the coach’s own professional identity or the AO Method being implemented.
  • Restorative underinvestment: Agile transformations are high-pressure; the restorative function of supervision (processing stress, role conflicts, emotional load) is often neglected in favor of the formative function (skill building). This increases burnout risk.
  • Ethical ambiguity in hybrid roles: An agile leader simultaneously coaching team members, attending retrospectives, writing performance reviews, and influencing roadmap priorities cannot maintain clean coaching boundaries without explicit, ongoing contracting.

Recommendations for AO Method Practitioners and Internal Agile Leaders

  1. Contract explicitly for power: At every new supervision relationship, name the organizational power hierarchy and agree on what it does and does not mean for the supervision space.
  2. Adopt a systemic model: Use the 7-Eyed Model or equivalent to ensure supervision addresses the organizational context, not only the coach–coachee dyad.
  3. Separate evaluation from reflection: Ensure that the supervisor holds no evaluative function over the supervisee in the same period and context as the supervision relationship.
  4. Use tripartite contracting: Always involve the organizational sponsor in initial contracting to align expectations on confidentiality, outcomes, and accountability — and document agreements explicitly.
  5. Blend internal and external supervision: Reserve internal supervision for formative and peer-reflective work; use external supervision for restorative, ethical, and high-complexity cases.
  6. Revisit contracts regularly: Power dynamics, organizational contexts, and role configurations shift continuously in agile organizations; supervision contracts must be living documents, not one-time agreements.
  7. Model vulnerability from the top: Leaders who receive and are transparent about their own supervision involvement normalize reflective practice and signal genuine commitment to psychological safety across the system.

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.

Politeness, Candor, and Feedback — AO Paper

Long-form insight paper

Politeness, candor, and feedback in adaptive organizations.

This page turns the paper into a readable editorial experience with a Swiss-modern consulting aesthetic: restrained, precise, and built for executive reading.

Executive summary

Why this paper matters

Many organizations confuse politeness with maturity, health, or alignment. In practice, politeness is a social coordination device, while truth is a question of whether relevant reality becomes discussable in time.

This distinction matters in transformation work because polite systems often hide risk, delay escalation, and weaken learning. Adaptive organizations need a design that protects dignity without suppressing candor.

Section 01

The assumption: politeness does not guarantee truth

Politeness and truth belong to different domains. One regulates social friction; the other regulates epistemic quality. A team may therefore appear composed, collegial, and professional while still failing to surface disagreement, error, or structural tension.

For leaders, the practical question is not whether the atmosphere feels smooth. It is whether the organization can process inconvenient signals before they become expensive consequences.

Section 02

Radical candor as disciplined respect

Radical candor is useful precisely because it refuses the false choice between kindness and challenge. The aim is neither aggression nor soft avoidance, but direct feedback delivered in a way that preserves dignity and improves usefulness.

When care lacks challenge

People protect feelings in the short term but leave capability gaps untouched. This usually feels humane in the moment yet often creates delayed frustration and mistrust.

When challenge lacks care

People hear contempt rather than commitment. The information may be technically correct, but the receiver experiences it as status threat rather than developmental support.

Section 03

Cognitive bias inside feedback conversations

Feedback is difficult because the brain does not process it as neutral data. It quickly entangles feedback with identity, competence, fairness, and belonging. Once that happens, bias shapes both how feedback is given and how it is interpreted.

  • Givers often distort through confirmation bias, attribution error, and courtesy bias.
  • Receivers often distort through negativity bias, self-serving bias, and belief perseverance.
  • The conversation itself becomes a fragile social arena where meaning and self-protection compete.

Section 04

Design feedback loops, not heroic conversations

Receiver bias cannot be removed, but it can be bounded by process. Organizations learn better when feedback is behavior-based, routine, multi-source, and framed as joint hypothesis testing rather than personal verdict.

That means using evidence, separating observation from interpretation, inviting the receiver’s meaning-making, and looking for patterns across time rather than overreacting to single episodes.

Section 05

Psychological safety in performance reviews

Performance reviews are especially sensitive because they combine evaluation, hierarchy, and future consequences. Without psychological safety, the review becomes a ritual of impression management instead of a learning device.

What increases safety

Transparent criteria, year-round conversation, specific evidence, employee voice, and leaders who model vulnerability.

What destroys safety

Ambiguous standards, surprise judgments, diplomatic vagueness, one-way verdicts, and punitive reactions to dissent.

Section 06

Operating principles for healthier feedback cultures

Respect people, test interpretations

Protect dignity while keeping assumptions discussable.

Prefer evidence over labels

Evidence invites inquiry; labels trigger defense.

Make feedback routine

Frequent lightweight loops reduce emotional overload.

Build two-way accountability

Leaders must receive feedback, not only administer it.

Design for bias

Use multiple perspectives, reflection prompts, and recalibration points.

Translate truth into learning

The organizational task is not harmony alone, but usable adaptation.

The central proposition is simple: organizational adaptability depends less on surface harmony than on the system’s capacity to convert uncomfortable truth into shared learning.