Thursday, May 25, 2017

Blue pill or red pill?

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. 

Figure 1 - The strategy 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.

Friday, May 12, 2017

Is my diagram a map?

Let us take a systems map


It is visual and context specific (being a system diagram of an online photo service and not a self driving car). It has components and the relationship between components. We also have the flow of information (blue line) between components. But does this make it a map? I've shaded one box (CRM) in grey and moved it.


The components and the relationship remain the same. It's still visual, it's still context specific specific and nothing alters with flow. The diagram is in essence identical but yet I've moved a box. Let us compare this with a road map of major roads in the UK.

It's visual and it's context specific (being the UK not France). The diagram has components, relationships between them and also flow (e.g. the movement of traffic). But it has more than this. The compass acts as an anchor, the components have position relative to each other (London is North East of Southhampton) and we have a concept of movement. If I wanted to walk from London to Exeter (not travelling along the major road) then I could head South South West (roughy). The diagram is not very accurate, it lacks scale but is this a map? Let us move the component I've marked in grey (Nottingham).


By moving the component I've fundamentally changed the meaning of the map. Nottingham is no longer North of London but SSW of London which of course, a quick flight across the territory will tell you is wrong. The map (and this diagram is a map) helps you explore the territory. It does so because it has the characteristics of navigation e.g. anchor, position and movement. Without such characteristics you cannot learn about the territory.

Whilst the road map is a map, the systems map is in fact not a map. It lacks those navigational characteristics which enable us to learn about the territory. We might call it a map, in the same way I might call myself a Jedi but it's not the name but the characteristics that define what something is. I still lack the powers of the force no matter how many times I tell myself that I am a Jedi.

A map must be visual and context specific. It must have components but more than this it requires an anchor, position and movement. The quickest way I know to determine if something is a map or not is to move a component (i.e. use movement) and see if this changes the meaning of what is being looked at. If it doesn't then it's not a map and hence it is of little use for learning about a space. 

Almost everything we call a map in business - systems maps, business process maps, mind maps, digital maps, product road maps, strategy maps - are not in fact maps. They are diagrams.  If you want to map a business then I've written the best part of a book (all creative commons) on how to actually do this.