Summary:

• By identifying the complexity of a problem, you can identify the right method for solving it. The Cynefin framework is a model that can be used to help understand the different levels complexity.
• Software product development usually remains in the complex domain because both the market and the product are continually changing. The more systems used in a software solution the more complex changes are within the solution.
• When looking for job candidates match the candidate’s ability for solving problems with the problem domain of the job.

The Cynefin Framework

The Cynefin Framework was created by Dave Snowden (no relation to the other more famous Snowden), a researcher in knowledge management. Cynefin, pronounced kuh-nev-in, it is a way to deal with problems and apply the right decision making for that kind of problem. There are 5 domains in the model. To illustrate how to use the model we will start with a series of possible problems at different levels of complexity. For this example assume that you want to have toast for breakfast, but then problems arise.

Simple:

The toaster isn’t working. We sense that it isn’t working, see the plug is unplugged, and plug it in. This is a simple problem and easy enough to solve. We knew it because of course in the past we’ve had to plug the toaster in, and plug in lots of other electronic things before they start working.

Complicated:

Let’s say our toaster really is broken. We sense that it isn’t working, it is plugged in but the toast keeps popping up. Now we need to analyze the mechanism and see what is broken, and then fix the broken part. Here most people may need to call in an expert or get a new toaster.

Complex:

Once we move over to a complex system let’s say we have bread and we want to figure out how to make a better toaster with things laying around the house (assuming our broken toaster is the only cooking appliance we have). Here there are lots of ways we could do this, we start trying different experiments and see if a radiator may work, or maybe we could start a fire outside and wrap the toast in a metal coat hanger. Here we are probing/experimenting our way forward.

Chaotic:

Here we are ravenous, like the hungry hungry caterpillar, and we are going to start eating something. If it isn’t food we spit it out and move on to the next nearest thing we can grab. Here we are in crisis but can move forward rapidly, and we may be satisfied with something other than toast or we may die from eating the wrong thing.

Sensing Model

Now that we have an example let’s dive more into the Cynefin framework more generically.

This framework is a way to look at the process with which we solve different kinds of problems, Simple, Complicated, Complex, or Chaotic. The sensing method we use to address a problem is in yellow in each section. When we start we don’t know which domain we’re in. To represent this uncertainty their is a big question mark in the middle, or the section of disorder. This is where we usually start before we sense where a problem should be categorized. Once we sense or act we are in moving our problem solving to a particular quadrant, but the problem we face may not be there, which means we won’t solve our problem.

At a higher level we have two halves of the framework.

By looking at this you can see there is a large distinction between the left and right of the model. This distinction is so important because mistakes can arise when we try to enforce methodologies from one side to another. This is called in the Harvard Business review as a cliff from simple to chaotic side. If we are failing to sense what is going on and we are only acting the result is chaos even if the problem was simple. If we ACT first we are always in the chaotic domain. My dad would call that the “FIRE!, ready, aim” version of product development. You may hit your target but you have just as good of a chance of hitting your foot. This can be especially dangerous in product development.

Complexity in the Product Lifecyle

In the product development lifecycle you are always starting in the complex domain to start. We want to probe aka discover, sense aka validate, respond aka mockup/prototype. We may do the following cycle many times in the product development

When building a product sometimes the design and discovery happens in the complex domain and then once the product is known, you build a recipe. The recipe or parts and assemble design falls usually into the complicated domain. Then an assembly line with automation our product is in the simple domain. The problem scope changes as we get closer to repeatability and known outcomes, i.e. ordered systems.

Good for Toasters, Bad for Software

Not all product work follows this pattern and one of the mistakes I have seen is to try and force this manufacturing pattern into software development. Software service development is always in the complex domain. The only simple domain, high volume scale, that happens in software development is when they package it and send it out on disk, a thing that software companies used to do.

Why does most software stay in the complex domain? There are several reasons but I want to highlight two: 1. User demand 2. Interconnectivity.

1. The software landscape changes rapidly and so do users expectations. A hammer hasn’t changed much in a hundred years and you can probably make the same hammer you made last year and sell a similar number. Software customers don’t stick around forever, as MySpace or recently Twitter have found out. Staying in touch with your customer base and their use of software is a key to prevent irrelevancy. This means to continual probe the usage of your users. If the change rate of your business does not meet that of the market you are prone to losing market share and the change rate of software is high.

2. Most software is interconnected with other software: operating systems, frameworks, and APIs. If you read my article on APIs, or are familiar with them, you’ll know most applications today depend on lots of different software packages, some of which are not even inside your company. When those interdependent products change the original software must change too. Your product will keep changing even if you aren’t changing it.

Software isn’t a toaster, but we have a tendency to treat it like one. The only simple domain fix for software seems to turn it off and turn it back on again. Most issues with software are complicated and may need an expert to figure out the issue with it. But due to the interconnectivity of software/systems most real problems are complex, this is where “troubleshooting” or “debugging” comes in. Hopefully you have software developers that can operate in the right domain.

Understanding who you need in your business

This model can also help you find the right people. What kind of problems do you need solved for any given role, and who can best help you solve them? In the realm of software development there can be a large asymmetry of information between the hiring manager and the candidate. Figuring out that information gap is important because there is a large difference between an average and great developer.

To bridge our gap in understanding we can focus on the problems a candidate has solved in the past. What kind of domain thinking can they bring to our team?

If you are doing product development work, then you need someone who can experiment their way forward. What does that look like in programming?

Let me give you a personal example, when I was at the University of Kansas we had a programming class on data structures. Our project was to represent a Rubik’s cube in code, and given any state of the cube our program needed to solve it using the shortest path possible without using a pre-defined algorithm. The program was expected to print out each turn of the cube and display a visual representation of what each side of the cube on a webpage. We were required to use C++, a deterministic programming language, it really helps solve simple and complicated problems. I didn’t know these concepts at the time, but I was struggling on the auto-solve and shortest path algorithm. I could use a heuristic (aka best known method) algorithm to solve the cube, but that violated the boundaries we were given. I discovered that by using a different language, Prolog, I could solve the problem. Prolog was good at “Probe->Sense->Respond” methods, it was an early AI language. I then went on to show my professor that with the given the constraints of the project we had, it wouldn’t be algorithmically possible to complete the project. He got a wry grin and said, “You’re right, you don’t have to do it. Don’t tell anyone else though.” I was stunned. Later I realized, he was making jet pilots not bicyclists.

You don’t have to go to the University of Kansas to find jet pilot programmers, though it doesn’t hurt. Finding developers who are used to solving problems in a complex environment is the goal. Some of the best developers I’ve run across grew up on a farm. They are used to running into unique problems with limited resources and finding a solution. Expert woodworkers can do the same thing.

Usage:

• Before acting on a problem sense or probe to see what kind of problem you have. Acting first always leads to chaos.
• When solving a problem if things aren’t going right ask, “is this actually a complex problem.” Try and validate the domain you are in.
• When working in product development don’t try and force process in while discovering what to build, this leads to chaos. Force in process for process sake can be even more detrimental because you no longer probing or sensing, this leads to chaos.
• You can use this model to look for the right candidates to hire based on the job role. What kind of problems will this person be solving? Are you looking for someone in a call center that follows a script. Simple domain is all you need.