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  (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)
- 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 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 we need a common vocabulary on the top level for the involved disciplines, so we can understand together what is possible to achieve.
- 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 exaptations if we have our eyes wide open in all directions for new knowledge, or luckily come across the 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, since that is UNKNOWN UNKNOWNS below and will sooner or later become a chaos.
- 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 and believe that we are in the ordered domains: We think we know, includes also not listening to vital knowledge within our organisation, or from outside our organisation, meaning disrespect since we as leaders and managers think we know better, or we not care, or we are not engaged. Sooner or later we will crash into the Chaotic domain)
We start with the obvious, the known knowns, which is the Obvious 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 Obvious 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, 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, which also means that we think we are in the ordered domains, 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, in real, we are in the Chaotic domain, with remaining unsolvable symptoms, even though a human complex adaptive system is adaptable and therefore will work, but to a lower degree depending on which and the number of unsolved root causes.
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 are aware and neglecting our visible organisational problems won’t change anything, we are still in the Chaotic domain, with fully visible unsolved symptoms. 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 domain 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 effected. 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 commone 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 in order to make the systemic solution, where our Prefilled Root Cause Analysis Map is of great help. A situational mapping will not help us far, since it is trial-and-error and therefore only an antisystemical (suboptimising) solution in our complex system.
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 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 the ordered 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. 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 root cause analysis. 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 not make our customers unhappy. 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, until we completely crash into the Chaotic domain, meaning we are not far from a company collapse, unable to compete.
As soon as we have taken control again, we have entered the Complex domain, meaning that we need to start asking why we have the problem, until we reach the root cause or the level of not understanding what is wrong. If we not understand what is wrong, we need to experiment to gain the needed knowledge that we now know that we don’t have, which 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 Obvious domain or 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, we will be in the Complex 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 rules** at all or not good enough, and we can therefore not see any pattern at all. When we have taken control again, we will find ourselves in the Complex domain, so normally when we have product problems, we will only swipe through the Chaotic domain. When we have severe organisational problems we can have them 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 is no unknowns at all.
So, from this reasoning we get that the Chaotic domain is unknown unknowns and the Complex domain is the known unknowns.
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. 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 correct, we will by asking why and problably some exploitational experimentation find the root cause. With organisational problem we have the same reasoning, meaning that if we violate one or more of our cognitive abilitities, we can ask why, to find the root causes. The very big difference to product problems is that every product specification is unique, but our organisational specification, or our cognitive abilities, are the same regardless organisation. This means that no experimentation is needed when we have organisational problems, we only need to ask multiple why to reach the root cause(s) and solve them. And our conclusion is then, that organisational problems never pass the Complex domain, but product problems always do (but maybe only shallow if for example the product specification is correct). 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 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 extraordinary innovations and exaptations in another discipline, i.e. we may work in one dicipline only or transdisciplinary. In either case, we do not from beginning know that we will make something useful, which means that unknown knowns also is a label for the Complex domain.
In order to solve complex problems, where iterations and interactions are more important then the activities, transdisciplinary work is a must as we can see above. And when working transdisciplinary, we can also see that there is no difference at all between known unknowns and unknown knowns, since in both cases we need to gain knowledge due to we don’t know and we think we don’t know respectively, where the latter also means that exaptations can occur running into something that already exist. Transdisciplinary work will take care of them both, i.e. to find out if the knowledge existed in other disciplines or not. So, that they are labeling 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. 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 depending on context and our current knowledge. This makes it possible for organisations to really thrive in any one of the domains.
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 root cause analysis to find the root causes in the product or service. 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. Many times experimentation is needed in the Complex domain to gain new knowledge, experiments that are parallel and contradictive, to gain the knowledge needed to get back to the ordered domains again.
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.
**”chaos is the absence of effective constraints, rules are a specific type of constraint”, stated by our complexity guru Dave Snowden at Cognitive Edge.
 NASA presentation at the OSMA Software Assurance Symposium 2003. Link copied 2019-05-28.