From purpose to leadership and back again.

I haven't written in a while, so I thought I'd put down same rough notes on managing an environment. Contrary to popular belief, management isn't some linear game of planning but a highly iterative cycle. It's best described (in my opinion) in the following diagram by combining Sun Tzu with John Boyd.

Figure 1-  Tzu and Boyd.

The first part is to understand your purpose i.e. your scope and your moral imperative (the reason why others follow you). Your organisation consists of value chains but it operates in the value chains of others. So you need to understand what you are and who you interact with. This is the game that you are playing in for the time being. Please note that the process is iterative i.e. your leadership and action may well change the game you are playing in. There is no such thing as core to a company, it's all transient i.e. Nokia's purpose changed from when it was a paper mill to when it became a telecommunications provider. You are, in the words of Deng Xiaoping, "crossing the river by feeling the stones" or in other words, the best you can do is to have a direction and be adaptive.

Now, once you have a scope you need to understand your landscape. This is what we call situational awareness and it requires a map. To create a map you need several things. First you need an anchor (e.g. in chess it's the board, in a physical map it's the compass). Then you need the position of pieces relative to the anchor (i.e. the co-ordinates on a chess board for the queen or this unit is NW of this position in a map). Finally you need movement i.e. where the pieces have been and where they can go.

To do this in business, you can use a Wardley map. The anchor is user needs. Relative position is given in a chain of needs anchored on the user. Movement is provided by evolution. Be careful here, I often see utter howlers with people using diffusion as a replacement for evolution. They are not the same thing. An example map is given in figure 2.

Figure 2 - An example map.

There's a lot of things which call themselves maps but without position and movement, they're not a great deal of use for learning. There's another concept worth noting called flow i.e. flow between components (whether information, risk or money) but that's a little bit advanced for this post. It's also one that people regularly make a hash of by making ineffective flows more efficient. 

One you have a map, you need to understand the climate. Fortunately from the use of maps or boards, you can infer the rules of the game over time. You can do the same with Wardley maps. There are many rules in the business climate. For reasons of brevity, I'll just mention 13 of the simplest.

CLIMATE

1. Everything evolves : due to supply and demand competition.

2. Characteristics change : from the uncharted through transitional to the industrialised space.

3. No one size fits all : whether project management (agile vs lean vs six sigma) to purchasing to outsourcing.

4. Efficiency enables innovation : it's faster to build new things with pre-existing components than to start with everything from scratch.

5. Increased stability increases agility : an effect from componentisation.

6. Higher order systems create new sources of wealth : e.g.  standard electricity enables TV.

7. Capital flows to new areas of value : either the more commoditised form or moves up to the higher order systems. This is a key part of creative destruction.

8. No choice over evolution : the Red Queen effect.

9. Change is not always linear : known as a punctuated equilibrium

10. Success breeds inertia : There are in fact at least 16 different forms of inertia each with their own tactical plays to resolve.

11. Co-evolution : e.g. practice with activity, see DevOps.

12. Inertia kills : e.g. Blockbuster, Kodak. Neither of these companies were taken out by lack of innovation (they both out innovated the market). It was there pre-existing business models that hit them.

13. Disruption comes in multiple forms : there are many different forms but the two worth knowing about are predictable and non-predictable.

Once you understand the basic rules of climate (i.e. the rules of the game) including the various forms of cycles (e.g. peace, war and wonder) then you can do a pretty reasonable job of anticipation by using the map. But you need to know how to organise yourself around the map. Here we're into context free doctrine. By this I mean doctrine that applies in almost all situations regardless of the context (i.e. the environment). There are many of these but again for brevity I'll just mention seven.

DOCTRINE

1. Focus on user needs : start with transaction and then onto customer journeys. It's essential to focus on the user need and you won't be able to map without it.

2. Use appropriate methods : i.e. use agile or six sigma where appropriate. 

3. Remove bias and duplication : you can use multiple maps to do this fairly easily. 

4. Fast, Inexpensive, Simple and Tiny : go read up on Lt Col Dan Ward and FIST.

5. Use small autonomous teams : e.g. cell based structures, think Two Pizza (AMZN) or Haier. 

6. Think aptitude and attitude : e.g. pioneer, settler and town planner. This is still an area we're learning about. 

7. Eat your own dog food : i.e. don't sell what you're not prepared to use yourself.

At this point, when you're playing the game then you should have a good understanding of your purpose, your landscape, the climate and doctrine to be used. At which point we can add gameplay. Alas, there's a vast array of different forms of context specific gameplay that I'm now aware of. It's a bit like Chess or Military combat where there is all sorts of standard moves depending upon the context of the board or map. When playing the game you often use multiple at the same time.

There are lots we could go through but I'll just mention one as an example in business - the use of fool's mate - which is to attack an underlying part of the value chain when you wish to shift a higher order part of the same value chain.

The combination of the map and anticipation (from climate) gives you multiple points of attack (i.e. multiple wheres, see figure 3) and the use of context specific gameplay helps you determine why to attack this space over another. That's the key about strategy, the why is relative as in why here over there. You never start strategy with why, you always start with WHERE.

Figure 3 - Multiple Where

Of course, this is the decision point and your action can impact the game, your purpose, the landscape and so on. It's all iterative. A constant cycle of observe, orientate, decide and act. Except in most business it isn't.

Most business have no idea of the landscape they exist in. Hence they can't possibly hope to learn the rules of the game (i.e. the rules of economic climate). They certainly can't distinguish between context free doctrine and context specific gameplay nor do they have any mechanism for learning context specific gameplay. In most business, leadership is an exercise of writing down a purpose and jumping straight to strategy by copying what others are doing or gut feel or the use of verbal reasoning such as SWOT diagrams. It's a mess of memes normally. But then, that's not really surprising because if you can't visualise the environment in some form then how are you going to observe changes to it (you have nothing to compare to) and how can you orient around that? As figure 4 highlights, what could strategy be other than meme copying and gut feel? Is it really any wonder that corporate strategy documents tend to be a tyranny of action statements (how, what and when) with only the most vague notion of 'why' when we can't see where to attack or learn from our play?

