Cynefin framework is a great tool for decision-making. It was coined by Dave Snowden during his work in IBM Global Services. The framework categorises problems into 4 domains where each requires a different approach to be resolved:
- Obvious. The best practice solution exists for “obvious” problems. Simple math problem like linear equation is in the “obvious” domain. There is a known best-practice methodology for solving it.
- Complicated: There are good practice solutions, meaning there are multiple good ways of dealing with a problem. You usually require an expert in the field of the problem to suggest a good practice solution for it. To know what tech stack to use for building a website you usually need experience or an expert to tell you, and there are usually multiple options - this is a “complicated” problem domain.
- Complex: There is no good practice solution for this problem. You don’t have a good or best practice solution because the problem is ambiguous. In Snowden’s words, you need to “probe” the problem by experimenting and learning about the problem first. At AWS I was assigned to develop a monitoring solution for Amazon’s network of devices. Since this problem is ambiguous, and there are no good practice solutions available, it is a complex domain problem.
- Chaos: No cause and effect relationship exists. There is almost no reliable information. The problem is completely novel and it requires some kind of action to address stable parts of the problem that can be moved into the complex problem domain. Covid pandemic is a chaotic problem.
Both complex and chaos domains are categorised as “unordered” domains, meaning cause and effect can only be deducted in hindsight after experimenting and interacting with the environment. It is very important to understand when your problem is in the “unordered” domain because you should automatically switch to methodologies where progress is measured in learning.
All startups fall into the complex domain. That is the gist of the Lean Startup movement and its principles. It addresses the fact that startups operate in an environment of extreme uncertainty and enforces a mindset where the primary goal is learning from probing a market and probing a problem.
Looking at the other way around, when you are dealing with a complex problem at work, you are running a small-scale startup. You must first probe the problem, get reliable data from probing, and learn from that data so you can make further decisions.
For instance, at JayOne.org we are not measuring our progress with a number of features developed or tickets resolved. We are measuring progress by measuring how users interact with our website, understanding if value and growth startup assumptions are correct, and then tweaking the code to see if we can get expected user behaviour.