Acknowledge Uncertainty

We humans often feel a tendency to portray ourselves as knowledgable, competent and masterful, especially when our work is being observed and judged by others.

However, there are situations in which we are none of these, and feigning certainty in these situations is not likely to lead to positive outcomes.

Dan Snowden’s Cynefin framework offers a useful guide to differing approaches that are appropriate for situations with varying degrees of certainty.

Cynefin Model

The Cynefin framework suggests four different approaches, starting with situations of high certainty, and proceeding to situations with progressively lower degrees of certainty.

  • In Simple situations, the appropriate approach is to Sense, Categorize and then Respond, making use of an established best practice.

  • In Complicated situations, the appropriate approach is to Sense, Analyze and then Respond, making use of expert knowledge.

  • In Complex situations, the recommended approach is to Probe, Sense and then Respond, allowing new knowledge to emerge.

  • In Chaotic situations, the appropriate approach is to Act, Sense and then Respond, learning and adjusting as you go.

Another way to think about these four categories would be to use the following terms:

  • Mechanical – In the simplest of situations, a mechanical or proceduralized response is most appropriate. For example, a user requests the addition of a new field to an existing screen in an established application. Usually only a brief discussion is required to determine which field type is to be added to the database, and which sort of user interface widget is to be added to the screen.

  • Analytical – In more complicated situations, some serious analysis is required. Let’s say we want to add some new functionality to an existing system, to help a user track a package after an order has been placed. Various questions naturally arise. What sort of information should be presented to the user? In what form – a textual display, or a map? And when should the information be provided – only when the user requests it, or at other times as well? This is more than simply a case of plopping the request into one of a few predefined categories.

  • Experimental – In complex situations, analysis based on existing knowledge is not enough, and some experimentation is called for. Let’s say your design team comes up with two very different user interfaces to accomplish a new task. Which of them will be preferable to most users? In a case like this, it’s appropriate to build a prototype of some sort, and perform some usability testing to allow new knowledge to emerge.

  • Crisis – In crisis mode, something unexpected has happened, and there is no opportunity for analysis or experimentation – immediate action is necessary. For example, your new system has been deployed for a week, and then suddenly crashes, for no obvious reason. In a situation like this, clearly someone needs to take charge and begin taking action without the luxury of waiting for much analysis or experimentation.

From a Knowledge Management perspective, it is useful to think about gradually moving particular situations down this scale, towards greater degrees of certainty. Once past an immediate crisis, then experimentation may be used, and once the results of experiments are known, then expert knowledge may be built, and once all possibilities have been categorized, then procedures may be written, or perhaps even automated, to deal with similar situations in the future.

On software development projects, it is critically important for everyone, but especially leaders, to acknowledge a legitimate spectrum of uncertainty, and to be able to draw from a palette of differing approaches to deal with these varying situations.

When considering the application of the Cynefin framework to software development, it is important to remember a few salient points:

  • Simple, mechanical tasks should generally be automated, or codified by standards and procedures, and so your developers should not be spending a lot of time in the simple, mechanical corner of the diagram.

  • Any project worth doing will be attempting at least some things that have not been done before, at least by this particular team, and so there will be some things in the complex, experimental quadrant.

  • In practice, it is often difficult to discern the difference between complicated and complex – between situations requiring experimentation vs. situations in which analysis is sufficient.

This idea of acknowledging uncertainty has far-reaching implications, and should be kept in mind when considering the following big ideas as well:

Next: The Inconvenient Nature of Software Development