A Simple Introduction to Complexity

Complexity is hard. A framework called cynefin helps me break it into chunks to describe systems based on their complexity. There are four states of a system: simple, complicated, complex and chaotic. There is another situation where there is no system to speak of, which cynefin calls "disorder." 

We could describe any context in which we operate using one of these states. The great thing is that each has its tricks to understanding, and there is a "goldilocks" zone we can aim for when managing the complexity of systems. 

Simple systems are obvious to the uninitiated. Tab A goes into Slot B. 2 + 3 = 5. These are systems where there is a clear best practice for solving it. Nobody needs domain expertise to understand the cause-and-effect situations. 

To address an issue in a simple system, one takes three steps:

  1. Appreciate (as the doctors might say) the situation.
  2. Categorize the issue as "another one of those," as Ray Dalio might say.
  3. Respond with an already-recognized best practice.

Many micro-systems in the world are simple. But most of the critical issues we face will be in the other categories. 

Complicated systems are understandable to experts. The expert can hold a mental model of the system and reliably predict what outputs a given set of inputs will generate. The system might be mysterious to the outsider, but you call a plumber, and the leak gets fixed. 

Addressing an issue is much like the simple system - but more complicated:

  1. One senses the problem.
  2. One analyzes the situation to find the root cause.
  3. One crafts a plan to address it.

The solution is more bespoke to the problem. That said, it is still deterministic - A causes B causes C causes D. The link from A to D might be lengthy, but with training and study, it is knowable. 

A lot of intelligent people believe they are operating in a complicated system. The notion has the attraction of being blocked off to the unwashed while being under one's control. One can feel a lot of power if one is an expert in a complicated system. One is often wrong. 

Complex systems describe a great deal of the world. Complex systems are more extensive in nodes and have more interactions among the nodes in the network. 

In my experience, one does not understand a complex system. One discovers attributes piecemeal. As a result, you cannot determine how it will behave in advance. However, through experiment and observation, one can see the fuzzy relationships. Put a different way, you don't know what will cause a problem, but after the fact, you can look and say, "oh, yeah."

How one manages a complex system depends on one's level of influence on it. Small complex systems have the potential to move back a level to complicated. One can only nurture large complex systems.

In a complex created system, such as many distributed computing environments, one can ask, "why is this system complex?" The opportunity is to re-architect to move back toward complicated. The first step is probing the system to discover the qualities that make it complex. Second, one can sense the relationships, leading likely to more probing. Finally, one can eliminate connections in the system, perhaps moving it to the complicated domain. 

In a complex emergent system, such as a community of people, cutting off connections is nigh impossible. Thus, one can understand a lot of the horrors of totalitarianism due to applying the "created system" techniques to human beings. Dictators look for ways to shrink the size of networks by dividing people into tribes and control the information networks that carry our complex social signals.

A more successful technique is nurturing the community. Here one looks for examples of bad connections or connection blockers. Grifters are examples of malignant links - liars degrade trust across the system. 

The problems and answers in complex systems are most often within the system. In both simple and complicated environments, domain expertise relevant yet external can "fix" it. The process of discovery in complexity usually means that the solution is internal to the system. The external resource brought to bear is systems thinking itself.  

Complex systems also have a time lag between inputs and outputs. The interrelationships mean that any given input expresses as an output only after some significant downstream interactions. Phrased a different way, they reward patience. 

For a scientist trying to publish on a publishing deadline for a conference, this is terrible! So much time to wait. For an investor managing money, this is often painful as well. But for an entrepreneur playing a long game, this is great. A funded competitor is on a clock, and the time delay effects are a weakness for them. Make time your ally, and you can thrive in a complex system, extending your connections. The metaphor works well with the idea of "stickiness."

The fourth domain is chaos. A complicated system is understandable in advance, while a complex system is "oh, yeah" in arrears. But chaotic systems are "huh?" as inputs and outputs have no reasonable relationship to the observer. These situations are nothing but danger. There is no appropriate action to take. Usually, this means the dynamism of the system is outpacing any reasonable ability to observe it. 

My take on these four domains is that they have a lot to do with the observer's expertise. For a computer programmer, a reasonably sophisticated program could be complicated in that it is under their thumb but not that of someone with less skill. They are in the business of figuring out where their upper bound is before a given program is complex and trying to keep it just under that roof. 

One could describe the line between complicated and complex as a "goldilocks zone." Going to the top of the complicated part of the domain allows one to create maximum value while keeping just off the emergent qualities of the complex environment. But, unfortunately, we often get over our skis, and the job is to pull back from an artificial complex system to enter complicated. 

And to a user, that which the programmer thinks of as complicated is effectively complex as they observe behaviors based on their inputs. 

Cynefin has given me a language to understand the nature of problems and how to drive value. I come back to it repeatedly in my study of technology, markets, and society.