Risk and Complexity
This blog was inspired by a question on Twitter.
To many people familiar with categorization matrices, the system of systems perspective afforded by the Cynefin framework remains a bit of a mystery. The primary cause of this mystery is that, while Cynefin is a sense-making framework, many just continue to use this as a categorization matrix, something that is very familiar to anyone who has done any course or reading in any domain of management.
Cynefin enables us to deal with complexity. In systems engineering or business management, it provides an alternate worldview, a way of interacting with our vociferous peers in a structured and meaningful way, a technique for better understanding events - the accompanying risks and opportunities - that impact our organization, and provides insights into new options for interventions required to resolve or mitigate their impact.
This blog is just a primer where we begin to explore the fundamentals of the Cynefin framework. In this series of blogs, we will explore complexity science and its inter-related fields of study in order to really get to grasp the full portent of the Cynefin framework.
There is enough literature on Cynefin on the internet. So let's plunge into an example that can highlight its use. The first is simple - locating Ross.
Who is Ross? For now, let's just say that Ross is a person of interest (PI).
The moment you are able to classify Ross as a PI, the easiest way to locate him would be to see what attributes describe Ross. In other words, what information is available about Ross. If say, you have his name and street address, it obviously becomes quite easy to locate Ross.
Therefore, if the information you have is a name, an address and the fact that the address you have is indeed his home address, makes it possible to locate Ross. In other words, his location becomes "obvious".
If Ross is an accountant, he would in all probability, be working in an office somewhere that is a 40-minute commute from his home in Rosenhiem. If on the other hand, if Ross were a salesman, he could be anywhere.
Then again, even if you knew Ross was an accountant, and that he commutes 40-minutes to work each morning, it may be that he went off elsewhere on an assignment.
You would probably be able to know his exact location on any particular day only in hindsight. Locating Ross in such circumstances is a lot more "complex". You will need to get on a phone and talk to a lot of people, maybe someone can get a description of his car, and a plate. Someone else could scope his residence, talk to neighbors, friends who might have seen him that morning. Others could check gas stations with a description of Ross and his the car. Someone else could check if they can get the police to access public CCTV cameras they use to monitor the town and so on.
These "probes" may get you some leads which you could use to determine follow-on actions.
*This analysis is imperfect - see explanation in Epilogue.
Ordinarily, with the amount of information you have on Ross and considering the pattern of his movements, you and I might choose to wait until he returns home at night. But that puts us back in the "Ross at home" scenario. For argument sake, let's say that we need to locate Ross urgently.
Why?
Maybe you get information on why Ross is a PI from the police - that he is a salesman working for a private firm ABC&Co that sells auto components, but all that is just a legitimate cover for his otherwise nefarious activities, that he is a gun-runner and a sympathizer for a known terrorist organization.
When you get a call telling you that Ross has been spotted in Munich (event), your affiliation with Ross will determine your consequent actions.
Assuming you are in the Rosenhiem police department and tasked with keeping a constant watch on Ross (hence the unusual level of interest in being able to locate Ross at all times), you will probably have to call your affiliate in Munich to help locate and monitor and/or apprehend Ross and get him back to Rosenhiem for questioning. Maybe you need to jump on a car or a train and get to Munich. Whatever the scenario and the amount of information available, you have to "act" immediately otherwise you may end up losing track of Ross again. The consequences of your "actions" or the lack of it will then determine outcomes.
*This analysis is imperfect - see explanation in Epilogue.
You learn of "events" - a situation or an occurrence in time and space that is of interest to you or your organization, an occurrence that represents a risk or opportunity, how you begin to make sense of it using the Cynefin framework. You learn that the decision sequence in each of the different domains is different, and you learn of constraints, probes, and action.
In addition, you also realize that there are dynamics at play, that events transition between domains, depending on the availability of information on the event, that more the information, the easier it becomes for arriving at a decision or developing a procedure to handle the specific event. In other words, the more you constrain an event (with increasingly definitive information), the more definitive, your approach to it.
You also realize that while the "Ross at home" scenario played out well, the "Ross in Munich" scenario was difficult to digest. How did "Ross at home" give slip to the police who were tasked with keeping an eye on him?
Obviously, over an extended period, while the "Ross at home" scenario played out, a certain level of complacency set in until finally, someone dropped the ball and Ross disappeared. Until he was spotted in Munich.
So whether by definitive actions, probes, analysis or just plain old complacency, you introduce a dynamic. The Cognitive Edge blog [1] explains some of these dynamics quite succinctly.
So what of it?
Bottomline, it is all a question of the capacity to adapt, in this instance, the adaptability of an organization to changes in its environment. The organization adapts by building capacities to respond to events that impact it. In this instance, a policeman on the beat could keep an eye on "Ross at home".
The moment Ross went mobile, you needed the help of some experts. You needed additional resources for probes - maybe one or more investigators or a whole new investigations department.
And finally, you needed those capabilities to be replicated to create a countrywide presence in order to track Ross and his colleagues, no matter where they were at any moment in time.
The same principles apply when you use Cynefin to develop systems and software engineering capabilities.
In the old world, a software requirements specification enabled engineers to pull customer needs from the complicated domain into the obvious domain in sufficient detail to enable the development team to develop the architecture, determine the structure of tables in the database and write the logic to complete the transaction.
Agility shifted the center of gravity of development processes to enable it to deal with greater levels of uncertainty, while still keeping the user acceptance risks manageable through constant interactions with the customer.
The client or supported organization is always evolving. And consequently, they will learn to deal with the complexities, volatilities, and uncertainties of its environment and adapt in order to balance risk and opportunity. And software development organizations need to learn to keep up with this pace of change.
The complex and chaotic domains are of particular interest to software development organizations and businesses. These are very volatile domains where practices are either emergent or novel and therefore offer the greatest potential for innovation.
Today, the software development and collaboration tools, tool-enabled processes like DevOps, and scalable, cloud-based infrastructure are all evolving in a manner that will further shift the center of gravity to the boundary between complicated and complex domains in order to enable the development organization to be highly responsive and assume an increasing share of the burden of risk and uncertainty with the client or with the supported organization.
Now liminal zones are extensions of the framework, something that Dave has been working on of late, his blog on "Boundaries as domain shadows" [2] and "Liminal Cynefin" refers [3].
Liminal refers to the initial or transitional stage of a process, or for that matter. occupying a position at, or on both sides of, a boundary or threshold. This requires the framework to be modified a bit as follows.
Dave introduced these "liminal" or "transition" zones between domains. In his words:
And in his blog of June 2017 [3] he says:
This is interesting. "Ross in Munich" is in the liminal zone between complex and chaos precisely because you have that piece of information. Your "actions" will determine whether you tip that into chaos or recover it.
"Ross in a car" is in the liminal zone between complex and complicated again precisely because without further information and if your early assessment is accurate, the situation can still be brought under control, that is, there is still the element of linear causality. If not, you may be left with no choice but to quickly launch multiple parallel probes (provided the capability exists).
Suffice to say that domain boundaries are critical to the framework. For now, I will just leave it at that.
In thermodynamics, the term phase transition (or phase change) is most commonly used to describe transitions between solid, liquid and gaseous states of matter, and in rare cases, plasma (physics). A phase of a thermodynamic system and states of matter have uniform physical properties. During a phase transition of a given medium, certain properties of the medium change, often discontinously, as a result of the change of some external condition, such as temperature, pressure of others. For example, a liquid may become gas upon heating to the boiling point, resulting in an abrupt change in volume. The measurement of the external conditions at which the transformation occurs is termed the phase transition. [5]
Extending the analogy to Cynefin, for the moment, we can definitely state that transitions are an important consideration. However, its practicality for general management application needs further study as boundary conditions here are not properties of materials, but outcomes of actions by "human agents" with varying levels of experience and skills.
2. Boundaries as domain shadows; Dave Snowden; May 2017; Cognitive Edge
3. Liminal Cynefin; Dave Snowden; Jun 2017; Cognitive Edge
4. Being in the Zone and Vital subjectivity; Paul Stenner; May 2016; Copenhagen Business School
5. Phase Transition;
To many people familiar with categorization matrices, the system of systems perspective afforded by the Cynefin framework remains a bit of a mystery. The primary cause of this mystery is that, while Cynefin is a sense-making framework, many just continue to use this as a categorization matrix, something that is very familiar to anyone who has done any course or reading in any domain of management.
Cynefin enables us to deal with complexity. In systems engineering or business management, it provides an alternate worldview, a way of interacting with our vociferous peers in a structured and meaningful way, a technique for better understanding events - the accompanying risks and opportunities - that impact our organization, and provides insights into new options for interventions required to resolve or mitigate their impact.
This blog is just a primer where we begin to explore the fundamentals of the Cynefin framework. In this series of blogs, we will explore complexity science and its inter-related fields of study in order to really get to grasp the full portent of the Cynefin framework.
There is enough literature on Cynefin on the internet. So let's plunge into an example that can highlight its use. The first is simple - locating Ross.
Who is Ross? For now, let's just say that Ross is a person of interest (PI).
The moment you are able to classify Ross as a PI, the easiest way to locate him would be to see what attributes describe Ross. In other words, what information is available about Ross. If say, you have his name and street address, it obviously becomes quite easy to locate Ross.
"Ross at home"
Now, while Ross is a person, a being, or an entity, his location is an event associated with time and space. While you have a name and an address in say, Rosenhiem, Ross may not be available at that address at all times. So the additional attribute that can lock down (constrain) Ross's location is the time at which he is available at that address. If it is a home address, he would in all probability, be there early mornings, late evenings, at night and on weekends. If it is an office address, he would be there between say nine and five on all working days. The greater the amount of information, the easier it is to locate Ross.Therefore, if the information you have is a name, an address and the fact that the address you have is indeed his home address, makes it possible to locate Ross. In other words, his location becomes "obvious".
"Ross on a train"
If Ross leaves for work each morning and commutes 40 miles by train, his exact location for the duration of commute is less obvious. Yet, there are only a finite set of commuter trains as well as towns/cities with a 40-minute commute by train. To be able to locate Ross, you would need more attributes besides his name and residential address. These attributes can be determined, however, will need some effort. You will need to locate the train that Ross takes each morning to work. For that, you probably need to know the city in which Ross works, the time of day at which Ross leaves for work, the nearest train station, the distance from his home to the train station, the trains that service the route, the departure time for each train between that home station and his workplace station. In other words, this will require a bit of "analysis", and probably by someone who has a bit of expertise in locating people.
"Ross in a car"*
If instead of taking a train, you only know that Ross leaves for work each morning by his own car. Locating Ralf becomes a lot more "complex". If you have prior information that he commutes to work each morning in his car, and that the commute takes 40 minutes, you could reduce (constrain) the number of towns or cities to which Ross commutes. Yet, unlike a train, a car can take Ross anywhere.If Ross is an accountant, he would in all probability, be working in an office somewhere that is a 40-minute commute from his home in Rosenhiem. If on the other hand, if Ross were a salesman, he could be anywhere.
Then again, even if you knew Ross was an accountant, and that he commutes 40-minutes to work each morning, it may be that he went off elsewhere on an assignment.
You would probably be able to know his exact location on any particular day only in hindsight. Locating Ross in such circumstances is a lot more "complex". You will need to get on a phone and talk to a lot of people, maybe someone can get a description of his car, and a plate. Someone else could scope his residence, talk to neighbors, friends who might have seen him that morning. Others could check gas stations with a description of Ross and his the car. Someone else could check if they can get the police to access public CCTV cameras they use to monitor the town and so on.
These "probes" may get you some leads which you could use to determine follow-on actions.
*This analysis is imperfect - see explanation in Epilogue.
"Ross in Munich"*
If someone calls and tells you that Ross (assume here that he had been missing a few days) has been spotted in Munich, it is an altogether different scenario.Ordinarily, with the amount of information you have on Ross and considering the pattern of his movements, you and I might choose to wait until he returns home at night. But that puts us back in the "Ross at home" scenario. For argument sake, let's say that we need to locate Ross urgently.
Why?
Maybe you get information on why Ross is a PI from the police - that he is a salesman working for a private firm ABC&Co that sells auto components, but all that is just a legitimate cover for his otherwise nefarious activities, that he is a gun-runner and a sympathizer for a known terrorist organization.
When you get a call telling you that Ross has been spotted in Munich (event), your affiliation with Ross will determine your consequent actions.
Assuming you are in the Rosenhiem police department and tasked with keeping a constant watch on Ross (hence the unusual level of interest in being able to locate Ross at all times), you will probably have to call your affiliate in Munich to help locate and monitor and/or apprehend Ross and get him back to Rosenhiem for questioning. Maybe you need to jump on a car or a train and get to Munich. Whatever the scenario and the amount of information available, you have to "act" immediately otherwise you may end up losing track of Ross again. The consequences of your "actions" or the lack of it will then determine outcomes.
*This analysis is imperfect - see explanation in Epilogue.
"Ross who?"
Of course, this is where it all starts. The first time you are assigned to the task of keeping track of a person named Ross. There is no construct, no structure at all to this assignment at this point in time, so your question would quite obviously be "Ross who?". It is your starting point.
Epilogue
The story ends well for you, of course! But what are the lessons learned?You learn of "events" - a situation or an occurrence in time and space that is of interest to you or your organization, an occurrence that represents a risk or opportunity, how you begin to make sense of it using the Cynefin framework. You learn that the decision sequence in each of the different domains is different, and you learn of constraints, probes, and action.
In addition, you also realize that there are dynamics at play, that events transition between domains, depending on the availability of information on the event, that more the information, the easier it becomes for arriving at a decision or developing a procedure to handle the specific event. In other words, the more you constrain an event (with increasingly definitive information), the more definitive, your approach to it.
You also realize that while the "Ross at home" scenario played out well, the "Ross in Munich" scenario was difficult to digest. How did "Ross at home" give slip to the police who were tasked with keeping an eye on him?
Obviously, over an extended period, while the "Ross at home" scenario played out, a certain level of complacency set in until finally, someone dropped the ball and Ross disappeared. Until he was spotted in Munich.
So whether by definitive actions, probes, analysis or just plain old complacency, you introduce a dynamic. The Cognitive Edge blog [1] explains some of these dynamics quite succinctly.
So what of it?
Bottomline, it is all a question of the capacity to adapt, in this instance, the adaptability of an organization to changes in its environment. The organization adapts by building capacities to respond to events that impact it. In this instance, a policeman on the beat could keep an eye on "Ross at home".
The moment Ross went mobile, you needed the help of some experts. You needed additional resources for probes - maybe one or more investigators or a whole new investigations department.
And finally, you needed those capabilities to be replicated to create a countrywide presence in order to track Ross and his colleagues, no matter where they were at any moment in time.
The same principles apply when you use Cynefin to develop systems and software engineering capabilities.
In the old world, a software requirements specification enabled engineers to pull customer needs from the complicated domain into the obvious domain in sufficient detail to enable the development team to develop the architecture, determine the structure of tables in the database and write the logic to complete the transaction.
Agility shifted the center of gravity of development processes to enable it to deal with greater levels of uncertainty, while still keeping the user acceptance risks manageable through constant interactions with the customer.
The client or supported organization is always evolving. And consequently, they will learn to deal with the complexities, volatilities, and uncertainties of its environment and adapt in order to balance risk and opportunity. And software development organizations need to learn to keep up with this pace of change.
The complex and chaotic domains are of particular interest to software development organizations and businesses. These are very volatile domains where practices are either emergent or novel and therefore offer the greatest potential for innovation.
Today, the software development and collaboration tools, tool-enabled processes like DevOps, and scalable, cloud-based infrastructure are all evolving in a manner that will further shift the center of gravity to the boundary between complicated and complex domains in order to enable the development organization to be highly responsive and assume an increasing share of the burden of risk and uncertainty with the client or with the supported organization.
Insights from Dave Snowden
I am leaving the narrative above in its original draft so that you can compare the more nuanced approach as suggested by Dave. Here is his response:
Now liminal zones are extensions of the framework, something that Dave has been working on of late, his blog on "Boundaries as domain shadows" [2] and "Liminal Cynefin" refers [3].
Liminal refers to the initial or transitional stage of a process, or for that matter. occupying a position at, or on both sides of, a boundary or threshold. This requires the framework to be modified a bit as follows.
Dave introduced these "liminal" or "transition" zones between domains. In his words:
I’d been thinking about creating a version of Cynefin in which the complex-complicated boundary becomes a domain. The reason for that is a lot of techniques, for example a sprint within Scrum, are boundary transitions rather than domain techniques. In general any linear iteration or experiment is such a transition rather than a domain technique. Complex is about shorter cycle parallel probes. Maintaining a project within the boundary domain is important to prevent premature convergence, so it needs to be more than a line. Over the last couple of days I’ve been thinking of it less as a domain more as a gradient or shadow – which is how it is drawn here. [1]
And in his blog of June 2017 [3] he says:
The Cynefin framework tends to be used in the main to categories situations within the four main domains (and for more advanced use all five). I’ve never had a problem with that but the dynamics are as important as the domains and they are too often neglected. A concerned effort over the last year in presentations and teaching has resulted in a higher utilisation so it’s time to move on the develop the boundary zones. I should make it clear that this is an additional layer to Cynefin so it does not need to be used per se. This is not complete and I may switch the representation as i develop it.So the final picture appears to be:
This is interesting. "Ross in Munich" is in the liminal zone between complex and chaos precisely because you have that piece of information. Your "actions" will determine whether you tip that into chaos or recover it.
"Ross in a car" is in the liminal zone between complex and complicated again precisely because without further information and if your early assessment is accurate, the situation can still be brought under control, that is, there is still the element of linear causality. If not, you may be left with no choice but to quickly launch multiple parallel probes (provided the capability exists).
Suffice to say that domain boundaries are critical to the framework. For now, I will just leave it at that.
The Stalker is a character played by Aleksandr Kaidanovksy in the 1979 film directed by Andrei Tarkovsky. The stalker does not spy on others, but smuggles people seeking inspiration (a scientist and a writer) into and out of the zone in which the normal laws of reality appear not to apply. The nature of the zone remains disturbing and mysterious throughout. Was it created by an industrial disaster, an alien crash landing, a military experiment or some other event? We are tild that at the centre of the zone is a room and that those who set foot in it will be granted their real wishes. Ultimately, the characters cannot bring themselves to enter, leaving one wondering why: What were their real desires? What is the zone? [4]
Stenner picturised this as under:
In thermodynamics, the term phase transition (or phase change) is most commonly used to describe transitions between solid, liquid and gaseous states of matter, and in rare cases, plasma (physics). A phase of a thermodynamic system and states of matter have uniform physical properties. During a phase transition of a given medium, certain properties of the medium change, often discontinously, as a result of the change of some external condition, such as temperature, pressure of others. For example, a liquid may become gas upon heating to the boiling point, resulting in an abrupt change in volume. The measurement of the external conditions at which the transformation occurs is termed the phase transition. [5]
Extending the analogy to Cynefin, for the moment, we can definitely state that transitions are an important consideration. However, its practicality for general management application needs further study as boundary conditions here are not properties of materials, but outcomes of actions by "human agents" with varying levels of experience and skills.
(Yet to be updated and/or concluded/...)
REFERENCES
1. Cynefin Dynamics; Dave Snowden; July 2015; Cognitive Edge2. Boundaries as domain shadows; Dave Snowden; May 2017; Cognitive Edge
3. Liminal Cynefin; Dave Snowden; Jun 2017; Cognitive Edge
4. Being in the Zone and Vital subjectivity; Paul Stenner; May 2016; Copenhagen Business School
5. Phase Transition;
Comments
Post a Comment