Demand Driven

We are not building toasters.

We have talked about the fact that most of our business practices were developed with a manufacturing mentality.  Historically, these have been deterministic systems: in a manufacturing model, we know the desired outcome (the product) and we know the resources and skills it will take to create that outcome. Manufacturing uses predefined processes and resources in a command and control model to minimize variation and maximize output. If we were building toasters, we would know what the outcome should look like and how it should perform. We would know what parts and skills are required to build a toaster. In a customer engagement and support environment, we are not building toasters. We are solving (often complex) problems. 

We are the first nor the only ones to recognize that the hierarchy as an organizational structure has outlived its usefulness.  "Traditional, hierarchical views of leadership are less and less useful given the complexities of the modern world” - opening sentence in a paper titled "Complexity Leadership Theory" from a group of academics.

Problem-solving is non-deterministic: we don't know at the beginning of the problem-solving process what the outcome or resolution will be. Nor do we know the process or what resources will be required to resolve it. The process and resources needed in a non-deterministic model are emergent; they are based on the nature of the situation.  Our approach, and the skills and resources required, emerge as we learn more about the situation. 

There is some excellent academic work that highlights this point. 

The approach depends on the situation.

The Cynefin framework is a great decision-making framework that highlights the different approaches needed for different types of situations. In this framework, problems can be sorted into five domains. 

In this framework, the characteristics of the situation allow the classification of the problem which dictates the approach. While the difference between chaos and obvious is self-evident, the difference between complex and complicated is not.  An example of the difference is helpful: building a passenger jet is complicated, but predicting the weather is complex.  Tying this back to the earlier discussion on deterministic and non-deterministic concepts: building a passenger jet is deterministic while forecasting the weather is non-deterministic.

In a support context, we could map new issues to the "unordered" side of the model and known issues to the "ordered" side of the model. For example: on the unordered side, if a serious outage has occurred, things may be chaotic and the first thing we want to do is take action to restore service.  After service is restored, we may move to the complex domain and probe to understand what caused the outage. As we learn more about the situation, we might recognize the cause as something that is known and we would move to the obvious domain. 

On the ordered side of the model, with known issues, there are times when determining the attributes of the issue may be complicated.  There are other times when we have a good understanding of the attributes of the issue at the outset, and if we have a good knowledge base, where we have captured the experience of responding to past demand, the resolution might be obvious.  

The situation or nature of the demand (the request) should dictate our approach to resolving the issue, and as we learn more about the issue we may shift our approach as our understanding of the situation moves us from one domain to another.

This is just one application of the Cynefin Framework. For more detail, please visit The Cynefin Co.