Skip to content

July 5, 2021

Cynefin: Four Frameworks of Portfolio Management

By IT Revolution
Cynefin Framework

In this edition of our Four Frameworks of Portfolio Management series, we’ll look at sense making approaches to portfolio management, specifically how to use the Cynefin framework for this purpose.

Sense Making Approaches

During an era of disruption and massive change, business leaders should use multiple cognitive models to evaluate their strategic positioning. Leaders need multiple approaches that help them create opportunities to avoid making the wrong decisions.

When trying to make portfolio and product-offering decisions for a business that generates $500 million in annual revenue, scientific inquiry and complexity science should be used as a sense-making model to complement other analysis. Leaders can use a sense-making model to make better-informed decisions around their beliefs, perceptions, and choices related to their reality and the relationships that are determined to be valid or invalid.

When using a sense-making approach, the goal is to determine one of two things:

  1. Do you have enough data to drive a predictive outcome?
  2. Do you need more data (continuous experiment)?

Steven Spear and H. Kent Bowen, in their famous Harvard Business Review article “Decoding the DNA of the Toyota Production System,” say that Toyota was a community of scientists continually experimenting. This scientific mindset has allowed Toyota to dominate the auto market for over thirty years.

Colin Powell, former Secretary of State and a retired four-star general, has what he calls the 40–70 rule. He says that when you are making impact decisions, you should have no less than 40% of the data and no more than 70% of the data. Having less than 40% of data is not enough and can lead to poor decision making. Having more than 70% of data is too much, and could slow you down and lead to missed opportunities. Gathering the appropriate amount of data requires leaders to apply a cognitive model that frames decisions via continuous experimentation and data.

Cynefin Framework

Cynefin, created by Dave Snowden in 1999, is a decision-making framework for working with complex systems. Cynefin—named after the Welsh word for “habitat”—is designed to assist decision making by applying decisions to domains. This domain structure allows decision makers to understand where they are in a complex adaptive system and what form of experimentation they should be using to make their decisions at that time. Specifically, it helps business leaders understand which specific point in the decision-making process they are in and how to react.

The domains can be used to set a flow of practices that are situated within a specific, current state. This is especially useful when evaluating product investments where products or markets have differing degrees of maturity. For more established products, information upon which decisions can be based (market size, requirements) are well known. For more emerging products, the same information may be unclear or unknown.

The Cynefin framework has five domains, defined as cause and effect relationships.

Cynefin Framework

The five domains of Cynefin are:

Obvious/Clear: This domain is an extremely safe environment with known-knowns and best practices. Everything is documented and has redundant expert resources who can answer questions. Reactions are considered to flow in this order: sense, categorize, respond. One of the qualities of the obvious or clear domain is that the sensing and categorizing have been refined to the point that experts are often not needed to solve these problems. The problem and solution is obvious or clear to almost anyone with common sense. When evaluating decisions in this domain, you might see things like standard work definitions or runbooks. The sense/categorize here means establish what the problem is (sense) and then look up the documented solution (categorize).

Complicated: In the complicated context, experts are understood and the majority of hypotheses are proven with “good practice” processes and methods. The important difference between “good practice” and “best practice” is that “good” is inconclusive. This means that experts may have different views on how to do something. Thus, leaders in this domain can be plagued by the problem of expertise. This is why experiences are classified as unknown-knowns. Reactions are considered to flow in this order: sense, analyze, respond. Experimentation in this domain might be considered linear. Cause and effect relations are guided by expertise. The same process in this domain run multiple times will most likely yield the same results. Things like battle-tested, cloud-platform frameworks are good examples, where the business leaders and the organization have relatively high experience.

Complex: In this domain, there are no experts, but you can find experience. Problems are stated without clarity on their accuracy. Ambiguity is a feature of the problem statement in this domain. The environment is full of unknown-unknowns and requires significant exploration to ask the right questions. Reactions are considered to flow in this order: probe, sense, respond. Situations in this domain are nonlinear and require parallel experimentation. The same process run multiple times in this domain will not yield the same results. The cause and effect relationship requires probabilistic reasoning. Emergent patterns become apparent as people probe the system.