Figure 4 - Lack of a map

However, that doesn't mean people are daft or can't change, the problem is they've been playing a game of chess without ever seeing the board or understanding that a board exists. I see this all the time. I run a workshop in which I take groups of LEF members through a scenario (using SWOTs, reports and financial analysis) in which they choose a set of strategic options and then later on they map the same scenario and discover (almost uniformly) how utterly mistaken their first attempts are. It's amazing to see and especially those lightbulb moments when they realise how they've been playing the game in their existing business. As one CIO of an enormous environment (think in the billions) said to me recently - "once you've mapped, it becomes so obvious that you wonder why you weren't doing this before".

Of course, you can learn to map in a day and do remember that all of this is creative commons. When you get good you can normally map an environment, work out the gameplay and determine how to attack a given space within a day or so. The trick is getting good and that, like Chess, takes practice. Many years of it. However, that's down to you. The only people who can map an environment and play the game are the people who work / live in that environment. You can't hand this off to consultants. You have to put in the effort.

Oh, but what about culture! That's another topic wrapped up heavily in doctrine with context specific elements and impacted by purpose and your choice of strategic play. However, given most people can't do the basics, I don't even think it's worth mentioning other than pointing out that you need more than one. But "culture eats strategy for breakfast" I hear some people cry. That's a soundbite which appears as popular as it is flawed. It has the accuracy of "the key to strategy is execution" or "you can't manage what you can't measure". But these are all more complex topics, better left to another day.

Managing a complex world

Going through some old talks, I dug up this video - I've now put it on Google - covering how to manage a complex world. It's from May 2008 and though I didn't go through mapping (back then I didn't realise that others might find mapping useful because I assumed everyone must do something like that) but it does cover innovation, evolution and how future organisational strain will be caused by rapid change. 

Alas, the best solution to this that I know of (as mentioned in the video) is a three party system e.g. Pioneer, Settler and Town Planners (or what I used to call Pioneer, Coloniser & Town Planner back in 2008). Eight years later and all the rage seem to be bimodal. Oh dear. There are many problems with such dual system approaches. You'll find out why you shouldn't soon enough.

It's amusing to note how many of the same problems still face companies today. These really shouldn't. Business thinking seems to progress very slowly ... except in China. However, that's another story for another day.

Sill, the presentation is not bad.

Two speed IT - the more I look, the worse it gets.

I've just been told of a "new" idea of using two speed IT with agile combined with a platform. Heaven help us. First, it's a very old idea and second it was as daft then as it is today.

Let's go through how things should work (see figure below). Your town planners (specialists in empires of scale) create your platform. Lets start with a simple code platform providing a utility like service. Your pioneers (the specialists of speed) build lots of new stuff on it. Your settlers (the specialists of learning, reducing waste) find the common patterns in all the new stuff and turn these into basic components whether products or libraries which they develop further. Let us be clear here, whilst your settlers may take "more" time to build a product or library component than your "hack it anyway it works" specialists, your settlers accelerate the speed of everyone building with those components. Hey, I just install the library rather than write one or there's an API to some rental like service (which is fairly stable).

Over time, your town planners convert these increasingly matured components into component services optimised for volume operations. Let us be clear here, these component services become extremely stable, change slowly (though new component services can be constantly added) and provide volume operations of good enough. Whilst the services may reliably provide volume operations of good enough, what "is" provided can be a highly standardised, less performing and less reliable component than available from the most super duper products. The key is volume operations, good enough, optimised for delivery and a very low mean time to recovery (MTTR) i.e. if the component fails, another is available rapidly. This forces architectural practice change (see Devops) but also the standardisation, change of focus, speed of delivery helps accelerate the speed of everyone who builds upon them.  For your pioneers, they don't have to install a library or product but instead they just use an API to a solid service which is super fast ... but they have to design for failure! It also helps your settlers who can include these component services in their libraries and products.

And so the cycle goes on and on, constantly driving us upwards and ensuring efficiency, agility, speed and removal of debt by the use of three groups, three speeds of operation, three types of people and three cultures. This was reasonable practice circa 2005.

So lets roll the clock forward to 2015. What we have is a "great" idea of one group builds the platform and then a second "agile" group running at a different speed builds the new things (see figure below). Certainly this might give you a short term bump in efficiency and delivery. The problem is there's no group identifying common patterns and evolving them. The "platform" group that builds industrialised component services aren't going to touch your flaky new "agile" thing (cue endless arguments to exacerbate any tension between the two groups). The agile team of course wants to move on, so they'll start building new things on top of their new things. This is a one way street to spaghetti junction, a bucket load of technical debt, an entire system that creaks and slows downs and a big "meeting" where we all get together to build the new platform of the future because the last one is now fscked. I've seen this so many times over the last decade that it ain't funny.

Two speed IT combining agile + platform ... that's my new shibboleth for the clueless. Almost anything is better than a big expensive platform effort which will grind to a halt requiring a huge future platform re-engineering effort and on and on. This is where you'll be heading and this is kids stuff. It's shockingly bad.

-- 6th January 2016 : On Speed
[added updates above]

Lots of people discussing the importance of speed. Please note, don't confuse the speed of how quickly something is built with the overall impact of the thing on speed i.e. it might take longer to build a library than a quick hack for the same activity but the advantage of the library is in re-use. The more industrialised something becomes then the speed of building / changing might become slower but the speed benefit it has on everything that is built on top becomes huge.

It's way quicker for me to chop down a tree and saw a plank of wood than it is to build a modern computerised sawmill. But if I need planks for a 100,000 homes then it's way better to have highly industrialised and standardised planks created by computerised sawmills than to have me with an axe and a saw.

-- 5th April 2016 : On Legacy
[added updates above to make clear the point]

