Organisations often produce the same outcomes even when nobody wants them. Decisions slow down, promising ideas become cautious proposals, new colleagues learn what not to say and familiar patterns return after every change initiative. This guide asks a practical question: what is repeatedly turning this situation into that outcome?

Quick answer

Constructor thinking helps leaders notice the processes, rituals, habits, roles, technologies and social mechanisms that repeatedly transform something into something else. A constructor is not simply something that influences behaviour. It produces a sufficiently consistent, repeatable transformation to become part of how the organisation works.

Five questions to consider when working with constructors:

  • What outcome keeps being produced?
  • What repeatedly turns the starting situation into that outcome?
  • Does the transformation happen through passage, contagion or presence?
  • What useful stability does this constructor provide, even if its effects are frustrating?
  • Should we maintain, amend, weaken, replace or experiment around it?

The aim is not to label every process a constructor. It is to identify what reliably transforms people, information, decisions or possibilities, then decide whether that transformation is one you want to sustain.

What this guide will help you do

  • Recognise outcomes that are being repeatedly produced.
  • Distinguish a constructor from a process, intention or one-off success.
  • Explore transformation through passage, contagion and presence.
  • Notice formal and informal constructors, including harmful ones.
  • Work through a live challenge using practical self-coaching questions.

From “Why does this keep happening?” to “What keeps producing it?”

When an organisation repeatedly produces an unwanted outcome, leaders often assume that somebody has failed to do what was expected. They communicate the priority again, clarify responsibility, revise the process, provide training or ask people to try harder. Sometimes that is enough. Often the pattern returns. The same meeting turns information into reassurance rather than challenge. The same approval route turns proposals into increasingly cautious versions of themselves. The same induction process turns curious newcomers into people who quickly learn to keep certain questions to themselves. Nobody may have designed these outcomes, yet the organisation produces them with impressive consistency.

Constructor thinking directs attention towards that consistency. Instead of asking only why people behave as they do, it asks what repeatedly transforms the situation. What takes an idea and turns it into an approved project? What turns a new employee into someone who understands how things are really done? What turns a customer complaint into learning, defensiveness or silence? What turns strategic intent into local action? The question is not whether the organisation has a process on paper. It is what transformation actually occurs, repeatedly enough to matter.

What is a constructor?

In the Estuarine Framework, constructors are elements that produce consistent, replicable and reliable transformations. The idea originates in Constructor Theory in physics, where attention is placed on which transformations are possible or impossible and what can bring them about. Dave Snowden adapts the concept for complex human systems. An organisational constructor may itself change as it operates, but it retains enough continuity of identity to be recognisable over time.

This is a practical leadership guide to noticing and questioning constructors. It is not a complete account of Constructor Theory or a substitute for the collective Estuarine Mapping process. The Estuarine Framework continues to develop, so the concepts offered here are best treated as working lenses rather than a settled management model.

In practice, a constructor might be a formal process, a ritual, a habit, a role, a profession, a technology, an artefact or an established way of working. A recruitment process transforms applicants into employees. A professional qualification transforms learners into recognised practitioners. A budget meeting transforms competing requests into funded and unfunded work. An incident review may transform failure into learning, or it may transform failure into defensiveness and blame. A leadership meeting may transform uncertainty into collective judgement, but it may also repeatedly transform uncertainty into false confidence.

The word reliable needs care. Human systems are not machines, and consistent transformation does not mean that every input produces an identical or predictable output. The same starting conditions may lead to different outcomes. Reliability means that there is enough repetition for us to recognise a mechanism at work, not that we have discovered a production line. If new ideas repeatedly become safer and less distinctive as they pass through approval, there may be a constructor worth examining. If that happens only once, we may simply have an event. Constructor is therefore a claim to investigate, not a label to apply casually.

Constraints shape. Constructors transform.

Constraints and constructors are related, and the same organisational feature can have qualities of both. A constraint shapes what is possible, difficult or likely. A constructor repeatedly brings about a transformation. An approval threshold constrains who may authorise spending. The approval process may also act as a constructor by repeatedly turning investment proposals into decisions. A professional role constrains who may perform certain work, while the rituals and expectations associated with entering that role may transform how people think and act.

