Cynefin and VUCA
Tools to help you think about how to think about problems 🥴
One of the main aspects of being a knowledge worker is thinking. This is why measuring “productivity” is such a tender and convoluted subject, why it doesn’t equate to 9-5, and why “frameworks” are there to guide you in thinking about stuff, not just blindly followed.
Talking about productivity measurements will likely devolve into ranting about billing you for my time in the shower or walking the dog, so instead today’s post is about thinking about thinking. Or, how to think about which kinds of thinking you need to think before you do any actual doing.
I'll cover two concepts that helped me in evaluating situations: VUCA and Cynefin. No magic bullets, these just help inform what kind of hard work lies ahead. The mental “understanding work” that you need to do before any of the “work work” part of knowledge work.
VUCA
VUCA is an acronym standing for Volatility, Uncertainty, Complexity, Ambiguity. It arose out of the military, an organisation that deals with chaotic SNAFUs and loves acronyms to succinctly communicate level of Fness.
Let’s examine what each element means, and how it’s dealt with:
Volatility refers to how likely and how fast will the situation experience unexpected changes.
Uncertainty is the (un)predictability of events, your confidence in the accuracy of predictions.
Complexity refers to the interconnectedness of factors, and the ability to isolate each.
Ambiguity refers to the lack of clarity about the meaning of events.
In other words, a normal day in the office for most PMs.
Now, some nimble-tongued consultant has come up with an antidote acronym of “Vision, Understanding, Clarity, and Agility” — which are good practices in general, but also directly related to countering the madness of a VUCA world.
In the Product world:
In order to counter rapid changes in the scenery (volatility) you need the agility to change direction quickly. This isn’t the Scrum style rigid “agility”, but the original meaning. Have your finger on the pulse of your industry, customer base, product, et al, and be able to change direction quickly to respond to changing business needs.
To help with uncertainty of the future, you can gather data to inform decisions, hold pre-mortems to figure what could go wrong, and generally continually observe and learn.
Acknowledge complexity by establishing cross-functional relationship inside and outside your organisation. Don’t obsess about the boundaries of who does what when, so much as the common vision and goal that unifies members of the org.
And lastly, ambiguity is also countered by analysis, by open and transparent communications, by embracing diverse perspectives and the psychological safety to speak up, to ask questions and be open to explore answers together.
You are likely experiencing all of these to a degree in your work. But it’s still worth thinking about these dimension explicitly, giving each a score between one to three (like in Angry Birds!) to figure out where you’re hurting the most, and therefore what to concentrate on when.
These dimensions can’t be “solved,” but you can work to reduce their impact. Constant communications based on the principles of transparency and curiosity will decrease ambiguity, and therefore help navigate the human part of complex situations easier. A shared understanding of the vision will help people adapt quickly when unexpected things arise.
You can read (actually, listen) more about it on Harvard Business Review.
Cynefin
Cynefin (pronounced kuh-nev-in, because Welsh), is a more nuanced framework developed by Dave Snowden. It’s often depicted in the following diagram, but it’s not your typical 2x2 matrix.
There are five different domains, and a situation will fit into one of them. Each domain requires different approaches.
Simple / Obvious: This domain holds situations that are highly predictable (causes and effects are known, not a lot of VUCA). It generally has well known industry “best practices” which you can (often, required to) follow. You need to understand the situation, fit it into a know category, and then respond according to the appropriate best practice.
Complicated situations are similar, but more, well, complicated. Cause and effects can be known, they just need a bit of investigations. A good analyst can decompose the situation and come up with a process that, once proven, can be considered a best practice.
These two domain are on the ‘ordered’ side of the diagram (right side). They belong in a classical world, where effects follow the causes in predictable ways. The type of thinking is reductionist — you reduce the problem to smaller, individual components, and address each in turn. It’s Taylorism to the max, and unfortunately the only way MBAs are taught to think.
The other, left side, of the diagram is where modern product development lives.
In the Complex domain everything is inherently interconnected, and the system cannot be reduced to individual parts. Imagine a group of people, where personalities impact the n-squared number of interactions, plus all the external factors pushing and pulling on the team and individuals.
In this domain, the practice is to probe — i.e. make small, safe-to-fail learning experiments — then make sense of the result before acting. Sounds familiar? This is where the discovery phase (both problem and solution) of most tech product development usually happens. You need to constantly examine the situation and try small changes, so you can learn and then decide on bigger actions. Your practices will continue to emerge.
Chaotic situations are completely unpredictable. You know the pedestrian definition of insanity — trying the same thing over and over but expecting different results? Well, in the chaotic domain you just might get them. There are just too many unknowns to even determine cause and effect. The best way is to act decisively first, assess what happens, and try to respond with increasing sense making and move to a more manageable state. It often requires new ways of doing things.
To approach the Complex and Chaotic domain requires the opposite type of thinking. Instead of reductionism to individual components, you need to apply holistic, systems thinking. It’s a roomful of black boxes, you gently press levers and learn what actions lead to which repeatable results, without worrying too much about the precise internal mechanics.
The Disorder domain (centre) is where you’re not even sure about the situation or what to do. This could be the result of over-confidence on the part of decision makers (like trying to apply rigid, structured processes to startups), or in transition between domains where people are overwhelmed and lack clarity.
Handling it is similar to the chaotic domain, but a lot revolves around engaging stakeholders and people, facilitating discussions, and constantly (iteratively) probing to see which of the other domains is most appropriate. If you’ve gone through “business transformation” of any sort, you know that you have to cross this domain.
You can read more about Cynefin in HBR’s article A Leader’s Framework for Decision Making.
VUCA and Cynefin together
Dave Snowden, creator of Cynefin, did some mapping as evidenced in this tweet. Generally speaking, a high VUCA situation fits the Complex and Chaotic domains. Complexity maps the same; Uncertainty implies chaos (predictability of results), as does volatility (rapid changes). Ambiguity could imply disorder, until you can assign more meaning to events.
You would deal with these elements as mentioned above, as you try to make sense of your domain, increase predictability, and build resilience to change and adapt to new situations as they arise.
I find it interesting that in building a product not everything falls into a single domain at the same time. Consider the Kano model, for example. Say you’re building some SaaS B2B app. While you’re trying to discover what jobs your users really care about and build awesome solutions (delighters), you also know that you must have the basics of security and data governance. You have some competition in the field, because the status quo is always an option, and you will be evaluated on how much better does your promise of the solutions is.
So building a secure data platform may not exactly be a ‘simple’ exercise, but there are certainly best practices you should follow (usually in the forms of standards you certify against).
Discovering the best problem to work on and the appropriate solution involves a lot of small experiments (Complex), but much of the actual features may require old-fashioned business analysis of needs and user workflows (Complicated).
So if you overlay Kano, VUCA, and Cynefin on top of your whole offering, you can start to see that different aspects require different types of actions, efforts, and investments. The most (OK, some of the) dangerous failures lie in applying the wrong domain to the situation.
We can joke (or moan) about the obvious application of Tylorist approach to knowledge work by committing people to work 9-5 in a noisy office together, but it can get more insidious than that. Trying to reduce complex systems to individual parts is death by analysis — it’s inherently the wrong approach. Applying a “framework” (like the ‘Spotify Model’) blindly without thinking about how it serves your current situation will lead to wasted efforts and disappointments.
As said above, this is thinking about how to think about what you need to do. It’s not exactly “practical advice” you can apply. I mean, sure, you can go with the antidote of VUCA above (Vision, Understanding, Clarity, Agility), and just talk to people with curiosity and transparency as you rally them to a common goal. These are always good practices.
But I find that, for me, knowing the type of situation, understanding the meta-context and the “why” (like a 3 year-old), helps me deal better. Helps me reach for the right tool.
What are your experiences with the developing products in different domains and under different conditions? Please comment!
Thank you for the introducation to Cynefin, Assaph! New term and very applicable to product managers.