How to Use Constraints to Enable Self-Organising Teams

A manager tells a team that it is now empowered to organise its own work.

Task assignments stop. Employees are encouraged to take ownership, make decisions and move faster without waiting for instructions.

Then the questions begin.

Which decisions belong to the team? What outcome is it responsible for? How much can it spend? Can it change an established process? When must it involve legal, security or senior management? What happens when its priorities conflict with another team’s?

None of this has been clarified.

The most forceful person gradually becomes the unofficial manager. Other employees hesitate because they do not know where their authority begins or ends. Decisions stall, disagreements grow and the original manager eventually resumes control.

The organisation concludes that self-organisation failed.

In reality, the team received freedom from instructions without a usable environment in which to exercise that freedom.

Self-organising teams do not succeed because leaders remove all structure. They succeed when leaders establish enabling constraints: boundaries that protect essential outcomes and risks without prescribing every action the team must take.

What Self-Organisation Really Means

A self-organising team is not a leaderless group in which everyone does whatever they prefer.

It is a team that can arrange its work, distribute responsibilities, solve operational problems and adapt its methods without requiring a manager to direct every routine action.

Much of the formal language around self-organising and self-managing teams comes from software and product development. The principles behind the Agile Manifesto state that “the best architectures, requirements, and designs” emerge from self-organising teams. The Scrum Guide uses the related term self-managing for teams that decide internally who does what, when and how.

These frameworks do not prove that every practice transfers unchanged to support, retail, healthcare or professional services. The underlying design problem, however, appears across industries: how can operational judgment be distributed without losing direction, accountability or coordination?

Autonomy also exists in degrees. A team may control its workflow without controlling its budget. It may decide how to achieve an outcome without setting the organisation’s wider strategy.

The goal should not be maximum autonomy for every team. It should be an appropriate decision-making mandate for the team’s purpose, capabilities and effect on the wider system.

What Is an Enabling Constraint?

An enabling constraint protects an important outcome, risk boundary or coordination need without prescribing the exact actions a team must take.

A football match offers a useful analogy, although it contains more than one kind of constraint.

The field and objectives create a coherent space for play. Specific rules prevent unacceptable actions. Within that structure, players retain substantial freedom over movement, passing and tactics.

The structure makes coordinated play possible without determining every move in advance.

The Cynefin tradition distinguishes enabling constraints, which support varied and emerging behaviour, from more rigid governing constraints used when actions need to remain predictable. In organisational practice, both may be necessary: safety or legal rules may need to be firm, while operational methods can remain adaptable.

A useful constraint therefore removes unnecessary uncertainty without removing necessary judgment.

1. Define a Clear Outcome

Teams cannot organise intelligently around vague instructions such as:

• Be more innovative.
• Improve performance.
• Take greater ownership.
• Work more efficiently.

These statements express a preference without defining a problem.

A useful outcome explains:

• Who should benefit
• What should improve
• Why the result matters
• How progress will be recognised
• Which important trade-offs must not be ignored

Compare these two instructions:

Improve customer retention.

And:

Reduce preventable cancellations during customers’ first 60 days without using misleading sales practices or creating an unsustainable increase in support workload.

The second outcome gives the team a direction and two meaningful boundaries. It does not dictate the solution.

The team might improve onboarding, revise communications, change a handover process or investigate a product defect. Leadership defines the result without pretending to know the best route in advance.

A clear outcome also gives team members a basis for resolving disagreement. Instead of asking whose preferred method should win, they can ask which option is most likely to advance the agreed result.

2. Establish Decision Rights and Risk Boundaries

Telling people they are empowered means little unless they know what they are empowered to decide.

Clarify:

• What the team can decide independently
• What requires consultation
• What must be communicated afterwards
• What requires formal approval
• Which conditions demand escalation

For example:

• The team may choose its workflow and distribute tasks internally.
• It may revise customer messages within legal and brand standards.
• It may run experiments costing up to an agreed amount.
• It must consult security before changing access controls.
• It must escalate decisions that create significant regulatory exposure.

This can be made even clearer by separating decisions into three categories:

Independent: The team can decide and act.

Conditional: The team can proceed after consultation or review.

Prohibited: The action falls outside the team’s authority.

Some boundaries must remain firm. Depending on the work, these may cover safety, law, data privacy, cybersecurity, ethical conduct, financial exposure or essential customer promises.