This is why the distinction should be used as a lens rather than a classification contest. Asking whether something is really a constraint or really a constructor can become less useful than asking two questions: how does this shape the possibilities, and what does it repeatedly transform? In Estuarine Mapping, constraints, constructors and actors are treated as actants, meaning anyone or anything acting in the system. An actant may sit somewhere between all three rather than fitting neatly into one category.

A documented process is not automatically a constructor. If people routinely bypass it, reinterpret it or use it without any consistent transformation, the diagram may describe an intention rather than what the organisation actually produces.

Organisations construct outcomes nobody intended

Leaders naturally pay attention to purpose. What was the policy designed to achieve? What did the programme promise? What behaviour did the leadership team request? Constructor thinking pays equal attention to what is actually and repeatedly produced. Intention and outcome may coincide, but they need not.

Imagine a monthly performance review intended to promote learning and early problem solving. Teams know that poor results attract intense questioning, while good results allow them to leave quickly. Before each review, figures are polished, uncertainties are softened and problems are held back until an explanation is available. The meeting may reliably transform incomplete information into a reassuring account. It is functioning as a constructor, just not the one described in its terms of reference.

This does not mean the participants are dishonest or the meeting is useless. Their behaviour may make sense within the surrounding constraints. Status, time pressure, previous reactions, incentives and relationships all influence the transformation. The useful question is not who corrupted the process. It is what the whole arrangement repeatedly produces and how that differs from what people say it is for.

Formal and informal constructors

Some constructors are easy to see. They have owners, stages, documents, systems and scheduled events. Recruitment, procurement, performance management, audit, governance and promotion processes all have the potential to transform inputs in relatively consistent ways. Technology can strengthen that consistency by making some routes easy and others unavailable.

Other constructors are informal. A story told to every newcomer may teach more about acceptable risk than the official values statement. A habit of discussing difficult issues before a formal meeting may mean the meeting itself merely confirms decisions made elsewhere. The visible process may not be the main constructor. A respected expert can transform how a group interprets an issue through their presence, even when they say very little. A recurring joke may teach people which ambitions are safe to express. A ritual of copying a senior leader into emails may turn uncertainty into escalation.

Informal does not mean weak, and formal does not mean reliable. The practical task is to look for repeated transformation wherever it occurs.

Three lenses for noticing how transformation happens

Current Estuarine guidance offers passage, contagion and presence as three simple prompts for identifying possible constructors. They are starting points for inquiry rather than an exhaustive classification, and they are not boxes into which every constructor must fit.

PassageSomething changes by moving through a process, threshold, sequence or ritual.
ContagionSomething changes as behaviour, knowledge or practice spreads between people.
PresenceSomething changes because a person, role, artefact or possibility is visibly present.

Passage: Transformation through a route

Passage is the easiest mechanism to recognise. Something enters a pathway and is changed by moving through it. A candidate passes through recruitment and induction. An idea passes through evaluation and funding. A complaint passes through triage, investigation and response. A person enters a professional role through training, assessment and ritualised recognition.

The route described on paper may differ from the route that performs the real transformation. A proposal may formally pass through three approval stages, but the decisive transformation happens in an informal conversation before the first stage begins. Ask where the input actually changes. Which thresholds matter? What is added, removed, translated or made acceptable? What can enter the route but never emerge from it?

Contagion: Transformation through spread

Contagion occurs when practices, interpretations or behaviours spread through interaction. People observe what colleagues do, copy what seems successful, adapt language, repeat stories and reinforce local norms. No central designer is required. A way of running retrospectives may spread between teams because it proves useful. Cynicism may spread because it provides social protection. A leader’s habit of asking for contrary evidence may gradually become part of how others prepare decisions.

Not everything that spreads is a constructor. The question is whether the spread repeatedly transforms something. Does peer practice turn inexperienced colleagues into capable practitioners? Does a recurring narrative turn ambiguity into resignation? Does imitation reliably change what becomes normal? Contagion also reminds us that communication is not simply transmission. People change ideas as they carry them.

