Skip to content

November 5, 2020

Domains of Work and Cynefin: A Primer for the Business Leader

By Jon Smart

Given the importance of taking an optimal approach for the type of work, it is important to understand what agile, lean, DevOps, and waterfall are and their history. People, historically, have spent very little time thinking about or improving how they do what they do.

This is the fourth in a series of posts adapted from the book Sooner Safer Happier addressing these different frameworks.

Approaching Work Based on the Domain of Work

As we’ve seen, product development, unique change, is emergent, not deterministic. The work is filled with unknown-unknowns and acting in the space changes the space. Conversely, a worker making wheels all day long on an assembly line knows when the wheel is built and when it’s not. Likewise an organization processing ten million payment transactions a day. In that context, you want standardized work, not variability.

It’s much harder when each thing you build is unique. Only once the product is built can you realize a better way of building it, or even realize that building something entirely different would better meet the needs of the consumer. In an emergent domain, you want variability to learn and then amplify the experiments that optimize for the desired outcomes.

This means there is no one-size-fits-all way of working. It’s not about Agile-everything or Lean-everything or DevOps-everything. It’s about optimizing the way of working based on the type of work and your unique context.

The Cynefin Framework

In 1999, while working as a management consultant for IBM Global Services, Dave Snowden produced the “Cynefin” (pronounced kuh-nev-in) framework to categorize the different domains in which work today takes place. Named after the Welsh word for “habitat,” the framework provides a model of five domains for problem-solving and decision-making. It is a very useful way to determine when to take an agile approach, a lean approach, or neither.


Figure 0.2 Cynefin (Adapted from Dave Snowden)

Clear: Child’s Play

The “clear” domain of the Cynefin framework is straightforward and has predictable results. This is child’s play. There is no need for a project plan, a sprint, or a backlog. A child knows that if she turns left, then right, then left again, she will arrive at school. The route is the same every day and so is the result. This domain has known-knowns and a best practice. In the UK you drive on the left. In the US you drive on the right. The relationship between cause and effect is clear. In this domain it is possible to sense the situation and the environment (e.g., I’m in the UK), categorize it based on what you know (in this country people drive on the left), and respond by following the rules or applying best practices (set off, driving on the left).

Complicated: Sweet Spot for Lean

The Complicated domain requires more judgment. It is knowable because this activity has been done many times before in this context. However, it’s not child’s play; it requires expertise. There are known-unknowns. The relationship between cause and effect needs analysis or knowledge. In this domain, you sense, analyze, and then respond, applying the appropriate good operating practice. There is good practice here, but there is no best practice. As it is non-trivial, there is still room for improvement, to eliminate waste, to improve quality, and to optimize flow.

For example, an IT firm installing servers in a datacenter; an automotive manufacturer building cars; an investment bank trading and processing equity trades; the HR department onboarding new employees. These activities are knowable because they’ve all been done many times before; however, the work requires expertise, especially when things go wrong. Even then, the failure patterns have been experienced before. This is ordered, repetitive, knowable activity. This is the sweet spot for lean.

Complex: Sweet Spot for Agile

Unique product development takes place in the Complex Domain. This is where there are unknown-unknowns and acting in the space changes the space. Cause and effect can only be deduced in retrospect. Whereas the previous two domains are ordered, this domain is unordered. There is no such thing as best practice or even good practice because activity in this domain is emergent. The best approach here is to probe by running a safe-to-learn experiment to test a hypothesis, to sense the results, and then to respond by amplifying or dampening the experiment.

In the Age of Digital, all software development is unique. You don’t write the same code twice. People don’t know what they want until they see it. You don’t know how you’re going to write it until you’ve written it, and then it needs to be refactored as you realize how it could have been written to be more usable, maintainable, or resilient. Even installing a third-party application, such as an ERP system, is novel: that code has never been installed in that context with those data feeds, those people, and those processes before. Minimizing time to learning is key; fast feedback loops de-risk delivery and enable optimizing for outcomes. This is the sweet spot for agility.

Chaos: Act First

