Last week we explored Cynefin as a way of understanding the nature of the problem.
This week we go one level deeper.
Because once you recognise the domain you are in, the next question becomes what is constraining this system?
Most frustration at work is not caused by laziness or lack of effort. It is caused by constraints.
What is a constraint?
In simple terms, a constraint is anything that limits how a system behaves.
Sometimes that limit is helpful.
Sometimes it is harmful.
Often it is invisible.
In productivity terms, a constraint might be:
- limited time
- limited energy
- limited attention
- a dependency on someone else
In agile terms, it might be:
- a single overworked specialist
- a slow approval process
- a fragile deployment pipeline
If you optimise everything except the constraint, you do not improve the system.
You just increase pressure at the bottleneck.
A brief word on the theory of constraints
The Goal by Eliyahu Goldratt popularised the idea that every system is limited by one or more bottlenecks.
The theory of constraints suggests:
- identify the constraint
- exploit it
- subordinate everything else to it
- elevate it
- then repeat
The key insight is uncomfortable: improving non-constraints often makes things worse.
Where Cynefin adds nuance
Cynefin reminds us that not all constraints are the same.
To keep the domains in view, here is the Cynefin diagram before we look at the different types of constraints.
Cynefin distinguishes between different kinds of constraints.
Fixed constraints in the clear domain
Tight or fixed constraints are strict rules or procedures; they offer no degrees of freedom. They can be:
- legal and compliance steps
- safety protocols
- standard operating procedures
They reduce ambiguity.
They create order.
They belong in the clear domain, the domain of best practice.
Governing constraints in the complicated domain
These are policies, guidelines or frameworks.
They guide behaviour without dictating every move.
- architectural standards
- approval processes
- budget rules
Experts interpret and apply them.
Enabling constraints in the complex domain
These are the most interesting. They do not control the system. They create the conditions within which emergence can happen.
Examples:
- sprint timeboxes
- WIP (work-in-progress) limits
- team working agreements
They shape behaviour without prescribing outcomes.
This is subtle but powerful.
In complex systems, you do not control performance. You design constraints that enable adaptation.
A deeper shift
When people hear “constraint”, they often think “problem”.
But in complex systems, constraints are not enemies. They are the boundaries that allow coherence.
A river flows because it has banks. Remove the banks and you do not get freedom. You get a flood… chaos.
The subtle art of coupling constraints
Now, this is where Cynefin gets subtle. When Cynefin talks about tightly coupled, loosely coupled and de-coupled constraints, it is describing how strongly behaviour is controlled.
It is about the strength of linkage between actions and outcomes.
Tightly coupled constraints in the clear domain
When actions and outcomes are tightly coupled, they are rigid and prescriptive.
- actions must happen in a specific order
- deviation is not tolerated
- cause and effect are predictable
They dominate in the clear domain.
Examples:
- safety procedures in aviation
- legal compliance steps
- a fixed manufacturing sequence
Break the rule and something breaks.
These create stability through control.
Loosely coupled constraints in the complicated domain
When actions and outcomes are loosely coupled, they provide guidance rather than strict sequencing.
- there is structure
- there is room for judgement
- variation is possible within limits
They sit mainly in the complicated domain.
Examples:
- architectural standards
- policy frameworks
- budget controls
Experts interpret and apply them.
They shape behaviour without dictating every move.
De-coupled constraints in the complex domain
When actions and outcomes are de-coupled, these are minimal or enabling constraints.
- they do not tightly control action
- they create boundaries within which emergence happens
- outcomes cannot be predicted in advance
They operate in the complex domain.
Examples:
- a sprint timebox
- WIP (work-in-progress) limits
- team values or working agreements
They do not force a specific outcome.
They create the conditions for adaptive behaviour.
Why this distinction matters
In simple systems, tight control increases reliability.
In complex systems, tight control reduces adaptability.
If you apply tightly coupled constraints to complex work, you often get:
- compliance behaviour
- reduced experimentation
- illusions of certainty
The art is not removing constraints.
It is matching the type of constraint to the nature of the system.
That is where Cynefin becomes more than a categorisation tool.
It becomes a design principle for leadership.
Why this matters for agile and productivity
If your work is complex:
- adding more rules will not create certainty
- removing all structure will not create agility
The art lies in choosing the right type of constraint for the domain you are in – fixed, governing or enabling.
That is where Cynefin becomes practical.
Better outcomes often come from changing the constraint, not demanding more effort.