Presence: Transformation through being there

Presence matters when the existence or visibility of an actant changes behaviour. A camera may alter how people use a space. A senior leader in a meeting may change what is discussed. A recognised expert may change how evidence is interpreted. A dashboard displayed in a shared area may change what receives attention. The effect can occur without a direct instruction.

Presence should not be treated as magical. A leader walking around the workplace is not automatically a constructor. We need evidence of a recurring transformation. Does their presence repeatedly turn open discussion into caution? Does visible participation in safety reviews make reporting more candid, or merely more polished? Does an artefact continue to direct attention after its novelty fades? Observe the effect rather than assuming it.

Constructors can be helpful, harmful or both

Constructors do not carry a moral judgement. A process can reliably produce a useful result. It can also reliably produce delay, defensiveness, conformity or waste. Frequently it does both. A compliance review may protect customers while discouraging experimentation. A strong professional induction may develop sound judgement while making alternative perspectives harder to hear. A rapid escalation process may protect operations while weakening local responsibility.

This makes removal a risky default. A frustrating constructor may be providing coordination, identity, legitimacy, memory or safety. Before dismantling it, ask what useful transformation might disappear with it. Equally, do not mistake stability for value. An organisation can become extremely reliable at producing an outcome it no longer needs.

How to recognise a possible constructor

Begin with an outcome you can observe. Avoid starting with the process you have already decided is responsible. Ask what repeatedly happens, under what conditions and across which situations. Look for recurrence when different people occupy the roles. Notice whether the transformation survives changes in personalities, language or formal structure.

A simple input, transformation and output sequence can help organise your observations, provided you treat it as an inquiry rather than proof. It is an observational aid used in this guide, not a formal Estuarine model or a claim that organisational change is linear:

  • What enters the situation?
  • What happens to it?
  • What tends to emerge?
  • How often does this pattern recur?
  • Where does it work differently?
  • What surrounding conditions support the transformation?

Exceptions are particularly useful. If one kind of proposal survives the approval route with its ambition intact, what is different? If one team turns incidents into learning while another turns them into blame, compare the mechanisms and their surrounding constraints. Difference gives you something to investigate.

Break large constructors into smaller parts

Descriptions such as “the performance management process”, “our culture” or “the leadership team” may be too broad to help. They gather many different transformations into one label and invite disagreement about what the label really means. In Estuarine Mapping, disagreement is a prompt to decompose the actant into smaller coherent elements rather than argue over the correct description.

A performance management process might include the manager’s preparation, the rating conversation, the calibration meeting, the software workflow, the promotion threshold and the stories employees tell one another about ratings. Each may perform a different transformation. One may be difficult to change while another may be relatively easy. Working at a finer level of granularity can reveal where useful movement is actually possible.

Do not decompose indefinitely. The aim is to reach a level at which people can recognise what is happening, examine it without collapsing several mechanisms together and identify a practical point of inquiry.

History and continuity matter

Organisational constructors are not required to remain unchanged. A profession, ritual or process can evolve and still retain continuity of identity. Annual budgeting may acquire new software, different templates and revised decision rights while remaining recognisably the organisation’s budgeting process. A leadership ritual may change format while continuing to perform a familiar transformation.

History matters because constructors often accumulate dependencies. Technology, roles, status, language and expectations develop around them. What appears to be one removable process may be holding together a larger arrangement. Understanding its origin can reveal the problem it once solved, the transformations it made reliable and the reasons people continue to protect it.

Ask whether the constructor is adapting usefully or merely preserving its identity after its purpose has faded. Also ask what else now depends on it. Changing the visible mechanism without attending to those dependencies may cause the old transformation to reappear elsewhere.

Constructors rarely work alone

A recruitment process interacts with labour markets, professional identities, managers’ habits, technology, reputation and informal networks. A decision forum interacts with incentives, reporting lines, previous conflicts and what happens to people who express uncertainty. The reliable transformation may emerge from the interaction rather than any single component.