Some people seem to think that "legacy" belongs with the town planners. Legacy is often the result of best architectural practice for consumption of a product which is different from best architectural practice for consumption of a utility. The issue is that architectural practice tends to co-evolve with the activity, so when we shift from product to commodity (+utility) then we get novel, then emerging, then good and finally best architectural practice for a commodity (+utility). In IT, we call this DevOps and I've written more on this subject in an earlier post.

Of course, though we experience this change of practice, we should be mindful that we've previously been through a cycle of novel, emerging, good and then best architectural practice for a product and the two sets of practices are fundamentally different as they are based upon different principles (e.g. low vs high MTTR, single vs volume instances, designed for purpose vs designed for delivery). A diagrammatic representation of this with respect to computing is ...



So often, the "legacy" can be found with the settlers who have built best architectural practice around consuming their product. This is the importance of theft, the town planners have to steal this activity from the settlers (overcoming any inertia), turn the activity into a more industrialised form (volume operations of good enough designed for delivery e.g. a cloud service for example) and allow for / encourage the development of a new set of architectural practices for consuming this commodity (+utility). In this case what's happening is your Town Planners are killing off the legacy that the Settlers want to hold onto.

Don't confuse Town Planners with the "keepers of the legacy", it just isn't so!

Legacy can incur throughout the structure i.e. there's co-evolution from custom built to product as well and so Pioneers are quite capable of building and maintaining for a very long time a mess of custom built legacy until someone drags it away from them (i.e. the Settlers). I know people talk about bimodal as having one part as managing the "legacy" and the other part managing "digital" but that's just ring fencing part of the organisation from inevitable change and giving them a justification to keep on doing what they were doing (often building data centres!)

I'm not a fan of bimodal, having experienced and been responsible for a dual party structure a decade ago. It creates a host of problems and rather than create a transition usually degenerates into utter warfare. If you're going to split into a "new" camp and "legacy" camp then you're going to be compounding these problems even more. You might as well call it Eloi vs Morlocks.

On a final note, "legacy" isn't something which belongs anywhere. A better description is Toxic IT and it's a debt to the past that is constantly created and needs to be constantly removed.

Can I just do Settlers and Town Planners as a Bimodal?

tl;dr : yes ... BUT.

Continuing on from the post on Bimodal, I was asked "Can I just do Settlers and Town Planners?"

Let us understand what that means. You're going to focus on product improvement and the industrialisation of a component but forgo the uncharted exploration of the novel and new. Well, there's no reason why you can't do this but it does means that you going to have to rely on the Settlers extending into the outside ecosystem to discover those novel and new components which at a later stage you will want to turn into products and finally industrialise (see figure 1). If you don't do this then you have no future pipeline.

Figure 1 - Focus on Settlers and Town Planners

For reference, I've given a fuller list of characteristics of the different roles in figure 2.

Figure 2 - Characteristics (you'll have to expand)

Ok, the problem with pushing all the novel and new to the outside market (i.e. taking an outside-in approach) is you'll be in a race with others to discover future patterns of success. This is not necessarily a bad thing unless :-

1) Everyone is trying to do this and there isn't some other system to exploit (see "How Much for a Fountain of Youth")

or more likely

2) Someone is playing an ILC ecosystem game against you (or a variant such as Tower & Moat).

I won't go through the ecosystem game, you'll have to read that post but the net effect is they can use their ecosystem as a future sensing engine and the bigger their ecosystem, the more powerful the effect will be. This means they'll not only have the edge on you but this edge will become larger over time compared to simply trying to scan the market.

So, yes you can just use a Settler & Town Planner structure but you'll need really high levels of situational awareness, ecosystem play, weak signal detection or otherwise you'll be an easy target with nothing in the bag (i.e. novel surprises) and a simple pipeline to choke.

If you really want bimodal then you'll need to give something up.

Back in 1993, Robert Cringely wrote the excellent book Accidental Empires (I have the 1996 reprint) which talked about the three different type of companies using the metaphors of commando, infantry and police.

During 2004-2006, having discovered a process of technology evolution and a mechanism of understanding the competitive landscape (known as Wardley mapping), I implemented the equivalent three party structure (known as pioneers, settlers and town planners) to mimic evolution within a single company. A description of this three party system can be found here and the importance of the middle for sustainable and competitive advantage. Over the last decade, I've written numerous articles and gave lots of presentations around the world on the three party structure and the importance of the middle.

In 2014, I came across bimodal / dual operating system and twin speed IT. I can't tell you how much this caused me to howl with laughter. I'm no fan of these concepts. I view them as old ideas, poorly thought through and dressed up as new. I've seen two party systems in the past that have degenerated into 'them' vs 'us' and with no consideration of how things evolve they are not sustainable. There is no effective process for how the new (i.e. tomorrow's industrialised components) become industrialised. The idea that somehow the two groups will work together in a 'dance' is fanciful. Brawl would be more like it. Pioneers and Town Planners are polar opposites, they don't get on well.

I'm quite convinced that those undergoing re-organisation into bimodal will be facing a future re-organisation into a more three party or spectrum based structure in the near future. Certainly that means oodles of cash for consultants advising on these multiple re-organisations and be honest, I don't care if it's private companies that I'm not involved with. My concern is this spills over into Government Departments.

There is however a way of creating a workable bimodal structure but it means you need to give something up. To remind readers, the three parts for which you need brilliant people are :-

Pioneers. Pioneers are brilliant people. They are able to explore never before discovered concepts, the uncharted land. They show you wonder but they fail a lot. Half the time the thing doesn't work properly. You wouldn't trust what they build. They create 'crazy' ideas. Their type of innovation is what we call core research. They make future success possible. Most of the time we look at them and go "what?", "I don't understand?" and "is that magic?". In the past, we often burnt them at the stake. They built the first ever electric source (the Parthian Battery, 400AD) and the first ever digital computer (Z3, 1943).

