This is the second post in a short series exploring the Scrum Master role through the four main Cynefin domains:
- clear
- complicated
- complex
- chaotic.
The first post looked at the clear domain, where simple rules, checklists and repeatable practice can help.
This post looks at the complicated domain.
What is the complicated domain?
In the complicated domain, the work is not obvious, but it is still knowable.
There may be more than one right answer. The team may need analysis, diagnosis or specialist input before deciding what to do.
This is the world of expertise.
In Scrum, complicated work might include:
- technical architecture decisions
- performance issues
- security concerns
- accessibility audits
- integration problems
- legacy system constraints
- legal, regulatory or compliance questions
- product decisions that need market, data or domain expertise
The work is not simple enough for a checklist.
But it is not completely unknowable either.
With the right people, evidence and analysis, the team can usually work out a sensible way forward.
The Scrum Master’s role
A Scrum Master does not need to be the expert in everything.
That is not the point.
The Scrum Master’s role is to help the team recognise when expertise is needed, create the conditions for that expertise to be used well and stop the team pretending that every problem can be solved by enthusiasm alone.
In the complicated domain, the Scrum Master helps the team move from vague uncertainty to informed judgement.
Help the team slow down enough to think
Complicated work often needs a pause.
Not a long delay.
Not endless discussion.
Just enough time to understand the problem properly.
A Scrum Master might help by asking:
- What do we already know?
- What do we need to find out?
- Who has experience with this kind of problem?
- What evidence would help us make a better decision?
- What risks are we carrying if we guess?
These questions help the team avoid rushing into action before they understand the situation.
Bring in the right expertise
Sometimes the expertise is already in the team.
Sometimes it sits elsewhere in the organisation.
Sometimes the team needs to speak to a security specialist, content designer, architect, accessibility adviser, finance colleague, customer support expert or legal adviser.
The Scrum Master can help by making this normal.
Asking for expertise is not a weakness.
It is responsible practice.
Good Scrum teams do not try to solve every problem in isolation. They know when to involve the right people at the right time.
Protect the team from false certainty
The complicated domain can be dangerous when people act as if the answer is obvious.
A confident opinion is not the same as expertise.
A loud voice is not the same as evidence.
A familiar solution is not always the right solution.
The Scrum Master can help the team notice when it is moving too quickly from assumption to decision.
Useful prompts include:
- What are we basing this on?
- Have we seen this work before?
- What options have we ruled out?
- What might we be missing?
- Who should review this before we commit?
This is not about slowing the team down for the sake of process.
It is about improving the quality of judgement.
Avoid turning expertise into dependency
There is another trap: in the complicated domain, teams can become too dependent on experts.
Every decision gets escalated.
Every uncertainty becomes a request for approval.
Every specialist becomes a bottleneck.
The Scrum Master should help the team use expertise without giving away responsibility.
That might mean:
- inviting experts to refinement meetings
- agreeing decision boundaries
- documenting principles rather than asking the same question repeatedly
- helping the team learn from specialist advice
- turning expert input into reusable guidance
The aim is not to remove expertise. The aim is to help expertise strengthen the team.
Make learning visible
Complicated work often produces useful knowledge.
The team may learn:
- why a technical approach failed
- which integration pattern is safest
- how a policy should be interpreted
- what a customer segment really needs
- where a workflow creates hidden risk
A Scrum Master can help the team capture this learning lightly.
That might be through:
- a short decision record
- a checklist for next time
- a working agreement
- a shared definition
- a note in the product backlog
- a brief retrospective insight
The point is not documentation for its own sake.
The point is to make good judgement easier next time.
What this looks like in practice
In the complicated domain, the Scrum Master may need to help the team:
- pause before committing to a solution
- involve people with relevant expertise
- separate evidence from opinion
- compare realistic options
- make decisions visible
- reduce repeated dependency on specialists
- turn expert advice into shared team knowledge
This is quiet, practical work.
It may not look dramatic. But it can prevent expensive mistakes.
The Scrum Master as a host of expertise
In the complicated domain, the Scrum Master is not the hero with the answer.
- They are the person who helps the right conversations happen.
- They notice when the team needs analysis rather than action.
- They help create space for expertise without letting expertise become hierarchy.
- They protect the team from both over-confidence and over-dependence.
That matters because complicated work deserves care.
Not everything needs a workshop.
Not everything needs an experiment.
Sometimes the team needs to stop, look carefully, ask someone who knows and make a better-informed decision.