This is another reason to avoid declaring that one process is the cause. Identifying a constructor is not the same as identifying a root cause. It is noticing one mechanism within the current configuration of actors, constraints and other constructors. Ask what makes the constructor reliable. Which constraints contain or connect it? Which actors sustain it? Which artefacts carry it? What would remain if the visible process disappeared? Decomposing the situation may reveal smaller constructors that can be influenced more easily.

Choosing how to intervene

Identifying a constructor does not mean it should be destroyed. The first question is what transformation it currently performs. The second is whether that transformation remains useful. The third is what else might change if you interfere with it.

These choices should not be treated as a simple sequence from diagnosis to action. In a fuller Estuarine Mapping process, constructors and other actants are examined collectively in relation to the energy and time required to change them. Different groups may judge those conditions differently, and those differences can themselves be informative. The options below are prompts for thinking, not a substitute for creating and interpreting that wider map.

Maintain or strengthenProtect a useful transformation and the conditions that make it reliable.
Amend or weakenChange part of the mechanism or its surrounding constraints and observe the effect.
Replace or createExperiment where an old transformation is harmful or a needed one does not yet exist.

Maintain or strengthen what is useful

Some valuable constructors are informal and vulnerable. A team may have developed a ritual that makes dissent safe. Experienced colleagues may quietly help newcomers translate formal policy into sound judgement. A cross-functional relationship may turn early warning signs into coordinated action. These mechanisms can disappear through restructuring, workload or the departure of one person.

Ask what makes the transformation work and how it might be supported without smothering it. Formalising an emergent practice too quickly can remove the local judgement that made it effective.

Amend or weaken what produces mixed results

Where a constructor produces both useful and harmful effects, wholesale removal may be unnecessary. Change a threshold, alter who participates, introduce a different sequence, remove one approval, vary the information available or change the surrounding incentives. Then watch what happens.

The purpose is not to prove that the intervention was correct. It is to learn which elements matter. A small change can reveal more about the mechanism than a long debate about its design.

Replace or create through experimentation

New constructors cannot simply be declared. A new process, meeting or role may be intended to transform something but will only become a constructor if a reliable transformation develops in practice. Start small enough to observe. Look for useful patterns already emerging. Reinforce what works, adapt what does not and stop what creates unacceptable consequences.

This is different from rolling out a finished solution. You are creating conditions in which a useful transformation might become more consistent while retaining the ability to learn.

Practical self-coaching exerciseOpen the guided questions and reflection spaces

Using this on your own challenge

Choose a recurring organisational outcome. Do not begin with the process or person you believe is responsible. Begin with what you can observe. This exercise can help you form better questions, but it cannot give you an objective map of the system. Other people may see different constructors, transformations and possibilities. Treat those differences as information rather than errors to be corrected.

1. Describe the recurring outcome

  • What keeps being produced?
  • How do I know?
  • Where is the pattern strongest?
  • Where does it happen differently?
  • What would probably continue if nobody intervened?

The recurring outcome I want to understand:

2. Trace the transformation

  • What enters the situation?
  • What happens along the way?
  • What tends to emerge?
  • At which point does the most important change occur?
  • What gets added, removed, translated or made acceptable?

The transformation I can observe:

3. Look beyond the formal process

  • What actually happens rather than what the procedure says?
  • Which habits, rituals or informal conversations matter?
  • What do people learn by watching others?
  • Whose presence changes the situation?
  • Which artefacts or technologies guide behaviour?

The less visible mechanisms I notice:

4. Explore passage, contagion and presence

  • What changes by passing through a route or threshold?
  • What spreads between people?
  • What changes simply because something or someone is present?
  • Do these mechanisms reinforce one another?

The most useful lens here:

5. Examine reliability and exceptions

  • How consistently does this transformation occur?
  • Does it persist when different people are involved?
  • Where does it not happen?
  • What is different in those exceptions?
  • Am I observing a constructor or only assuming one exists?

What the exceptions may be telling me:

6. Notice what it enables as well as what it damages

  • What useful stability does this provide?
  • Who relies on it?
  • What risk does it manage?
  • What might disappear if it were removed?
  • What unwanted outcome does it also produce?