Settlers. Settlers are brilliant people. They can turn the half baked thing into something useful for a larger audience. They build trust. They build understanding. They learn and refine the concept. They make the possible future actually happen. They turn the prototype into a product, make it manufacturable, listen to customers and turn it profitable. Their innovation is what we tend to think of as applied research and differentiation. They built the first ever computer products (e.g. IBM 650 and onwards), the first generators (Hippolyte Pixii, Siemens Generators).

Town Planners. Town Planners are brilliant people. They are able to take something and industrialise it taking advantage of economies of scale. They build the platforms of the future and this requires immense skill. You trust what they build. They find ways to make things faster, better, smaller, more efficient, more economic and good enough. They build the services that pioneers build upon. Their type of innovation is industrial research. They take something that exists and turn it into a commodity or a utility (e.g. with Electricity, then Edison, Tesla and Westinghouse). They are the industrial giants we depend upon.

The process of evolution (see figure 1) causes a change of characteristics which is why you need multiple attitudes and why one size fits all methods don't work (i.e. why agile, lean and six sigma should die and be replaced by agile plus lean plus six sigma). 

Figure 1 - Evolution

If you want to create a bimodal / dual operating system structure out of this then you really have to give up on one part. For example :-

You could focus on Settlers and Town Planners alone i.e. your company could all be about product development and industrialisation. Simply drop the pioneering research function. The best way to do this is with the press release process i.e. force the writing of press release before any project starts because no-one can write a press release for something unexplored. Don't attempt to do any pioneering stuff and instead use ecosystems models such as ILC or some equivalent to do future sensing. 

You could focus on Pioneers and Settlers alone i.e. your company could develop novel concepts and then create products out of this. Simply drop the town planning function and outsource all industrialised components (including dropping your own products) where appropriate.

You could decide to focus on just one aspect i.e. be Pioneers (develop novel concepts), be Settlers (create great products) or be Town Planners (create highly industrialised commodity and utility services).

However ... 

1) DON'T try and break into Pioneers and Town Planners. These two groups are far apart. You'll create a them vs us culture. None of the novel concepts will ever be industrialised because the Pioneers won't develop them enough and the Town Planners will refuse to accept them for being underdeveloped. Both groups feel they are the most important and both ridicules the other.

2) DON'T bury your Settlers into one of these groups. They won't feel welcome, they will be in conflict with the group becoming second class citizens. Put them in the Pioneer group and they'll be denigrated to documenting the "glorious" inventions of others and fighting a losing battle over user needs. Stick them with Town Planners and they'll be seen as 'lightweights', the people whose job it is to deal with those annoying Pioneers and document what they've done etc.

Either drop one aspect (i.e. Pioneers or Town Planners), or focus solely on one aspect (i.e. Pioneer, Settler or Town Planner) or focus on ALL three. This means the Settlers (the missing middle) need to be recognised.

Create one mode to focus on "core system maintenance, stability, efficiency, traditional & slow moving development cycles" and another mode to focus on "innovation & differentiation with high degree of business involvement, fast turnaround & frequent update" ... well, Pioneers and Town Planners don't mix and creating two camps focused on this won't make for a happy environment.

Oh, but isn't Bimodal / Dual better than Unimodal / Single? No, I'm far from convinced that this is the case. In the past many ignored evolution and squashed all three attitudes, cultures and type of people into one group called IT, Finance, Marketing or whatever (yes, evolution impacts everything we do). Those groups would tend to yo-yo in methods between the extremes hence in IT we had Agile vs Six Sigma (ITIL etc) battles. But every now and then the 'middle' would get its chance. Today you're seeing this with Lean, with focus on user needs etc.

If you organise by the extremes e.g. pioneers and town planners or mode 1 and mode 2 or whatever you wish to call it then you're burying the middle. This is not good. This middle group are not mode 1 or mode 2 but they have a vital role to play. They deal with the transition between the extremes. However in a dual structure then you've given the other attitudes a flag to rally around, you've formalised a structure to support this and left the settlers singing in the wind. You've gone from ignoring them (which you did to all attitudes under one group) to actively discouraging them and sending a message that only pioneers and town planners matter.

Well, you've been warned, tread this path carefully. This will be my last post on this subject (I hope) given it's such old hat but I'll come back in a decade and we shall see what has happened to these dual structures.

P.S. The mapping technique, the characteristics, the use of multiple methods, the pioneer / settler / town planner structure and a host of other stuff you'll find in this blog is all ... creative commons share alike. You can do this yourself. You don't need external consultants, license fees etc.

The only structure you'll ever need ... until the next one.

Back in 2004, I was the CEO of Canon subsidiary and I faced multiple problems. We had issues of business & IT alignment, poor communication, dissatisfaction and clarity of strategy.  Don't get me wrong we had strategy documents but they were pretty much identikit copies of every other company out there. What we did, and what I've later refined solved [for us] many of those problems because they're all associated with a lack of situational awareness.

The first part of this journey was creating a map of our landscape. The map has two elements. It showed the position of the pieces and how they could move. The position was expressed through a value chain from the user needs to the components required to meet those needs. The movement was expressed through an evolution axis that covers activities (what we do), practice (how we do things), data and knowledge. I usually simplify that axis to show activities alone but in this case (see figure 1) I've added a table to show all the different elements. In other words on a single map you can show activities, practices, data and knowledge if you choose to do so.

Figure 1 - A Map

Table 1 - Different Classes. Terms used.

Oh, and where did I get the idea of producing a map from? I nicked it straight out of Sun Tzu's Art of War and the emphasis on understanding the landscape before taking action. Don't get me wrong, these maps are imperfect but they act as vehicle for discussing, learning and understanding the environment.

When I first produced the map of my company, I didn't realise the importance of sharing it outside the executive team. Our map had our strategic play on it. We had quickly learned a number of common economic patterns, how characteristics of components changed as they evolved (from the uncharted to the industrialised) and methods of manipulating the landscape (from open source to patents to constraints).

