This is part four and the last part of this series about the importance of having the same vocabulary and today we will elaborate on UNKNOWN UNKNOWNS and its friends. We will elaborate on both their meaning and in which domain in the Cynefin™ framework they logically should be put, which will be contradictory to where they have been put so far. This elaboration is very important, because wrong labels on the different domains, leads to explanations of why the label is put where it is put, that is contradictory to the common understanding of each domain.
One of the first references where unknown unknowns et al (all combinations of them) can be found, is from a NASA presentation at the OSMA Software Assurance Symposium 2003 [1] (built on the famous words by Donald Rumsfeld), where they give the following definition (I have added more explanations and information within the parentheses):
- KNOWN KNOWNS – There are things we know that we know
(We know that we have the knowledge)
- UNKNOWN KNOWNS – There are things we don’t know (that) we know
(We don’t know that the knowledge exist, or we think we don’t have the knowledge. But that does not mean that someone else in the company or in another discipline outside the company does not have the knowledge, meaning that we need to work transdisciplinary to find out. This is very important since in many cases we do not even know what questions to ask the other disciplines, especially when not having a common vocabulary, so a common vocabulary is key here. By transdisciplinary work we here have the possibility for speeding up implementations, since it is no use to invent the wheel once again. Transdisciplinary work can also make extraordinary innovations and even an exaptation if we have our eyes wide open in all directions for the already existing knowledge, or luckily come across the existing knowledge, which can lead us to success.
Note! Do not mix this up when people in charge doing the plans, do not listen to the existing knowledge from employees. This ignorance is leading to UNKNOWN UNKNOWNS below, due to the fact that we sooner or later will become a chaos.) - KNOWN UNKNOWNS – There are things we know (that) we don’t know
(We know that we don’t have the knowledge. Someone else may still know of course, but that information is not available for us, so in order to achieve the knowledge, we need to experiment ourselves; parallel and contradictive ones will accelerate our search for the knowledge. Transdisciplinary work is important here where people from different disciplines sit together and learn from each other, to achieve modular platforms for example, see this blog post for more information. And once again we need a common vocabulary on the top level for the involved disciplines, so we can understand together what is possible to achieve transdisciplinary.)
- UNKNOWN UNKNOWNS – There are things we don’t know (that) we don’t know
(We don’t know that we don’t have the knowledge, which means that we think we have control. This is the danger zone, because we are out of control, in one of the other domains (Clear, Complicated or Complex), where insufficient planning is an example that is context independent and valid for them all. We think we know, includes also not listening to vital and scientific knowledge within our organisation, or from outside our organisation. This means disrespect to our people since we as leaders and managers think we know better, or we not care, or we are not engaged, leading to not only miserable results, but also highly risking a deteriorating culture. Sooner or later, we will crash into the Chaotic domain.)
We will start with elaboration of these four definitions, but they are not enough, since they will not cover the cases when we cannot do an ontological judgement, when something is UNDEFINABLE. So let us start here.
The definition undefinable, making it impossible to use one of the four different labels above, meaning that we cannot directly take an action. But, the Cynefin™ Framework has a fifth domain, the Confused domain, where everything is blurred or/and blurry. The best example of a blurred situation is when we have caused ourselves problems, due to an earlier mistake or ignorance. Built-in problems are symptoms and consequences, which always are impossible to directly solve. Instead, we need to dissolve the problems by finding and dissolving the root causes to our problems, meaning that we need to change our system, to get rid of our problems. In situations when we cannot find and dissolve all the root causes, our situation is blurry, pointing instead on the need to combine the current situation with abductive approaches in the Complex domain, in order to take the appropriate actions on the path forward.
We continue with the most obvious one, the known knowns, which is the Clear domain in the Cynefin™ Framework. In every step we know what to do, and we know the result, and this can many times be synonymous with repetitive work like production, but not necessarily. In the last step of product development, we will also be in the Clear domain, when everything has been sorted out and we are sure that we can release our product or service for production. But, if we instead did not have control, meaning the unknown unknowns (next bullet), we will end up in the Chaotic domain when we found out.
Next, we go to one of the more difficult one to understand and the one that is mostly put in the Complex domain, but sometimes in the Chaotic domain, and that is unknown unknowns. unknown unknowns means as we can see above that “We don’t know that we don’t have the knowledge”. This is the same as believing that we are in full control in our organisation, no matter the domain (Clear, Complicated or Complex), with a perfect way of working in the organisation that will make us a perfect product or service that our customers will love, in no time, with the right quality to the right cost. But, if we are building our products and services with a way of working not following human science, natural and complexity science, we will have built-in insolvable symptoms and consequences, originating from the unsolved root causes. This means that we in reality are in the Chaotic domain, but we have not understood that yet. Human systems, like organisations, can adapt tremendously to make it work anyway, but with a lower efficiency, higher cost and a low score on the culture. But if the generated symptoms are due to non-reduced complexity or hampered innovations, the catastrophic failure is soon to come.
Sooner or later (hopefully the former), we will realise that we are out of control regarding our product or service and/or our organisation, and then we will directly fall down in the Chaotic domain, since in reality we didn’t know, that we didn’t have the knowledge. But, note that if we now are aware and still neglecting our visible organisational problems it won’t change anything, we will be in the Chaotic domain, or in the boarder land between Chaotic and Confused, with fully visible unsolved symptoms and consequences. And this is a very big difference compared to when we suddenly having product problems and start a task force to understand the root causes to the problems. Because, we will not have a working product again, until we have a plan of what to do, meaning that then and only then, we can leave the Chaotic and Confused domains permanently, and enter the complex or ordered domains, depending on the root cause(s) to the product problems*. The reason for this is that products do not have adaptability, but organisations have and can therefore still have some lower performance.
The Chaotic domain is therefore not the place we want to stay in for a long time, since the whole organisation is strongly negatively affected. No, we need to take full control again, in order to as fast as possible reach the ordered domains again, where we have full control, and an efficient, effective and healthy organisation.
Analysing our system, our organisation’s way of working, as well when we find product or service problems, is extremely important, so that we can be sure that our processes are the proper ones and be sure that we are not violating our human capabilities, see this blog post series about problem-solving, this blog post series about human science and this blog post series about common sense. Human science gave us the final bits of information to our set of principles that our organisation’s need to follow to meet the market of today. If we are not following our set of principles, we need to fix that first of all in order to make the systemic solution, where our Prefilled Problem Picture Analysis Map is of great help. A situational mapping will not help us far, since it is trial-and-error since symptoms can never be solved in order to make the system work, and therefore only an anti-systemical (sub-optimising) solution.
As many of you already know, unknown unknowns is mostly labelling the Complex domain, but as you understand from the reasoning above, it is not logical. This is further elaborated with the following reasoning:
- When we don’t know that we don’t know in the ordered domains we are simply blind and cannot know about it (or we are neglecting it, meaning that we already know that we are in the Chaotic domain), but when we sooner or later realise it, we have chaos, meaning that we have fallen over the cliff from any of the domains into the Chaotic domain. Now we need to mobilise ourselves to take control over the situation by starting a task force or similar to gather available information, since we only know that we have a mess, there is no knowledge. But, to find the root causes to the mess, how to solve them or if it is even possible to solve them, we need to do a Systemic Problem Picture Analysis – SPPA, meaning we are entering the Confused domain, since direct solutions to symptoms and consequences are undefinable. This goes for both product and organisational problems, with the difference that if we have problems with our product, we immediately need to start a task force solving the problem to make our customers happy as soon as possible. Regarding organisational problems we are adaptive and flexible as humans, which means that as we stated above, it can take long time, sometimes many, many years of neglecting, especially regarding product development of big products, until we completely crash into the Chaotic domain, meaning we are not far from a company collapse, being unable to compete.
- As soon as we have taken control again, we leave the Chaotic domain and enter the Confused domain, and we then start asking why we have the problems, where we can have a product problems or organisational problems. In both cases we ask why until we find the root causes. Regarding organisational problems, we cannot change ourselves, we have the organisational human principles within our DNA, meaning that the organisational specification is always wrong if we have organisational problems, due to failure of following the organisational principles. We then need to make a new integration for our organisation, to achieve new cohesiveness (Juarrero) of our complex system. We need to do an integrative (transdisciplinary) exploitation in the Complex domain (or in the boarder land to the Complicated domain, depending on the knowability), so we can follow the organisational principles. This can mean “prototypes”, since the solution may not be perfect the first time as well as can always become better, but definitely better than not fulfilling organisational principles. Regarding product problems, the root causes can require integrative exploitation in the same way (the system specification of the total product was wrong), or require part (disciplinary) experimentation in order to achieve more knowledge for the solution within the part, or even new science.
The latter means that if we not understand what is wrong, even do we have found the root cause, we need to experiment to gain the needed knowledge that we now know that we don’t have, see this example of the science of blood. This means that the Complex domain must be labelled known unknowns, otherwise we would never have started our experimentation per se. The severity of the problem will “decide” how long time it will take until we have the knowledge needed (but, there is no guarantee that we will find a solution) and can enter the ordered domains again, where the knowledge is known in the Clear domain or increasingly knowable by exploitational prototypes in the Complicated domain. As you understand, a product problem for example can be that the systemisation and the specifications are right, but we by mistake mounted one wrong component at production. This means that the problem originates from the ordered domain and we can ask why in combination with experiments to understand the situation until we get the root cause, but until we know and can take an action to solve the problem, we will be in the Confused domain.
- The Chaotic domain got its name from chaos, which we will not have until we are realising the problem, which means that its label must be unknown unknowns. This is a domain where we need to take control, as fast as possible. In the Chaotic domain there are no constraints** at all or not good enough, and we can therefore not see any patterns. When we have severe organisational problems, we can have them a long time without really understanding it, and too long time before we enter the Chaotic domain, can mean bankruptcy.
- To label the Complex domain with unknown unknowns makes no sense, since then we can remove the Chaotic domain, as well as we then have nowhere to put our experimental prototypes, known unknowns (known unknowns can neither be put in the Complicated domain, since we in the ordered domains only have the knowledge, or it is knowable, and there are no unknowns at all.
So, from this reasoning we get that the Chaotic domain is unknown unknowns and the Complex domain therefore is the known unknowns, where the latter means experimentation within a discipline, for example new science in order to make our products better, or integrative exploitation if the knowability is low. Organisations will make their own research in order to take advantage of new science and technology for their different products. Research is always fully unpredictable due to the very high complexity, and is the reason why research never is put inside a project, since that would mean a highly unpredictable time, cost, quality, etc., which never would satisfy the customer. Research can also require multiple experiments (concepts), which are safe-to-fail, which means that there also can be experiments that are wild and for example bringing in thinking form other disciplines, so maybe an exaptation can see the light. When we are confident with the new technology on the parts we wanted to update, we need to do transdisciplinary work to find the new cohesiveness between the parts. This is where the synthesis comes into the picture, which means integrative exploitation, which is in the border line between the Complex and Complicated domains. Normally product development starts at this border line with this integrative exploitation, which will lead to one or more prototypes depending on the knowability. Important to add is that this integrative exploitation is linear with its increase of knowledge until we have done the product right. This linearity is very different from the research phase for the parts (or on the hole, if the integrative knowledge is unknown), where there can be multiple safe-to-fail experiments needed to gain completely new knowledge, as mentioned above.
We have also touched that in the Complicated domain we make exploitational prototypes, which gives it the label known knowable, or we know that the information is knowable with help of experts judging the results from the test result from the prototypes. A good example is HW prototypes, where experts will guide us to our product release, meaning that the test of every new prototype give us new valuable information. Normally 2-3 prototypes are enough to take care of the solution for EMC and Lightning problems, as well as integrating HW and SW.
Note! What is important in the complicated domain is the direction from cause (for example a prototype) to many different effects (we get the test results), where experts can help us judge from the test result the design of the next prototype (or real product if possible). But, if we go backwards, there is only a one-way-track to our cause that we initiated ourselves, meaning that if the specification is not correct, we will by asking why and probably with some experimentation find the root cause to our product problem. With organisational problems we have the same reasoning, meaning that if we violate one or more of our cognitive abilities, we will for sure have symptoms and consequences, so we can ask ‘why’, to find the root causes. The very big difference is that with deeper and deeper scientific knowledge we can make our products better and better or/and we can put the parts together with a new cohesiveness. This means that product specification can be out-dated due to new science for the parts, even though the cohesiveness is the same. But, each and one of the organisational specifications around the world, need to be built on our cognitive abilities, there are no more science to find deeper in our humans. We humans are the parts, and we have the DNA we have, so we need to focus on the cohesiveness instead, on how we put our organisation together, so that our cognitive abilities are not violated. For further information about problem-solving regarding products and organisations and their close relationship, see this series of blog posts.
Saved for last is the tricky unknown knowns, “There are things we don’t know (that) we know”, or maybe easier understood as we think (that) we don’t know, meaning that someone in some discipline (or even our own) has the knowledge about the solution or have already solved it (new science or technology in the disciplines or parts by experimentation due to known unknowns), but in our discipline we cannot see it, or understand how to use it even if we see it, or the knowledge is brand new. That is the reason why a common vocabulary is so important, or at least that we try to understand the words when we are entering a new discipline, and understand if the new words are new to us, or in fact only are other names for the same thing. unknown knowns is thus where we combine existing knowledge from one or more discipline(s) to make an extraordinary innovation or exaptation in another discipline, i.e., we may work in one discipline only, or transdisciplinary between different disciplines, seeking for new cohesiveness. In either case, we do not know from the beginning that we will make something useful, which means that unknown knowns is a label also for the Complex domain.
In order to solve complex problems, where iterations and interactions are more important than the activities, transdisciplinary work is a must in product development as we can see above. And when working transdisciplinary, we can also see that there is little difference between known unknowns and unknown knowns, since in both cases we need to gain knowledge due to we know we don’t know, and we think we don’t know respectively, where the latter also means that an exaptation can occur running into something that already exist, but in another discipline. Transdisciplinary work is important for both of them, i.e., to find out if the knowledge existed in other disciplines or not as well, once again stating the need of a common vocabulary, the focus on this series. So, that known unknowns and unknown knowns are labelling the same domain, the Complex domain, is no coincidence.
Now we have labels for all the domains in the Cynefin™ Framework and even two on the Complex domain, which will then look like this:
Picture pending.
With our logical reasoning, removing contradictions due to putting the labels wrong, it is now much easier to understand the different domains and what to do with our problems depending on context and our current knowledge. This also includes the knowledge about that some problems are undefinable and therefore cannot directly be taken an action on in one of the Clear, Complicated, Complex or Chaotic domains. All together this makes it possible for organisations to take care of any problem, really thrive in any one of the domains and become a flourishing organisation.
This was all in this series of blog posts.
C u soon again.
*The task force (< 5 persons) need to take control over the situation as soon as possible, by making a traditional analysis to find the root causes in the product or service, i.e., 5Why?, Ishikawa diagram, or similar. The ability to bring up a task force in no-time is critical to take control again and be able to leave the Chaotic domain. With the root causes found and a rough way forward, the complex or the ordered domains will be entered. But we not only need to understand the root cause to the problem in our product or service. In order to not repeat the same problem again, we also need to analyse our system, see this blog post series about problem-solving for an detailed elaboration about the product and system layers to be able to find the real root cause(s) also of our organisation, and to dissolve them.
**”chaos is the absence of effective constraints, rules are a specific type of constraint”, stated by our complexity guru Dave Snowden at Cognitive Edge.
References:
[1] NASA presentation at the OSMA Software Assurance Symposium 2003. Link copied 2019-05-28.
https://www.nasa.gov/centers/ivv/ppt/172585main_SoftwareAssuranceSymposium_OConnor.ppt