The mistake is not creating non-negotiable rules. It is treating nearly everything as non-negotiable.

MIT’s Center for Information Systems Research describes decision-rights guardrails as enabling constraints that allow teams to act while remaining aligned with company-wide interests. Its four guardrails concern organisational purpose, accessible data, minimum viable policies and appropriate resources.

Decision rights should be explicit enough that the team and its stakeholders share the same expectations. Unwritten vetoes turn supposed autonomy into a guessing game.

3. Provide Information and Resources

Authority without information produces poorly informed autonomy.

A team cannot make responsible decisions when important knowledge remains locked inside management reports, specialist departments or disconnected systems.

Depending on its purpose, it may need access to:

• Customer behaviour and feedback
• Financial limits
• Operational performance
• Quality measures
• Previous experiments
• Technical constraints
• Relevant risks
• Cross-team dependencies

Information must also flow in the other direction. Teams should make significant assumptions, decisions, experiments and results visible to the wider organisation.

This does not require constant reporting. A concise decision record, a few meaningful measures and visible risks may be enough.

Resources matter just as much as information. A team cannot reasonably be held responsible for an outcome when it lacks the time, skills, tools, staffing or budget needed to influence it.

Constraints define the team’s operating space, but they cannot compensate for chronic understaffing, missing capabilities, low trust or an outcome the team has no realistic power to change.

4. Use Capacity Limits to Create Focus

Time, money and attention are constrained whether leaders acknowledge that fact or not.

Calling ten priorities urgent does not give a team the capacity to pursue all ten. It merely forces employees to make hidden trade-offs while pretending everything remains equally important.

Useful capacity constraints can include:

• A fixed experimentation budget
• A limit on concurrent initiatives
• Protected time for improvement work
• A maximum number of unresolved cases
• Defined access to specialist support
• A deadline for testing an initial approach

Work-in-progress limits are a familiar example. The current Kanban Guide requires a clear definition of how work in progress is controlled as part of managing the flow of value. Limiting active work can help a team focus on completing existing commitments before starting more.

A capacity limit should encourage prioritisation rather than make success impossible.

When the assigned work consistently exceeds the available capacity, leadership must resolve the conflict. Transferring an impossible collection of priorities to the team is not empowerment.

5. Clarify Team Boundaries and Interfaces

A team cannot operate autonomously when it depends on several other groups for every meaningful action.

Leaders should clarify:

• What the team owns from beginning to end
• Which capabilities are provided by others
• How requests are submitted
• What response can reasonably be expected
• Which shared standards apply
• How competing priorities are resolved
• When closer collaboration is needed

Self-organisation does not mean isolation. A team remains part of a larger system, and its choices may affect shared technology, customer promises, compliance obligations and the workload of colleagues elsewhere.

Team Topologies defines three interaction modes:

• Collaboration: Teams work together for a defined period to discover or create something.
• X-as-a-Service: One team provides a service that another consumes.
• Facilitation: One team helps another develop a capability or overcome an obstacle.

Naming the relationship helps both teams understand whether they are jointly exploring a problem, consuming an established service or receiving temporary assistance. It can also expose dependencies that would otherwise remain an undefined collection of meetings and negotiations.

6. Review the Constraints

Constraints should not be established once and treated as permanent.

A sensible boundary may become unnecessary after risks, technology or team capabilities change. A broad decision right may need to be narrowed if its consequences become more serious than expected.

Teams and leaders should periodically review:

• Results
• Unexpected consequences
• Workload
• Emerging risks
• Cross-team effects
• Whether the team has enough authority
• Whether each constraint still serves its purpose

The Agile principles explicitly call for teams to reflect regularly and adjust their behaviour. Scrum similarly relies on inspection and adaptation rather than assuming the initial design will remain correct.

Each important constraint should have:

• A clear purpose
• A person responsible for maintaining it
• A way to observe its effects
• A review date or trigger
• A method for challenging or changing it

A boundary that cannot be questioned eventually becomes bureaucracy, even when it began as a sensible safeguard.

A Practical Example: A Customer-Support Team

Imagine that a support department wants to reduce the number of customers who must make repeated contact about the same issue.

Leadership establishes the following operating environment.

Outcome

Reduce repeat contacts while maintaining customer satisfaction and avoiding an unsustainable increase in employee workload.

