The System Domain Effect: Why Coaching One Team Doesn't Shift the Pattern

The new Scrum Master who arrived with the old team

The coach had spent eight months with a development team producing what she considered genuine improvement. The team had moved from status reporting to honest retrospectives, from escalation to direct conflict resolution, from SM-as-meeting-manager to SM-as-facilitator of team thinking. The improvements were real and were visible to the team, to the product owner, and to the engineering manager.

Then the Scrum Master moved to a different team within the organisation. A new Scrum Master joined — technically competent, experienced, certified, and carrying, without knowing it, a complete set of assumptions about what good Agile practice looked like: the SM runs the ceremonies, the SM monitors the velocity, the SM escalates blockers, the SM produces the team health survey. Within six weeks, three of the patterns the team had worked hardest to exit had returned. The new SM was not causing this deliberately. She was doing what her training, her certifications, and her previous experience had told her good Scrum Masters do.

Menzies Lyth and the domain problem

Isabel Menzies Lyth's hospital research identified social defences at the institutional level — the nursing system of a particular hospital. But when she and her colleagues worked across multiple hospitals, they observed something that complicated the picture: the defences were not confined to individual institutions. Similar defensive structures appeared in different hospitals, in different locations, with different management and different staff. The pattern was recognisable across the domain of similar organisations.

This led to an extension of the social defence concept. The defences were not just institutional — they were domain-wide. And because they were domain-wide, consultants who successfully modified the defences in one institution would watch the change erode as staff moved between institutions, carrying the domain's defensive assumptions with them. The institution is embedded in a domain, and the domain continuously reclaims what the institution has changed.

Bain's extension: the system-domain-in-the-mind

Andrew Bain extended this observation into the concept of the system-domain-in-the-mind: the internalised version of the domain's defensive structure that each practitioner carries and reinstalls wherever they go. The domain is not just external — it is internal. The practitioner who has been trained in, certified by, and formed within the domain's shared assumptions does not simply adopt the domain's practices. They become them. When they move to a new organisation, they bring the domain-in-the-mind with them, and they install it in the new context — not through malice or rigidity, but through the simple operation of doing what they know how to do.

This is the system domain effect: the domain reclaims what the institution has changed, through the movement of practitioners who carry the domain's assumptions in their professional identity.

The Agile coaching domain

The Agile coaching world is a domain in precisely this sense. It has shared structures that constitute and reproduce its assumptions: SAFe certification content, ICAgile competency frameworks, Scrum Alliance training, LinkedIn discourse about what good Agile looks like, shared vocabulary (velocity, capacity, sprint goals, psychological safety), shared metrics, and shared job descriptions that specify what a Scrum Master or Agile coach is supposed to do.

These structures create a domain-level defensive system as coherent as any individual institution's. The defensive function is the same: they protect the practitioners of the domain from the anxiety of genuine uncertainty — the uncertainty of not knowing whether their intervention is working, of facing team dynamics they were not trained to handle, of being asked to work with complexity that no framework can navigate.

The domain's defences produce predictability and professional identity at the cost of the kind of improvisational, deep, non-framework-mediated work that the most complex team dynamics require. And they are reproduced through the movement of practitioners, just as hospital defences were reproduced through the movement of nurses.

Five domain-level defences visible in Agile coaching

These are not critiques of individual practitioners. They are descriptions of assumptions so widely shared across the domain that they have become invisible — which is the defining characteristic of a domain-level defence.

Ceremony compliance as the measure of team improvement. The domain assumption that a team is improving Agile practice when it is running its ceremonies correctly. This protects practitioners from the much more demanding question of whether the team is developing its capacity to think and work together — a question that has no framework-provided answer.

Coach responsibility for team performance. The domain assumption that the coach is responsible for whether the team performs well. This manages the anxiety of not being able to control what the team does while being held accountable for results. It also undermines the team's own accountability for its development.

Team happiness scores as the metric of coaching success. The assumption that team satisfaction surveys measure coaching effectiveness. This manages the anxiety of not knowing whether depth work is happening — a process measure substituted for an outcome measure.

External coaching as superior to internal capability. The assumption that an external coach brings something an internal practitioner cannot. This protects both external coaches (whose livelihood depends on it) and internal practitioners (who are relieved of the pressure to develop coaching depth).

The Scrum Master manages the process. The assumption embedded in most SM training that the SM's role is to ensure the process is followed correctly. This manages the SM's anxiety about role authority while systematically preventing the team from owning its own process.

What coaches can do at domain level

The coach working only at team level cannot address domain-level defences. A new hire will arrive carrying them. The certification content will reproduce them. The job description will reinforce them. The LinkedIn post from a respected community figure will validate them. Team-level coaching is necessary and insufficient.

Working at domain level requires operating in the spaces where domain assumptions are formed and challenged. Communities of practice that examine rather than reproduce shared assumptions. Supervision groups that look at domain-level collusion alongside individual practice. Writing and publication that names domain-level defences explicitly. Supervision of other coaches that passes on a different set of assumptions about what the work requires.

None of these are easy. The domain will resist its own examination for precisely the same reasons that individuals resist self-examination — the examination threatens the defensive function. But the coach who understands the system domain effect understands why they need to work at more than one level, and why the team-level work they do so carefully is always in tension with the domain-level assumptions that continue to arrive with each new hire, each certification cohort, and each LinkedIn endorsement of the old way.

The domain will reclaim what you have changed

If you are coaching one team and the team is embedded in a domain with powerful shared defences, your work at team level is necessary but insufficient. The domain will reclaim what you have changed — through new hires who arrive with the domain-in-the-mind, through certification content that reproduces the domain's assumptions, through job descriptions that specify the defended roles, through the LinkedIn discourse that validates the familiar.

This is not a reason to stop coaching teams. It is a reason to understand what team-level coaching can and cannot hold on its own, and to invest some of the practitioner's developmental energy at the level where the most durable change is possible.