Sometimes decisions have to be made in a domain that is “chaotic.” Knowledge here is less important than rapid action that returns order. We act to establish order, to stem the bleeding; sense where stability lies; and respond to turn the Chaotic into Complex. Like the Complex domain, this domain is also unordered.

The global COVID-19 pandemic is a good example of this domain. With mandated lockdowns in force globally and people required to stay at home, organizations scrambled remarkably quickly to act. That could have been to open up more network connections to enable huge numbers of people to work from home, or in industries such as aviation, automotive, and hospitality to shut down operations, or supermarkets and suppliers working to keep the supply chains operating. There was no time for months of planning and multiple committee-based approvals. Organizations often comment that they are at their best in these situations, with people coming together, irrespective of job role or business unit, working as one multidisciplinary team to quickly address the issue. Most then go back to their previous ways of working. Techniques stumbled upon in Chaos can end up becoming a new good or best practice in the Complicated or Clear domains for business as usual.


The last of the domains in the Cynefin framework is Confused, when it’s not clear which of the domains currently apply. This can be authentic (you’re really not sure, in which case break the situation down into smaller parts) or inauthentic (which means that you are complacently ignoring any distinction and carry on managing Complex situations as if they were Complicated or Clear.)

Work Moves Around Domains

Work is rarely stationary in one domain. For example, the creation of a new product, such as a new model of car, will start in the Complex domain. In an agile manner, there will be customer focus groups, pencil sketches, computer-aided design (or “digital twin” simulation), and eventually a small-scale prototype and wind tunnel testing for quickest time and cheapest cost of learning, avoiding a sunk cost fallacy. At some point there will be a full-size prototype and eventually testing in the extremes of the Sahara and Alaska, all the time making updates to maximize the desired outcomes. Later 100,000 instances of that model are built each year, which is into the Complicated domain. Then there is a shallow dip into Chaos with a recall of certain models due to a fault, some Complex domain experimentation to fix it, and then back into Complicated domain with lean production.

Figure 0.3 Work Moves around Domains

Software benefits from both an agile and lean approach. The software binary is agile-created and the path to production is lean, as the build, test, deploy process should run repetitively and with a high degree of automation many times a day. Periodically there will be step-change agile experimentation in the path to production and then back into lean again. Software is an agile-created box on a lean conveyor belt.

In the last post in this series, we’ll look at how to survive and thrive in the Age of Digital. 

- About The Authors
Avatar photo

Jon Smart

Co-founder and CEO of Sooner Safer Happier, lead author of the award winning and bestselling "Sooner Safer Happier: Patterns and Antipatterns for Business Agility", and Programming Committee member for the DevOps Enterprise Summit.

Follow Jon on Social Media


  • James Gifford Mar 24, 2021 3:32 pm

    Lean has become a vague term in this day and age. I would love the understand which flavor you are referring to.

    • IT Revolution Mar 25, 2021 5:09 pm

      This earlier post from Jon should help clarify his view of lean:

  • Olivier Gourment Nov 30, 2020 1:57 pm

    Great article using Cynefin to contextualize Lean, Jonathan. Was this reviewed by Dave Snowden? I understand he would rather place Agile in the liminal domain between Complex and Complicated. There are other methods to apply in the pure Complex domain. In particular, you mention running one experiment at a time where Cynefin recommends multiple parallel probes (illustrated as //PSR on some representations: ProbeS-Sense-Respond.)

Leave a Comment

Your email address will not be published.

Jump to Section

    More Like This

    Announcing DevOps Enterprise Journal | Fall 2023
    By IT Revolution

    As our longtime audience will know, each year we hold the DevOps Enterprise Forum,…

    Industrial DevOps: Bring Agile/DevOps to Cyber-Physical Systems
    By Suzette Johnson , Robin Yeman

    The following is an excerpt from the book Industrial DevOps: Building Better Systems Faster…

    My Fit Experience: Leaders
    By Lucy Softich

    In previous articles, I've been going through some of the excursions from André Martin's…

    2023 Fall Releases
    By IT Revolution

    We have had quite a year so far, and it only keeps going! As…