Chaotic: This is an ambiguous territory without practices, knowns, or expertise. Decisions are made minute-by-minute and are only reactions to the unprecedented and unexpected events that unfold. Reactions are considered to flow in this order: act, sense, respond. Unlike decisions made in the complex domain, parallel experimentation is not used. In this domain the key point is that the criteria for making decisions is unclear. It is not possible to determine the “best” decision, and attempts to determine “best” may waste precious time. Think of the beginning of the COVID crisis—countries that decided to isolate quickly fared better. It may not have been the “best” decision, but it was one that bought time for emergence in the complex domain. Essentially, decisions here can force the system to appear and operate clearly, but that mode of operation is usually unsustainable.

Disorder: When you feel lost in the woods and there is no sense of where you belong. Reactions are considered to flow in this order: gather information, identify the domain, move-on.

An important point to understand when evaluating complex systems is that no one system (product of service) lives in one single domain. Complex systems can have different flows across different domains. For example, understanding flow for a smart-device application that has dependencies on a legacy system (e.g., a mainframe system of record) might need to be evaluated by its subsystems. Mainframe systems of record might be obvious and some JavaScript (JS) node front-end code decisions might be evaluated in the complex domain.

The key point is that nothing in any system is static. Cynefin allows us to understand where a component might be at any given time. In fact, a single system or subsystem might actually span across multiple domains. The key thing to understand is that Cynefin is not a classification tool designed to put products and services in a specific domain; rather, it is a sense-making tool for understanding how to react during transitions between domains.

The Cynefin Framework in Action

Here are the four examples of insights provided through Cynefin for the four portfolio examples:

Product A is a highly matured capability that lacks spontaneity and unplanned risk. Most of the decisions for this system will be known-knowns. Most solutions are resolved relatively quickly by a matured knowledge base and set of experts. This subject has a matured purpose and falls in Cynefin’s obvious domain. Some of its process might fall in the complicated domain. Most of the system is highly constrained with a set of predetermined rules, and there is a complacency among new ideas.

Product B sits in the complicated domain and maintains a structure in its problem-solving. Most assumptions are verifiable, and platforms continue to innovate with positive results. Decisions made for Product B are not as obvious as for Product A. There are known-unknowns, meaning there is a set of expertise around the cause and effects.

Products C and D sit in the complex domain and are exploratory and experimental in nature. Leadership cannot expect order and should embrace unordered ambiguity and failure. The technology is breaking new ground for the business, continues to challenge the team’s understanding, and still has unexplored areas of risk. The few experts still don’t know how things will play out, and the near future contains a lot of trial and error. This domain has unknown-unknowns (emergent behaviors), meaning the cause and effect is discovered through parallel experimentation.


With an analysis based on Cynefin, you might find yourself questioning your approach to leadership, technology, measurements, or investment. For example, in the context of enterprise understanding of product investment, moving from the chaotic domain to the complex domain may not respond as effectively to existing organizational structures and processes.

Leaders who recognize these natural movements are able to adapt their styles and ways of working. Movements between domains may also clear out your existing set of assumptions and require you to reset your understanding.

Next, we’ll look at forward looking/predictive metrics when looking to manage complex product portfolios. To read the full white paper, download it here.

- About The Authors
Avatar photo

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

No comments found

Leave a Comment

Your email address will not be published.

Jump to Section

    More Like This

    The Role of the Software Architect in Agile Medical Device Development
    By Summary by IT Revolution

    In a recent presentation at the 2024 Enterprise Technology Leadership Summit Virtual Europe, Tom…

    Calculating the ROI of Flow Engineering
    By Steve Pereira , Andrew Davis

    This post is adapted from the book Flow Engineering: From Value Stream Mapping to Effective…

    What to Expect at Enterprise Technology Leadership Summit Las Vegas 2024

    Holy cow, Enterprise Technology Leadership Summit Las Vegas is happening in August, which is…

    Transforming Telenet’s Operating Model: Insights from a Multi-Year Journey
    By Summary by IT Revolution

    In a recent presentation at the 2024 Enterprise Technology Leadership Summit Virtual Europe, Barbara…