What needs protecting:

What needs changing:

7. Look at the surrounding system

  • Which constraints make this transformation more likely?
  • Which actors maintain it?
  • What history has made it credible or necessary?
  • What other constructors interact with it?
  • What would remain if the visible mechanism disappeared?

The surrounding conditions that matter:

8. Intervene and learn

  • Should I maintain, strengthen, amend, weaken or replace this?
  • What is the smallest useful experiment?
  • What would I expect to notice if the transformation changed?
  • What unintended effects should I monitor?
  • What would I amplify, adapt or stop?

My small intervention:

What I will watch:

Twelve questions for working with constructors

  1. What outcome keeps being produced?
  2. What enters the situation, and what tends to emerge?
  3. What repeatedly performs the transformation, and can it be broken into smaller mechanisms?
  4. What actually happens, rather than what the formal process says should happen?
  5. Does the transformation happen through passage, contagion, presence or a combination?
  6. How reliable is the pattern, where are the exceptions and what alternative explanations remain?
  7. Does it persist when different people are involved?
  8. What useful stability, coordination or protection does it provide?
  9. What do other people see, and which constraints, actors and constructors help sustain it?
  10. What might we lose if we removed it?
  11. Should we maintain, strengthen, amend, weaken, replace or leave it alone?
  12. What small experiment could help us learn how the transformation works?

A final shift in language

Instead of “Why does this keep going wrong?” ask “What keeps producing this outcome?”

Instead of “Do we have a process?” ask “What transformation does the process actually produce?”

Instead of “Who failed to follow it?” ask “What route do people really follow, and why?”

Instead of “How do we communicate the new behaviour?” ask “How might the new behaviour spread and become normal?”

Instead of “Who owns this?” ask “What combination of roles, habits, artefacts and constraints sustains it?”

Instead of “How do we roll out the solution?” ask “What small experiment could help a useful transformation become more reliable?”

The central question remains: What is repeatedly turning this situation into that outcome, and is that a transformation we want to sustain?

A bridge to Actors

Constructors help us see what repeatedly produces transformation, but transformations do not occur without agency, interpretation and interaction. We also need to examine who or what can act with intelligence and intention, how roles and identities shape that agency and why the same person may act differently in different contexts. Those questions take us to Actors. Return to the Estuarine Mapping overview or revisit Working with constraints.

Want some help understanding what keeps producing the same outcome?

Constructor thinking can reveal why a pattern survives changes in people, plans and structures. Sometimes it helps to examine the transformation with someone who can question the formal explanation and notice what the organisation is actually producing.

For one immediate challenge

Bring one recurring leadership problem. We can trace what keeps producing it and identify a practical place to experiment.

For a challenge that needs sustained attention

Work with me over time to examine persistent patterns, test assumptions and develop more useful ways of working.

For your leadership team or organisation

Bring me in to facilitate work on recurring organisational outcomes or train your leaders, managers and facilitators to examine them together.

Choose the level of support that fits the situation you are working through.

Sources and further reading

This guide draws on Constructor Theory and its adaptation within Dave Snowden’s developing Estuarine Framework.

Cynefin.io (no date) Estuarine framework. Available at: https://cynefin.io/wiki/Estuarine_framework (Accessed: 16 September 2026).

Deutsch, D. (2013) ‘Constructor theory’, Synthese, 190(18), pp. 4331–4359. Available at: https://doi.org/10.1007/s11229-013-0279-z.

Snowden, D. (2022) ‘Estuarine mapping first edition’, The Cynefin Co., 7 October. Available at: https://thecynefin.co/estuarine-mapping/ (Accessed: 16 September 2026).

Snowden, D. (2023) ‘Updated Estuarine typologies’, The Cynefin Co., 8 April. Available at: https://thecynefin.co/updated-estuarine-typologies/ (Accessed: 16 September 2026).

Snowden, D. (2024) ‘PAGODA’, The Cynefin Co., 16 September. Available at: https://thecynefin.co/pagoda/ (Accessed: 16 September 2026).