We used the map to determine where we could attack and from this formulated the why (as in why here over there). Hence we moved into the cloud in 2005 building the first public platform as a service.  I used the same technique to help Canonical successfully attack and dominate the cloud space in 2008 against massive (and vastly better funded) foes.

I subsequently learned that by sharing the maps I could not only improve situational awareness but also help remove bias, silos, misalignment and inefficiency in organisations and also provide a clarity of purpose throughout the organisation. Every team knows the maps (there's often a master and many sub maps for specific areas). They know where their part fits in. 

When it came to organisation then I used a Pioneer - Settler - Town Planner structure. This is a derivative from Robert Cringley's Accidental Empires, 1993. By derivative, I mean I nicked it or shall we say repurposed a description of companies to running a single company.

The first step is to break the map into small components managed by small teams. Today, we describe this through cell based teams with each team less than twelve people (the Amazon two pizza rule) or use other concepts such as microservices, composability etc. The team should have autonomy over how it organises and runs itself but should have certain conditions (i.e. a fitness function) that it is measured against. Oh, you can guess ... this was nicked from the 1970s and the use of workgroups.

The problem however is that whilst each team will require certain aptitudes (e.g. engineering, finance, market), those skills change in attitude as the components that team manages evolve. For example, engineering in the uncharted space is agile but in the industrialised space it is more six sigma (see figure 2). Oh, and that diagram is a derivative from Solomon and Storey's innovation paradox of 2002.

Figure 2 - Changing Characteristics and Methods with Evolution.

Back in '04/'05, we had Agile and Six Sigma and were struggling with the missing middle and methods associated with it. We saw the same problem with purchasing, with finance, with operations, with marketing. We also noticed that some people were more adept at one end of the spectrum than the other.

We also knew that new things appeared in the market and were bolted onto organisations, just like Chief Digital Officers are being bolted on today. We also knew that the new stuff is tomorrow's legacy. So, we decided to mimic the outside process of evolution internally within the organisation. We created a structure based on pioneers, settlers and town planners and let people self select which group they were in. We started with IT and rolled the rest of the business into it. We also introduced a mechanism of theft to replicate the process of evolution in the outside world. See figure 3.

Figure 3 - Pioneer, Settler and Town Planner

The advantage of this method is we recognised that there isn't such as thing as IT or finance or marketing but instead multiples of. There are multiple ways of doing IT and each have their strengths, their culture and a different type of person.  In 2005, we knew that one culture didn't work and enabling people to gain mastery in one of these three domains seemed to make people happier, more focused. Try it yourself, take a pioneer software engineer used to a world of experimentation and agile development and send them on a three week ITIL course. See how happy they come back. Try the same with a town planner and send them on a three week course of hack days & experimentation with completely uncertain areas and lots of failure. 

What we realised back then is we needed brilliant people in all three areas. We needed three cultures and three groups and each one has to excel at what it does.

Pioneers are brilliant people. They are able to explore never before discovered concepts, the uncharted land. They show you wonder but they fail a lot. Half the time the thing doesn't work properly. You wouldn't trust what they build. They create 'crazy' ideas. Their type of innovation is what we call core research. They make future success possible. Most of the time we look at them and go "what?", "I don't understand?" and "is that magic?". In the past, we often burnt them at the stake. They built the first ever electric source (the Parthian Battery, 400AD) and the first ever digital computer (Z3, 1943).

Settlers are brilliant people. They can turn the half baked thing into something useful for a larger audience. They build trust. They build understanding. They learn and refine the concept. They make the possible future actually happen. They turn the prototype into a product, make it manufacturable, listen to customers and turn it profitable. Their innovation is what we tend to think of as applied research and differentiation. They built the first ever computer products (e.g. IBM 650 and onwards), the first generators (Hippolyte Pixii, Siemens Generators).

Town Planners are brilliant people. They are able to take something and industrialise it taking advantage of economies of scale. They build the platforms of the future and this requires immense skill. You trust what they build. They find ways to make things faster, better, smaller, more efficient, more economic and good enough. They build the services that pioneers build upon. Their type of innovation is industrial research. They take something that exists and turn it into a commodity or a utility (e.g. with Electricity, then Edison, Tesla and Westinghouse). They are the industrial giants we depend upon.

I know Lou Adler talks about how there are only four different types of jobs in the world - thinkers, producers, builders and improvers - well, I've found you can get away with three. Pioneers are more thinkers / builders. Settlers are more builders / improvers. Town planners are more improvers / producers.  Of course, every group needs to think and communicate (which is what maps help with) but this approach seems to work fine. Also, whilst everyone tends to have a bit of everything they also tend to dominate in one attitude over another. So encourage that specialist attitude, let them develop into master pioneers or master town planners. Lastly, it may well turn out that a four party or even more spectrum like approach is needed. I've never pushed it beyond three distinct groups, so I don't know. I do however know that breaking into two groups tends to end up with internal warfare and them vs us whereas three distinct groups seems to resolve that conflict.

Combining with a map and a cell based approach then what you end up with is figure 4.

Figure 4 - PST in a cell based organisation.

It's important to note :-

1) The maps are essential to this process. They also give purpose to each team. You know what you're doing, where you fit in.

2) The cell based structure is an essential element of the structure and the maps should be used to create this. Those cells need to have autonomy in their space, they must be self organising. The interfaces between the teams are used to help define the fitness functions. Co-ordination between teams can be achieved through Kanban. If a cell sees something they can take tactical advantage of in their space (remember they have an overview of the entire business through the map) then they should. 

3) The cells are populated with not only with the right aptitude but attitude (pioneers, settlers and town planners). This enables people to develop mastery in their area and allows them to focus on what they're good at. Let people self select their type and change at will until they find something they're comfortable with. Reward them for being really good at that.

4) The process of theft is essential to mimic outside evolution. All the components are evolving due to supply and demand competition which means new teams need to form and steal the work of earlier teams i.e. the settlers steal from the pioneers and the outside ecosystems and productise the work. This forces the pioneers to move on. Equally the town planners steal from the settlers and industrialise it, forcing the settlers to move on.