Decision rights

The team may alter its internal workflow, redistribute responsibilities, revise response templates and run limited improvement experiments.

Risk boundaries

It may not bypass privacy, identity-verification, refund or regulatory requirements.

Information and resources

The team receives access to repeat-contact data, customer feedback, quality reviews and product-defect reports. It also receives a small technology budget and scheduled access to a product specialist.

Capacity

No more than two significant experiments may run at the same time.

Interfaces

Suspected product defects follow a defined route to the product team, with an agreed response expectation.

Review

Every two weeks, the team examines repeat-contact rates, customer outcomes, employee workload and unintended effects.

Leadership does not assign every task or prescribe the solution.

The team may discover that repeat contacts are caused by unclear help content, poor handovers, inconsistent explanations or an unresolved product defect. It then chooses how to investigate and respond within the agreed boundaries.

The constraints do not obstruct autonomy. They make responsible autonomy possible.

Enabling Constraints Versus Controlling Instructions

The difference is not simply the number of rules. It is whether the team retains meaningful choices.

Handling customer complaints

Controlling instruction:

Follow this 14-step script for every complaint and obtain supervisor approval before offering compensation.

Enabling constraint:

Resolve valid complaints fairly, protect customer data, record the reason for compensation and escalate payments above the agreed financial threshold.

The first dictates the method. The second protects essential conditions while preserving judgment.

Choosing technology

Controlling instruction:

Every project must use this tool and follow this exact workflow.

Enabling constraint:

Tools must meet our security, accessibility, interoperability and record-retention standards.

The enabling version may still result in standardisation when one option clearly works best. The difference is that the standard is connected to a necessary outcome rather than imposed as an unexplained preference.

When Constraints Become Micromanagement

Leaders may describe a system as empowering while continuing to control nearly every consequential choice.

Warning signs include:

• The complete method is prescribed alongside the outcome.
• Most exceptions require senior approval.
• Rules conflict or make the outcome unattainable.
• The team is measured on results outside its control.
• A new restriction is added after every isolated mistake.
• Reasonable decisions made within the stated boundaries are later punished.

Ask a simple question:

Does the team still have meaningful decisions to make?

When every acceptable choice has already been selected by leadership, self-organisation exists only in name.

The Manager’s Role Changes Rather Than Disappears

Self-organising teams still need leadership.

The manager’s role shifts away from directing routine activity and towards maintaining the environment in which the team operates.

That includes:

• Clarifying outcomes
• Negotiating decision rights
• Securing resources
• Removing organisational obstacles
• Protecting the team from conflicting priorities
• Coordinating with the wider organisation
• Coaching when needed
• Reviewing results without immediately reclaiming control
• Changing constraints when evidence justifies it

A widely cited study of external leaders of self-managing work teams found that effective leaders worked across the team’s organisational boundary. They built relationships, gathered information, secured support and helped the team gain the resources and cooperation it needed.

Managers must also tolerate reasonable decisions they would not personally have made.

Intervention is justified when a choice crosses an agreed boundary, creates unacceptable risk or exposes a genuine capability gap—not merely because the manager would have chosen a different method.

A Constraint-Design Checklist

Before introducing a new constraint, ask:

1. What outcome, dependency or risk does it address?
2. Would the team understand why it exists?
3. Does it establish a boundary or prescribe the complete method?
4. Is it the minimum constraint reasonably needed?
5. Does the team have meaningful authority within it?
6. Does the team have the information, skills and resources to act?
7. Could it conflict with another expectation or encourage harmful behaviour?
8. When will it be reviewed, changed or removed?

These questions do not guarantee a perfect design. They make it harder to disguise habit, preference or fear as an essential rule.

Freedom and Structure Are Not Opposites

Teams need freedom to use local knowledge, respond to changing conditions and improve their methods.

They also need enough structure to understand what success means, which decisions they own and where responsible boundaries lie.

Removing all constraints creates ambiguity. Adding too many controlling constraints creates bureaucracy.

The leader’s task is not to choose between total control and complete freedom. It is to design a coherent space in which the team can act intelligently, learn from results and coordinate with the wider organisation.

Freedom without boundaries creates confusion.

Boundaries without freedom create compliance.

Self-organisation becomes possible when teams receive enough direction to remain aligned and enough discretion to use what they know.