Why Self-Organisation Fails — and What to Do Instead

"Most teams don't fail at self‑organisation because they lack skill. They fail because no one addressed the power dynamics underneath."

1. The Promise That Keeps Breaking

Self‑organisation is Agile's most ambitious promise. The Scrum Guide describes Scrum Teams as "self‑managing," with no sub‑teams or hierarchies (Schwaber & Sutherland, 2020). The Agile Manifesto privileges "individuals and interactions over processes and tools." Psychological safety — the shared belief that the team is safe for interpersonal risk‑taking (Edmondson, 1999) — is routinely cited as the foundation upon which self‑organisation is built (Thorgren & Caiman, 2019). In theory, everyone agrees: give competent people a clear purpose, remove unnecessary constraints, and they will organise themselves to deliver value. The logic is compelling. The results, frequently, are not.

What Agile coaches actually encounter looks different. Teams that wait for permission before acting on their own ideas. Retrospectives that produce the same themes — "unclear priorities," "too many dependencies," "technical debt" — sprint after sprint, quarter after quarter. Product Owners and developers locked in covert authority struggles that neither side will name. Scrum Masters who remove impediments that the team could address itself. Managers who announce "empowerment" while requiring escalation on any deviation from plan. These are not process problems. They are not solved by better ceremonies, new estimation techniques, or another round of working agreements. They are patterns in how people relate — to each other, to authority, to risk, and to the very idea of shared ownership.

The standard diagnoses are familiar: "The team isn't mature enough." "Leadership doesn't get it." "We need more training." A systematic review of large‑scale Agile transformations found that approximately 90% of included papers were experience reports rather than rigorous research, highlighting how little empirical evidence exists for how to work with these dynamics (Dikert, Paasivaara, & Lassenius, 2016). Juli (2010) identifies a critical paradox in which organisations adopt the terminology of self‑organisation without the philosophy, creating what she calls "the illusion of self‑organizing teams" — structures that claim autonomy while maintaining command‑and‑control in practice. Moe, Stray, and Hoda (2019) document persistent, unresolved tensions between team autonomy and organisational control.

These explanations share a common assumption: self‑organisation fails because something is missing — skill, maturity, leadership support, training. The argument of this article is different. Self‑organisation fails not because something is absent, but because something is present and unnamed: the power dynamics that persist beneath the surface of declared autonomy. The reason self‑organisation breaks down is not that people don't want it. It is that no one has addressed what happens to power when the explicit hierarchy is removed.

2. Power Doesn't Disappear — It Goes Underground

When organisations "empower" teams without changing the reward structure, reporting lines, or decision rights, what actually shifts? The formal hierarchy recedes, but the psychological contracts that governed behaviour under the old hierarchy persist. The unspoken deal remains: "I (manager) won't let you fail or make decisions you're not ready for, and you (employee) won't challenge my way of doing things." This is not a failure of intent. It is a feature of how relational contracts operate.

Hay (1995) distinguishes three levels at which contracting operates: procedural (logistics, schedules, deliverables), professional (scope of work, competence, methods), and psychological (covert expectations, fears, hopes, hidden success criteria). In the author's experience, Agile coaching engagements and Agile transformations routinely contract at the first two levels and almost never at the third. Working agreements say "we start on time" and "decisions stay in the room." Nobody contracts for what happens when someone disagrees with the Product Owner publicly, or when a junior developer's idea contradicts the tech lead's preference, or when the team's definition of success conflicts with the sponsor's. The result is predictable: the engagement proceeds on the basis of explicit agreements while being sabotaged by implicit ones.

Rousseau's (1995) psychological contract theory illuminates this precisely. Psychological contracts are individual beliefs about reciprocal obligations — what I believe has been promised to me, and what I believe I have promised in return. When an organisation says "we are adopting Agile and teams will be self‑managing," different parties hear fundamentally different promises. The sponsor hears: "Teams will deliver faster with less management overhead." The team hears: "We will finally have the freedom to make technical decisions without interference." The Agile coach hears: "I will have a mandate to change how this organisation works." These beliefs are rarely surfaced, let alone reconciled. When they collide — as they inevitably do — each party experiences the other as breaking a promise that was never actually made.