5) The maps should also show the strategic play. Don't hide this, share it as well as target of opportunities.

6) As new things appear in the outside world they should flow through this system. This structure doesn't require bolt-ons which you need to replace later. No chief digital, chief telephony, chief electricity, chief cloud officer required.

7) As the cells grow they should subdivide into smaller teams (keep it less than 12 to a cell). The map can help them subdivide the space, each with new fitness functions. As you get larger, you'll need to structure the communication between cells more using a hierarchy. Yes, that means you need a hierarchy on top of a cell based structure.

8) The map MUST start from user needs at the top. It has to be mapped over evolution (you can't use time, diffusion or hype cycles to do this - none of that works).

9) The executive structure becomes a CEO, a Chief Pioneer, a Chief Settler and a Chief Town Planner (think of Cringley's original commandos, infantry and police) though you'll probably use more traditional sounding names such as Chief Operating Officer, Chief Scientist etc. We did. I'm not sure why we did - can't remember the reason for this. We also called the groups when we started in IT - developers, frameworks and systems. These days I wouldn't bother, I'd just make it clear and move. You will need separate support structures to reinforce the culture and provide training to each group. 

10) Any line of business, described by a map, will have multiple cells and therefore any line of business is likely to contain a mix of pioneers, settlers and town planners all operating to a common purpose. See figure 4.

Now, PST is a structure I've used to remarkable effect in a very small number of cases. That's code for 'it might just be a fluke'. However, in the last decade I've seen nothing which comes close and instead I've seen endless matrix / dual and other systems create problems. Is it suitable everywhere? No idea. Will something better come along ... of course it will. However, to invoke Conway's law then if you don't mimic evolution in your communication mechanisms (e.g. through a mechanism of theft) then you'll never going to cope with evolution outside the organisation.

So how common is a PST structure? Outside certain circles it's non-existent, never been heard of. At best I see companies dabbling with cell based structures - which to be honest are pretty damn good anyway and probably where you should go. Telling companies they need three types of culture, three types of attitude, a system of theft, a map of their environment, high levels of situational awareness is usually enough to get managers to run away. It doesn't fit into a nice 2 x 2. 

It also doesn't matter for most organisations because you only need high levels of situational awareness and adaptive structures if you're competing against organisations who have the same. Will it become relevant over time ... maybe ... but by then we will have found the next 'best thing'.

A debt of thanks
A bit of digging in the old memory banks, brings me to Robert X. Cringely's book, Accidental Empires reissued in 1996, page 235 - 238. Copying some quotes from that book (which I recommend people go buy and read), the ideas of pioneers, settlers and town planners are all there but used to describe companies rather than how a single company operates. I knew it had come from somewhere.

Think of the growth of a company as a military operation, which isn't a stretch, given that both enterprises involve strategy, tactics, supply line, communication, alliances and manpower.

Whether invading countries or markets, the first wave of troops to see battle are the commandos. Commando's parachute behind enemy lines or quietly crawl ashore at night. Speed is what commandos live for. They work hard, fast, and cheap, though often with a low level of professionalism, which is okay, too, because professionalism is expensive. Their job is to do lots of damage with surprise and teamwork, establishing a beachhead before the enemy is even aware they exist. They make creativity a destructive art.

[Referring to software business] But what they build, while it may look like a product and work like a product, usually isn't a product because it still has bugs and major failings that are beneath the notice of commando types. Or maybe it works fine but can't be produced profitably without extensive redesign. Commandos are useless for this type of work. They get bored.

It's easy to dismiss the commandos. After all, most of business and warfare is conventional. But without commandos you'd never get on the beach at all. Grouping offshore as the commandos do their work is the second wave of soldiers, the infantry. These are the people who hit the beach en masse an slog out the early victory, building the start given by the commandos. The second wave troops take the prototype, test it, refine it, make it manufacturable, write the manuals, market it, and ideally produce a profit.  Because there are so many more of these soldiers and their duties are so varied, they require and infrastructure of rules and procedures for getting things done - all the stuff that commandos hate. For just this reason, soldiers of the second wave, while they can work with the first wave, generally don't trust them, though the commands don't even notice this fact, since by this time they are bored and already looking for the door. While the commandos make success possible, it's the infantry that makes success happen.

What happens then is that the commandos and the infantry advance into new territories, performing their same jobs again. There is still a need for a military presence in the territory. These third wave troops hate change. They aren't troops at all but police. They want to fuel growth not by planning more invasions and landing on more beaches but by adding people and building economies and empires of scale.

