When we see businesses that succeed it’s always tempting to see what we can learn from them and to apply it in our own businesses. When businesses spot a new approach to doing things that they can try in their business, they watch, question, and consider it. They then design a way to do things based on what they have learned. Yet often it just doesn’t deliver what’s expected.
The problem is context, or rather, the different context that now applies. Often that context is only subtly different, nuanced from the original context, but elements of the process depend on aspects of the context being present in the right way. When we apply things in new contexts that dependence may have been missed.
Indeed dependence may not even have been suspected, nor implied, from the observed experience, which is often limited in extent. It may not ever be possible to measure or test the level of dependence. In the absence of the ability or time to test dependence the tendency is to assume independence (because none has been seen) rather than dependence. Therein lies one aspect of the contextual independence fallacy.
The other is that cause and effect are often separated by significant periods of time. For example, launching a new product requires a significant input of time and effort long before any returns can be measured.
Very few business processes are truly contextually independent, so it’s important when designing and testing processes to also capture the contexts that apply. It’s also important to recognise that the context may not be clear, and is probably changing. After all very little is static and the environment changes constantly. Keeping track of what works, the contexts in which it is working best, the contexts which stop it working and seeing the changes and adapting to them is often what we describe as intuition. Really it comes from depth of experience, and skills of interpretation honed over time.
Knowing that assuming contextual independence is a fallacy is one thing, dealing with it is quite another. The first step is to look at all aspects of the contexts that are known to work well. Who is involved, in what ways, when and how they react. At each point it’s important to question whether the new context will be the same, or, in what ways, it will be different. That’s not necessary to determine how to change what you do, rather it’s to help identify how and what to measure, and test.
The second step is to put the process into action and record the impact and results. Changes can then be put in place to test alternative approaches in the new context, informed by the results so far, and interpreting possibilities to suggest new approaches.
What ends up is a new process in a new context, dependent on that context for the results we get, but evolved from rather than imposed by, the original source process. Contextual dependence becomes a part of the experience we now have, rather than the fallacy of contextual independence.