The three‑cornered contract (English, 1975; Hay, 1995) provides the sharpest lens for this dynamic. In any coaching or change engagement embedded within an organisation, there are at least three parties: the practitioner (coach), the direct client (team), and the contracting authority (sponsor, leadership). Each holds expectations, success criteria, and anxieties — and these frequently conflict. When a sponsor says "we want the team to be empowered" while simultaneously requiring weekly status reports and escalation on any deviation from plan, the mismatch is not a bug in the contract. It is the contract, at the psychological level. The sponsor has contracted for the appearance of autonomy with the reality of control. The team has been invited to self‑organise within a system that will punish them for doing so.

The practical consequence is that self‑organisation is attempted on the basis of procedural agreements — new ceremonies, new roles, new board layouts — while the psychological contract remains unchanged. Power has not been redistributed; it has been made invisible. And invisible power is harder to challenge, harder to negotiate, and harder to hold accountable than the explicit hierarchy it replaced.

3. The Symbiosis Trap: Dependency as a Co‑Created Structure

"The team won't take ownership." This may be the single most common complaint in Agile coaching. Scrum Masters remove impediments that teams could address themselves. Product Owners make decisions that teams should own. Technical leads hoard design authority. Meanwhile, team members wait for instructions, ask permission for routine choices, defer to the loudest voice, and complain about lack of empowerment while declining opportunities to exercise it.

Classical Agile coaching responses — "empower the team," "step back," "let them fail safely" — assume the problem is one‑directional: someone is controlling too much, or someone is not stepping up enough. Co‑creative transactional analysis (Summers & Tudor, 2000, 2014) reframes this fundamentally. Dependency is not a team defect. It is a co‑created relational structure in which all parties have a stake.

Schiff (1975) describes symbiosis as a pattern in which two or more people function as if they were one complete person, each discounting complementary ego states. In organisational terms, this manifests as role‑based enmeshment: a manager who over‑functions — doing the thinking, deciding, and protecting — paired with team members who under‑function — waiting, adapting, and complaining. Both sides maintain the arrangement because it delivers psychological payoffs. The manager feels needed, competent, and indispensable — the Rescuer payoff in Karpman's (1968) drama triangle. The team feels safe from failure, free from the anxiety of genuine autonomy — the Victim payoff, or more precisely, the predictability payoff of a known pattern. Both avoid confronting the discomfort of Adult‑to‑Adult negotiation under real uncertainty.

Mellor and Schiff (1975) link this to four passive behaviours: doing nothing, overadaptation, agitation, and incapacitation. These are not character flaws but ineffective problem‑solving strategies maintained by discounting — treating some aspect of self, others, or reality as less significant than it is. A team that says "we can't influence the architecture" may be discounting its own capability, the significance of its perspective, or the possibility that the constraint is negotiable. A manager who says "they're not ready" may be discounting the team's actual competence to preserve her own role as the indispensable decision‑maker.

The self‑reinforcing loop is what makes this so persistent. Symbiosis relies on discounting and passivity, which invite drama roles. Drama dynamics in turn justify the symbiosis — "See, without me stepping in, things go wrong" — and all of it is held in place by system norms around authority and boundaries. Breaking one element without addressing the others produces temporary disruption followed by reversion.

Consider the pattern of the "micromanaging mentor." A team lead reviews all code, attends every meeting, and answers client questions on the engineer's behalf — all framed as support and mentoring. The engineer becomes passive, rarely suggests solutions, and constantly seeks approval. The lead is overloaded. Both are unhappy, but neither changes, because the arrangement delivers reliable payoffs: the lead feels indispensable; the engineer feels safe. The intervention that worked was an explicit dyadic contract: the lead gave explicit permission — "You have my OK to design it your way; even if it's not how I'd do it, that's fine if it meets requirements" — set defined checkpoints rather than continuous oversight, and committed to treating mistakes as learning rather than failure. Crucially, protection was built in: "If something goes wrong, I'll support you and we'll fix it together." Over eight weeks, the engineer's confidence and output grew significantly. But the transition was not smooth — it required the lead to tolerate imperfection and to renegotiate her own professional identity.

Co‑creative TA's distinctive question cuts through the blame that conventional diagnosis produces: "What are we co‑creating that makes rescuing the stable solution?" This question implicates everyone — the rescuer, the rescued, the organisational structures that reward over‑functioning, and the coach who may, without awareness, be participating in the same dynamic.

4. The Stroke Economy: What Gets Recognised Kills What Gets Attempted