Robert X. Cringely, Accidental Empires, 1996 (the reissued, I don't own the original).

What Robert called Commandos, Infantry and Police is what I later called Pioneers, Settlers and Town Planners. The two are identical except Robert was there much, much earlier. In fact 1993, a good ten years before I implemented the "trimodal" structure and 21 years before Gartner and others came up with the bimodal / dual operating system / two speed IT concept

I owe Robert Cringely a debt of thanks. Also, I'm not a fan of dual operating system as I take the view that continual and sustainable competitive advantage comes from managing the middle not the extremes.

[1st October 2015]

Added the descriptions of Pioneers, Settlers and Town Planners and why every group needs to be awesome / brilliant.

Added a link and comments on Lou Adler's four roles.

Continuous and Sustainable Competitive Advantage comes from Managing the Middle not the Ends

The mechanics of biological and economic systems are near identical because they're driven by the same force - competition. The terms we use to describe economic systems from evolution, punctuated equilibriums, ecosystems, red queen, cell based structures, co-evolution, componentisation, adaptive renewal cycle and so forth, all have their origins in biology. 

I'm going to use a few of these to argue why the future of continuous and sustainable competitive advantage comes from the middle not the ends of evolution. If you are completely new to Wardley mapping then I'd suggest starting here.

First, we need to understand evolution. Evolution is not the same as diffusion. It describes how something evolves as opposed to how a particular instance of something diffuses (see Everett Rogers) in an ecosystem. 

Evolution is not predictable over time but it occurs over time. The best model I know of describing evolution is given in figure 1. It's based upon a pattern that was described in 2004 and primary research to determine why that pattern occurred between 2006 and 2007.

Figure 1 - Specific form of Evolution

It's the combination of supply and demand competition that causes things to evolve along a standard pathway. As things evolve their characteristics change. However, evolution doesn't just impact activities (the things we do). It also impacts practice (how we do things), data (how we record things) and even the mental models that we create (how we understand things).

The general form of evolution is given in figure 2 and in table 1, the characteristics of the different classes along with several general economic patterns are provided.

Figure 2 - General form of Evolution

Table 1 - Characteristics of General Form.

There are all sorts of subtle interaction (e.g. co-evolution of practice with activities, how to define ubiquity) but that's not the purpose of this post. What I want to concentrate on is the issue of evolutionary flow i.e. the competition that causes all things to evolve.

As a thing evolves then it enables higher order systems to appear through an effect known as componentisation (see Herbert Simon). For example, utility electricity provision enabled television, radio, electric lighting and digital computing. These news things exist in the unexplored territory, the uncharted space. They are about experimentation and exploration. They are only economically feasible because the underlying subsystems (i.e. the things they need, such as power) became more industrialised.

When this happens, visible user needs are no longer about the underlying subsystem but instead about the new higher order systems that have appeared. People only want electricity in order to power their computer, their TV, their radio and so forth. 

These higher order things are the visible user need, the underlying subsystem becomes increasingly buried, obscured and invisible. But any new higher order thing also evolves e.g. digital computing has evolved from its genesis to utility forms today. This in turn allows an even higher order of systems to be built.

When I use a cloud service, I don't care about the underlying components that the supplier might need (e.g. computing infrastructure). I care even less about the components below that (e.g. power).  I did care many years ago about things like servers and even power but today I care about what I can build with cloud services. Those underlying components are far removed from my visible user need today. Why? Because I'm competing against others who also use these services.

It is supply and demand competition that creates the evolutionary pressure which drives the novel to become the commodity, the uncharted to become the industrialised and the cycle to repeat. For activities that means genesis begets evolution begets genesis (see figure 3). For knowledge it means concept begets universally accepted theory begets concept.

Figure 3 - Genesis begets evolution begets Genesis

As an aside, this cycle has specific effects. It has three stages of peace, war and wonder due to its interaction with inertia to change. There are numerous forms of inertia and they act as what Allan Kelly described as a homomorphic force.  This cycle has a corollary in Hollings adaptive renewal cycle which is unsurprising given both are driven by competition. The war element of the cycle creates a punctuated equilibrium with the past due to network effects of competition i.e. the more people adapt the more pressure to adapt increases. The latter is known as the Red Queen Effect.

Of course, whenever you examine something it has a past, a present and a future. If I use a cloud based analytic service, I know it needs an underlying computing infrastructure, I know that computing infrastructure needs power and I know that the generators that make power need mechanical components. I also know that all these components evolved and were once novel and new. They each had their genesis. 

I've shown this constant evolution in figure 4. What's important to remember is the chain of needs (shown in a solid black line) is a line of the present. Those components evolved from the past and are evolving into the future (the dotted lines). The further you go down the chain, the more invisible the component becomes to the end user.

Figure 4 - Chain of Needs, The line of the present.

Being able to show the present on a landscape of what something is (the value chain) against how it is evolving (change i.e. past, present and future) is what mapping is all about. It's an essential activity for improving situational awareness, gameplay, operations and organisational learning.

It's key to understand that a map is a picture of the present in a dynamic landscape. All the components are evolving due to competition. That evolutionary flow affects everything. But if you know this, if you understand how evolution works, the change of characteristics, the requirement for different methodologies and common economic patterns, then you can exploit this. Figure 5 has an example map and a particular play known as Fool's mate.

Figure 5 - Map

With a map you can mitigate risks, obliterate alignment issues, improve communication and even examines flows of business revenue along with a host of other techniques. With enough maps you can remove duplication and bias in an organisation. 

You can also use maps to organise teams into cell structures and to solve the issues of aptitude and attitude i.e. we might have lots of engineering (an aptitude) but the type (an attitude) of engineering we need to create novel activities is different from the type of engineering we need to run an industrial service. This is a structure known as Pioneers, Settlers and Town Planners - a derivative of commandos, infantry and police from Robert X. Cringely's Accidental Empires, 1993.

You can use maps for scenario planning, for determining points of attack (the WHERE of strategy,  WHY is always a relative statement such as why here over there) and you can even create a profile of a company, an industry or a market i.e a frequency count of where components are along the evolutionary scale. 

Why bother with a profile? 

The components in the profile are all evolving from left to right (i.e. competition drives them to more industrialised). If nothing novel was ever created then it would all (assuming effective competition) become industrialised. You can use a profile to determine the balance of your organisation and whether you need more pioneers, more settlers or more town planners (see figure 6).

Figure 6 - Profile

To give you an idea of how to apply the three party structure. I've covered this before (many, many times) but this diagram will help.

Figure 7 - Applying PST (Pioneer, Settler and Town Planner) to a Map

As with the need for using different methods whether purchasing or project management (agile for genesis, lean for transition, six sigma for industrialised) then the roles of pioneers, settlers and town planners are different. So, is their culture. So is the way they organise. So are the type of people. See figure 8.

Figure 8 - Characteristics of Pioneer, Settler and Town Planner

Ok, but what has this to do with the middle?

The settlers and the transitional part of the profile, that is your middle.

This form of structure is the only way I know of sustainably solving the Salaman and Storey innovation paradox of 2002. This isn't "nice ideas", this came from competitive practice over a decade ago and subsequent re-use. Why it worked so well could only be explained afterwards in 2007 when the evolution curve went from hand waving pattern to something more concrete.

Of course, the techniques of mapping and evolution have evolved themselves over the last decade. Mostly this is by refining the terms used to make the language more transparent to others or through more adoption. However, every now and then something new appears and the latest addition is from a post by Dan Hushon on 'Digital Disruptions and Continous Transformation'. If you're familiar with mapping, I recommend you go and read now!

There's an awful lot to like in Dan's post. However, to explain why it's important, you need to first consider that a map can also be used to provide information on business revenue flows i.e. you can investigate a map to identify different business opportunities (see figure 9)

Figure 9 - Business Revenue Flow.

Some of those revenue streams will be profitable, others not. But even with a profitable revenue stream then this won't remain static. Take for example the pipeline of content in figure 5 above from commissioned shows to acquired formats i.e. the evolution of a new show like X-factor to a broadly repeated format show. The nature of the show has evolved.

With anything new (i.e. genesis) then you'd expect to add a high margin because of the risk taken. As that thing evolves and becomes more widespread and defined,  then you'd expect the margin per unit should be reduced and compensated with a much greater volume in a functioning marketplace.

In his post, Dan looks at this from the point of view of value vs evolution and overlays a PST (pioneer - settler - town planner) structure. I've slightly modified this but kept very close to the original in figure 10. This is not a graph of how things are, it's a concept that hasn't been tested yet. But evolution would suggest that this is how things should operate.

Figure 10 - Modified version of Dan Hushon's Graph

Why do I like this graph so much? Well, think of your organisation. You have core transactions you provide to others (in order to meet their needs). Those core transactions consist of underlying components (which can be mapped) that are evolving, These components effect the profitability of the transaction. The transaction itself is also evolving. As it evolves, the margin (or value) created by each unit of transaction should also change and reduce. Novel transactions should show high value per unit (and high margins). Commodity transactions should show low value per unit (and low margins) over time. 

You can use this graph to create a financial profile of your organisation and where your transactions are. They should all be evolving along the arrow. Of course, as transaction evolve to more commodity then you should be looking for those higher order systems to replace them. This can be used to create a financial pipeline for change and whilst the ends are important, it's the middle we really need to manage, the flow from one to another.

Ok, I get this but why is the middle so important?

If it wan't clear, situational awareness is key to a vast number of aspects of managing an organisation and the ONLY way I've found to significantly improve situational awareness is to map and compare the present against evolution. 

Evolution shows us that we're living in a dynamic environment with the constant flow of change from the novel to the industrialised. This impacts everything from project management to purchasing to team structure to finance.

Whilst there are two extremes (the uncharted vs industrialised, the genesis vs commodity) which require polar opposites in methods, culture and structure (Salaman and Storey, Innovation paradox, 2002) and everything (activities, practice, data and knowledge) in a competitive market (with demand and supply competition) evolves from one extreme to another ... there is a constant. That constant is change. The middle represents and governs this evolutionary flow from one extreme to another.

Yes, it's important to manage the extremes but both extremes can be outsourced either to suppliers or through the use of an ecosystem model, such as ILC.  Some firms will be able to hide in the relative safety of the industrialised space using ecosystem models to sense the future. Some will try and survive in the high risk space of constant genesis. For most of us then the one thing you need to manage above anything else is the flow between the extremes. This is where all the tactical plays matter. This is where situational awareness is critical. For most us, this is where continuous and sustainable advantage can be gained.

If you're going to build a two mode structure (bimodal, two speed IT, dual operating system etc) then do so by eliminating the pioneers from your organisation. Focus on creating public APIs for utility services and get every other company to build on top of it. Let everyone else be your R&D labs and your pioneers. Hide in the industrialised spaces and use ecosystems as your future sensing engines. Remove that pioneering capability internally through the use of a press release process i.e. force everyone to write a press release before the project hence preventing anyone creating the novel & new. Use the skills of the settler to mine the ecosystem for new successful changes which you then industrialise with town planners to commodity components or utility services. Alas, there's only a limited number of firms who can play that game.

This is why I'm not a fan of bimodal, dual operating system, two IT speed concepts in general. Most of us have to cope with the entire spectrum of evolution. These two mode methods appear to focus the mind too much on the extremes creating two groups which will exacerbate the internal conflict. It doesn't matter if they've included the all important middle (the transitional part, the settlers) in one group or another or if you have a little 'dance' between the groups. You've just buried that which truly matters.

The Settlers (like Cringely's infantry) are key. They make success happen. They control your destiny. They make the entire process sustainable. They play the most important games. They are where open source becomes a weapon. They are mostly ignored in favour of the extremes. Let us "take the pig and lipstick it" seems to be the mantra. Bolt on a digital side to our legacy and ignore the fact that the digital will itself become legacy over time. What do we call the legacy then? Legacy Legacy with Legacy Digital and New Digital ... let us add some more lipstick?

Organising by extremes creates two opposing camps, conflict and bottlenecks are inevitable and something I've seen over the last decade. Yes, these two mode methods may give you a short term boost in terms of efficiency and innovation but it's the sustainability issue that's the problem. That's why I strongly suspect in a decades time, the same people telling you to become a two mode type organisation will be flogging you a three mode solution to your new two mode problems. Save yourself the trouble and another round of re-organisation.

On the upside, all the mapping stuff (2005 onwards), all the profile work, flow, the PST structure and ILC models are creative commons share alike. It's all scattered throughout this blog and has been presented at hundreds of conferences between 2007 to 2014.

That's an invitation to help yourself.

Improve your situational awareness. Learn to play the game.

You'll soon discover why the "middle" is the all important battleground.

Oh, and on the question of bias ... am I biased towards mapping? Yes! I've been using mapping to outplay other companies in many commercial markets for over a decade and more recently in the last four years within Governments. I'm as biased as you can get. In my world, situational awareness helps. Yes, it's also true that maps are complex. In some cases, you can spend a whole day to create a first map that you can use.

--- 18th March 2015

Added figure 7 just so people can make the jump between PST and a map.