The strategy cycle is one of those simple mental devices which hides a world of complexity. On the surface, it's all about observing the environment (the landscape and climatic patterns which impact it), orientating around it (the doctrine or principles we might use), deciding where to attack (leadership) and then acting. It's a combination of OODA (Boyd) and Sun Tzu in a easy to understand cycle.
However, dig beneath the surface and you start to discover layers of complexity. To understand the landscape you need to map it and there as many maps as there are industrial landscapes. There's also not just one climatic pattern but many and these are useful in anticipation. There's not just one principle to follow but many patterns for doctrine that are universally useful for any organisation. There are also many forms of context specific gameplay which are used in scenario planning various plays. Finally you have the speed at which you loop around the cycle.
However, take one small area - doctrine - and the complexity expands.
Figure 2 - Components
There are least forty different forms of universally useful doctrine from focusing on user needs to a bias towards action to using appropriate methodology. Each of these in turn expands. For example managing inertia has 16 different types of inertia and different tactical plays for each.
Figure 3 - Doctrine
Figure 4 - Managing inertia
Of course, how you implement doctrine is also context specific. Thinking small as in team structure (e.g. Amazon two pizza or Haier's cell based teams) might be universally useful doctrine but the teams within Amazon will be different from the teams in Haier whether in size, composition or number.
With practice much of this becomes second nature, you learn to map, you to learn where inertia will exist in the map and the types of inertia to change that you're likely to face. You learn how to constrain complex spaces by dividing large scale businesses into small contracts and small teams. You learn how to constrain maps themselves creating an atlas for an industry with each node representing an entire map itself. It also all blends together with gameplay and anticipation of change to become part of the craft. You learn how to exploit the inertia of others or to design an organisation to cope with constant evolution. But there are layers of subtlety and many unexplored areas.
For example, I've long used doctrine as a way of examining competitors to determine how adaptable they are and hence what sort of gameplay I might use against them. I've provided two doctrine tables that have been completed by others - one for a US web giant that is tearing up industry after industry and one for a US investment bank. I'll let you decide who is who and where you fit between them and which you would prefer to face off against.
Figure 5 - Doctrine table 1
Figure 6 - Doctrine table 2
The problem of course, is whilst the list of doctrine has been developed from mapping many industries and finding patterns that are universally useful, I cannot actually say which components of doctrine matter more. Is transparency more important than a bias to action or is using appropriate methods more important than a focus on user needs. Sorting this out will take decades of data collection and as organisations evolve we will find that more universally useful principles emerge. However, as a rough guide the doctrine table appears useful enough for the time being.
Of course, without the priority order it becomes difficult to say which you should adopt first. Certainly some of these doctrine appeared significantly important in our Learning from Web 2.0 report published in 2012 but are they the most important? Also is there an order, are some dependent upon others?
Using experience, I can make an educated guess about which should be implemented in what order (as a discrete set of phases) but it's only a guess. For example, I know that implementation of a pioneer - settler - town planner structure (a topic of another post) should happen well after an organisation has increased its situational awareness, got used to applying different methodologies, started to appreciate the difference between aptitude and attitude whilst having implemented a cell based structure. You can't just charge in with pioneer - settler - town planner. There is an order to these things.
Figure 7 - Doctrine phases
This of course is just one small aspect of mapping. There are over 27 different forms of economic pattern used in anticipation with various weak signals. There over 70 different forms of context specific gameplay that I'm aware of - there are different types of disruption, even Porter's five forces have a context specific element. Mastering mapping is a daunting task and not one that I expect to achieve in my lifetime.
However, the good news is that you can learn in small steps. Just the ability to map an environment will get you to challenge assumptions (a form of doctrine), focus on user needs (doctrine), provides a systematic mechanism of learning (the map) and helps you appreciate that everything evolves (a climatic pattern). Loop around the cycle one more time and with two maps you'll start learning how to remove bias and duplication (another form of doctrine) by comparing them.
Every action you take, every loop around the cycle will dive you deeper into the subject and you will get faster in return. The speed at which I can map an industry today outstrips my early attempts to map a single line of business in 2005. But once started, be warned, it's hard to go back. As Chris would say "What is seen, cannot be unseen".
So I give you the choice. The blue pill means you go no further, you wake up in your land of SWOTs, stories, gut feel and magic secrets of success learned from the great and good of the management consultancy industry. The red pill ... ah ... start with chapter 1.