"Create psychological safety" has become the most common aspiration in Agile coaching — and perhaps the most frequently misunderstood. Edmondson's (1999) original concept is precise: psychological safety is a shared belief that the team is safe for interpersonal risk‑taking. But in Agile coaching practice, it is often treated as a norm to be declared ("we have a safe space"), a temperature to be measured ("safety check: green, yellow, red"), or a leader behaviour to be modelled ("thank people for speaking up"). These are helpful but insufficient. They address the surface structure of safety while leaving the underlying economy untouched.

Co‑creative TA offers a more structural account through the concept of strokes — units of recognition (Steiner, 1974/1990). Steiner argues that humans need recognition the way they need food, and that in most social environments an implicit "stroke economy" operates: a set of inhibiting rules that restrict the giving and receiving of positive recognition, increase stroke hunger, and drive substitute behaviours — including the pursuit of negative strokes (criticism, conflict, drama) as alternatives to the missing positive ones.

Applied to self‑organising teams, this lens reveals dynamics that norm‑setting cannot reach. Under delivery pressure, teams develop a recognition economy in which certain contributions are visible and rewarded — shipping features, hitting sprint commitments, heroic firefighting — while others are invisible: quality maintenance, defect prevention, mentoring, documentation, emotional labour in cross‑functional negotiation. The stroke economy is not a metaphor. It is observable in who gets mentioned in stand‑ups, who is credited in demos, whose work is treated as interesting versus boring, whose concerns are heard versus dismissed.

When positive recognition is scarce, people pursue substitutes. A developer who never receives recognition for careful code review may resort to public criticism of others' code — a negative stroke, but at least a stroke. A team member who is never acknowledged for raising risks may stop speaking altogether, choosing stroke withdrawal over the vulnerability of speaking into a void. A Product Owner who receives recognition only for throughput will learn to discount quality concerns, regardless of what the working agreement says about "quality built in."

The connection to self‑organisation is direct: a team that is told to self‑organise but receives recognition only for individual output will learn to discount everything that doesn't ship code — including the relational work that self‑organisation requires. Mentoring, conflict resolution, cross‑team coordination, knowledge sharing: these are the infrastructure of self‑organisation. If they receive zero recognition, self‑organisation will not survive the first delivery crunch. The failure is not motivational. It is economic.

5. Three Games That Kill Self‑Organisation

A game, in transactional analysis terms, is not a one‑off conflict. It is a recurring, patterned series of transactions that serves stroke procurement and script confirmation (Berne, 1964). Games persist because they deliver something the system needs — predictability, anxiety management, identity protection. Three games appear with particular frequency in teams that are trying, and failing, to self‑organise.

The co‑creative stance toward games is not to "catch" someone playing a game — which easily becomes another form of blame — but to ask: "What are we co‑creating that makes this game the safest available option?" Games persist because they deliver something the system needs. The intervention is not to expose the game but to understand what it provides and to design alternative ways of meeting those needs.

Erskine and Zalcman's (1979) racket system model provides additional explanatory power: a self‑reinforcing cycle of script beliefs ("nothing ever changes here"), associated feelings (cynicism, resignation), rackety displays (complaints, sarcasm, performative busyness), and reinforcing memories ("remember when we tried X and it was ignored?"). In teams, these show up as culture loops — chronic emotional climates that reproduce themselves regardless of personnel changes, process improvements, or leadership interventions.

The constructive question is what to do about it. The answer is not "better self‑organisation" but a fundamentally different understanding of what self‑organisation requires: not structural rearrangement, but relational infrastructure.

Contract at the psychological level, not just the procedural level. Most Agile teams have working agreements — "start on time," "cameras on," "no interrupting." These operate at the procedural level. Robinson's (2020) cocreative learning contract operates at the psychological level, addressing the relational preconditions that determine whether working agreements are lived or merely posted. Adapted for Agile teams, a psychological‑level contract might include: "We will share responsibility for solving our problems." "We will attend to what is happening between us, not only to task progress." "It's OK to name what isn't working, even if the person responsible is in the room." The shift from procedural to psychological contracting is, in the author's experience, one of the highest‑leverage moves available to an Agile team coach.

Make the three‑cornered contract explicit. The coach facilitates a session with sponsor and team present: "What are you (sponsor) hoping this engagement will produce? What are you (team) hoping it will produce? Where might those hopes be in tension? What would each of you need to see in three months to feel this was worthwhile? And — importantly — what must not happen?" This last question often surfaces the most critical psychological‑level material. Contracting also requires explicit agreement on confidentiality and reporting.

Graduate autonomy with protection. Co‑creative TA explicitly warns against removing support faster than people can build internal capacity. The Delegation Levels Matrix (Appelo, 2011) — mapping key decisions onto a spectrum from Tell to Delegate, completed collaboratively with team, manager, and sponsor, and revised as trust grows — provides a concrete artefact for this process. Coach the team to shift from indirect, passive communication ("things are blocked") to direct request and offer language ("I'm requesting a decision on X by Tuesday"). And crucially, protection must be contracted: what risks will the organisation absorb while the team learns? An intervention that pushes autonomy without contracting for protection is not empowerment; it is abandonment.

Redesign the recognition economy. The stroke audit is a facilitated team exercise that maps what gets recognised, by whom, and what is invisible — and identifies where negative strokes substitute for missing positive ones. Leader re‑contracting follows: specific, observable commitments such as "When someone raises a risk, I will respond with a question before I respond with a decision." And the invisible work that sustains self‑organisation — testing, documentation, cross‑team coordination, mentoring, conflict resolution — must be made visible and explicitly recognised. If these contributions receive zero acknowledgement, self‑organisation will not survive delivery pressure.

7. The Coach in the Field: You Are Not Above This

Co‑creative TA's most distinctive contribution may be its treatment of the coach's own participation. In classical Agile coaching, the coach is positioned as a "servant leader," a "neutral facilitator," or an "impediment remover" — roles that imply detachment from the system's dynamics. Co‑creative TA challenges this directly: the coach is a participant‑observer in the relational field, not above it.

The empowering implication is that the coach's experience — confusion, frustration, the urge to rescue, the pull to take sides — is legitimate data about the field. When the coach feels the pull to "fix" something for the team, the pull itself may reveal that the system is inviting rescue. The sobering implication is that without awareness and discipline, the coach becomes part of the problem. Common entanglement patterns include: the coach as messenger, carrying messages that sponsor and team will not say to each other directly; the coach as scapegoat, absorbing blame when transformation stalls; and the coach as ally, recruited by the team as their champion against management, losing the ability to work the three‑cornered contract.

The primary safeguard is the triangulation audit: "Which conversations are you hoping I will have with the team that you are not willing or able to have yourself?" — asked directly of the sponsor, followed by contracting to create conditions for those conversations to happen directly. Supervision or reflective practice is, in this framework, non‑optional. If the coaching relationship is an active ingredient in the change process, the coach must tend to it with the same discipline applied to any other intervention.

8. Knowing When It's Not Relational

Intellectual honesty requires naming the limits of any framework. The relational lens proposed here adds most value when confusion is maintained by mixed messages, hidden agendas, and covert expectations; when boundary tensions persist despite process improvements; when conflicts are cyclical and identity‑laden; or when the coach feels pulled into rescuer, persecutor, or victim dynamics.

It may not be sufficient when the constraint is purely technical — CI pipeline instability, infrastructure debt, or tooling limitations are not relational problems. When resource scarcity is the root cause, no amount of recognition redesign will substitute for adequate staffing. When the organisation structurally prevents autonomy — governance denies decision rights, compliance requires approval chains — "dependency" may be adapted realism, not a team defect. And when the sponsor's intent is control rather than development, the coaching engagement may be structurally incoherent, and the ethical response may be to renegotiate or exit.

The critical guardrail is this: when a team is "dependent" because it genuinely lacks decision authority, telling it to "take more ownership" is not coaching. It is gaslighting. The responsible move is to diagnose whether the constraint is relational — and therefore addressable through contracting, recognition work, and pattern interruption — or structural — and therefore requiring governance, policy, or resourcing change — and to advocate for the latter when needed. Self‑organisation is a relational achievement that requires structural conditions. Neither alone is sufficient.

9. From Process to Relationship — and Back

Self‑organisation was never just a process design. It was always a relational promise — a different way of working together, more humane, more adaptive, more honest. That promise breaks when we treat autonomy as a structural rearrangement rather than a relational achievement.

The work is not to "empower" teams — as if power were a gift the organisation bestows and can reclaim at will. The work is to make the power dynamics visible, the contracts explicit, the recognition economy honest, and the coach's own participation accountable.

The question is not "how do we get this team to self‑organise?" It is: "What are we all co‑creating that makes dependency the safest option — and what would need to change for a different pattern to emerge?"