The wow of mapping

So far, I've covered then good bits of mapping - namely focus on user needs, coping with change, effective management of complex environments and contracts, better scenario planning and strategic gameplay, improvements in communication and risk management and the ability to identify opportunities from system level to policy - along with the Amazing aspects of mapping of better situational awareness (correlated with market cap growth) & organisational learning, initiation of potentially more effective organisational structures and heightened ability to anticipate change.

The above is a 'kick ass' list of business superpowers however it is nothing compared to what's next.

If you haven't read those two posts - STOP! Go read both of them - the good bits of mapping & the Amazing aspects of mapping - and then return.

The conclusions of this post are also the most controversial because the examples are rare in the extreme and data is very thin. However, if this concept is right then to give the 'wow' a title then it has to be :-

1) Organisations don't need one culture, they need three.

First, a bit of background. I noticed this effect first in 2004 when I implemented the first early prototype of a Pioneer, Settler and Town Planner structure in Fotango. Of course, back then I was experimenting without a clear understanding of why the new structure improved our efficiency and innovation so effectively. I do now, or at least I have a pretty good idea why.

To explain why, we need a little bit of a journey. First, when mapping a business you need to get people involved in the organisation to do the mapping and preferably large numbers of them. This is because one of the axis of evolution is certainty and it's actually difficult to precisely say where something is on such an axis. You can use the wisdom of the crowd effect (see Marquis de Condorcet) but this requires each voting member to be 'more likely than not to make a correct decision'. Hence it has to be people experienced in the business and the environment itself i.e. there's no general consultancy gig in mapping and if any consultant offers to map your business ... run away. Of course, you can get strategy advice once you've mapped but since most big strategy firms I've met tend to fail at getting the ten good point right ... run away. It's always way better to learn to play chess for yourself.

Now, once you've mapped a business you still have a problem ... bias. Having watched and collected maps from different companies, I've noticed a tendency of companies in similar industries to think in similar ways. This is a probably a side effect of competing against each other, people moving between companies in an industry and industry specific conferences.  Hence what is considered advanced modelling techniques in the oil and gas business is not the same as what is considered advanced modelling techniques in the high tech industry. Though I don't have enough data to categorically state this (yet), it would appear that not only do you have early adopters and laggards within industries but entire industries can be early adopters or laggards. However, within a laggard industry there will be companies that consider themselves to be early adopters because they're comparing to their competitors. A bias exists towards the industry norm.

Hence if you take mathematical modelling techniques, let us hypothesise that the rough order is high tech > media > retail > finance > pharma > oil and gas. Then not only will you have early adopters and laggards in each of those sectors but the sectors themselves will exhibit differences. Hence a company in the finance industry which considers itself a 'early adopter' might dismiss a high tech company moving into their industry but can often find themselves competing against a beast they're poorly equipped to deal with. The problem with this bias is that the delta between industry sectors may well be growing (this is part of a current research examination).

Now, putting bias aside for moment, I want to now turn to profile. If you take all the maps of a company, by simply counting frequency of components at different stages of evolution then you can generate a profile. At the moment this is a very imprecise and highly polluted technique (because of bias) but it gives us a 'flavour' to how a company views itself.

The interesting aspect of a profile, is that each section requires different management techniques and methods. It was an awareness of this that led me to the pioneer, settler and town planner structure (PST) in the first place. See figure 1.

Figure 1 - Pioneer, Settler and Town Planner

So rather than organising by 'type' of components grouped into functional departments (such as IT, Marketing, Finance & Operations), under a PST structure the company organises by 'evolution' and components flow from one group to another through a process of theft. For more details read here.

In the PST world there is no IT, Finance and Operations others than subset specialisms of PST. When implementing this structure, people appear to be attracted to different parts of the profile. I'm not going to say there are different characteristics of people but a tendency of people to be happier with certain parts of the profile. Also the cultures of each part are different - pioneers operate better in an environment which is different to town planners. Finally, each part of the profile is important for a company's current and future health.

Hence I was piqued by Lou Adler's post on there being 'only four types of jobs in the world' because in a PST world (based upon evolution) there are only three.  Oh and for reference the difference between Lou's post and the much earlier PST structure is the Pioneers are the builders, Settlers are the improvers, Town Planners are the producers and contrary to Lou's assertion, all three groups contain thinkers. I've seen more recent work (at Greenwich University) which seems to support this structure further.

However, this is not the key point. I happen to have created and experienced a PST structure and seen equivalents and whilst there isn't enough data to statistically prove it is vastly better beyond reasonable doubt, it is more inline with how things evolve and my experience tells me it is a vast improvement in terms of innovation and efficiency.

But there is a significant wow which I slipped in the above. That wow is that under structures like PST (and equivalents) then a single company requires three separate cultures to work effectively. In much the same way there is not a single size fits all management method for projects, there is not a single size fits all for culture. There maybe common elements but the culture and type of people for each stage is different. 

This is pretty much counter to everything which is written on organisational culture today. That's the big wow of mapping and if you're embarking on a mapping journey, this is where it will lead you. I know because I've been there.

Oh, and why wow? Because if the above is right, then there are far more effective organisational forms than what exists today. Companies like Amazon, Google, Facebook etc aren't the permanent titans that people make them out to be. They can be taken.

Oh, and what happened to Fotango? Well, as far I know it was a bunch of strategy consultants that persuaded the parent company the future was in 3D television and variants thereof rather then the stuff Fotango was doing in 2005 - namely 3D printing, mobile phones as camera, platform as a service, server side javascript, automation, continuous deployment, infrastructure as a service, nosql like object data stores, online visual scrapbooks ... oh, it was a depressingly long list. 

I'm not a fan of big name strategy consultancy firms. In my world they take the 'kick' out of 'kick ass'.

Pioneers, Settlers and Town Planners

I recently heard of a third organisation which has a pioneer, settler and town planner (PST) like structure rather than the usual organisation by type - IT, Finance, Marketing - or the various derivations of (Geography & Type, Business Unit & Type).

I was going to do a long rambling post on evolution, how activities and practices move from chaotic (poorly understood, uncertain, constantly changing, rare, future source of worth)  to more linear (well defined, predictable, stable, common, cost of doing business) and how organisations contain a mass of these activities and practices. Understanding this and using the right methods and tactics is important to creating a balance between the unstable but potentially high margin activities (chaotic) and the stable and low margin (linear).

This process of evolution from chaotic to linear is why "one size fits all" mentalities are so dangerous because you either impact survival today (through poor efficiency) or survival tomorrow (through future wealth creation). This creates the badly termed "innovation paradox" of Salaman and Storey.

There is however a route by which you can create a profitable but stable organisation which deals with the constant cycle of change, except unfortunately traditional organisational structures (by type) get in the way. They do so by obscuring the natural evolution (or flow) of activities from chaotic to linear which is driven by user and supply competition. Invariably the traditional structures built on type result in alignment issues and a host of other problems.

More cell based structures (e.g. Two Pizza) appear better than traditional structures at dealing with these issues but as I accidentally found out in 2004 (but couldn't explain why back then) this can be enhanced by a pioneer, settler and town planner (PST) structure which appears to solve the problem of flow enabling high rates of innovation of new activities and efficiency continuously.  These days, I can explain why this should work but with so few examples then it could just be coincidence or some other bias.

Under PST, there is no IT, Finance or Marketing departments or any grouping by type. There is only a structure defined by evolution and flow - hence pioneers, settlers and town planners.

Now, I could go through the details in a long rambling post but I've done this countless times before in presentations around the world over many, many years. So, instead I'll just add a few diagrams (pinched from various presentations) on PST which is useful for those with a basic understanding of evolution, value chains and the flow of chaotic to linear (for some background see Ten Graphs on Organizational Warfare)

Figure 1 - How things evolve.

Figure 2 - Mapping an organisation, value chain vs evolution

Figure 3 - Structure around it.

Figure 4 - An organisation based on theft.

Overall, I'm happy to hear of another example and I've also been told of a possible fourth. Alas, I'll need several hundred more operating under many years of economic competition before I can actually demonstrate the difference has significance.

The models say this is a more "right" structure than by type and if successful even in these few cases, the practice should diffuse. Time will tell and I'll be watching those companies with a great deal of interest.

20th March 2013

Updated images with higher resolution screenshots with less Neapolitan Ice Cream effect.

On Structure

Once you have built maps for an organization and used this to decide a strategy, the next question is how do we go about doing this? How do we organize ourselves?

Many of the issues that businesses suffer with, from business alignment to various forms of inertia to one size fits all to the perils of outsourcing are a consequence of how we organize ourselves. Most the time we break companies down into silos grouped around type – i.e. type of activity, practice or data. Hence we have Finance departments, IT departments and Marketing departments.

Each of these silos consist of many activities all of at different stages of evolution. It is easy for a single department to adopt a one size fits all technique that invariably creates alignment issues with other groups. “We need IT to be more efficient” will be the chant of one group whilst another declares, “We need IT to be more innovative”. The more silos of this type, the more likely that alignment issues will occur.

A more effective approach (used by the Next Generation companies) is to break the organization into cells connected by services. As show in figure 54, the cell-based approach based around grouping components in small teams resolves the problems of one-size fits all and many alignment issues.

An example of this can be found with Amazon’s two-pizza model of working in which no team is bigger than can be fed by two pizzas (12 people). Such cell-based approaches are diffusing but are still infrequent in occurrence.

Figure 54 – Cell based approach to organizational structure.

 Now, a two-pizza approach takes advantage of componentization with each group not only providing components to others but also relying on components provided by others. Because each group has unknown demands for what it produces and because the inputs may fail, each group is required to build using distributed approaches and to anticipate failure. Concepts such as degeneracy, where once component can be switched for another become important and reinforcing mechanism including the constant introduction of random failure are often used e.g. a master of disaster or in Netflix’s case a chaos monkey.

Is a cell-based approached therefore the limit of organizational design? No.

The components continue to evolve and as they do so their characteristics change. Which leads to a question. Even if an organization is broken down into small cells, are the right people involved?

In other words, do the people you need to deal with a component, such as an activity in the genesis stage the same as the people you need at the more commodity stage? Are there people who are more comfortable with a highly chaotic and uncertain environment with high rates of failure and flashes of brilliance? Are there others who are more skilled in a world that is more ordered, highly metric, highly reliable and efficient?

One way to resolve this potential dichotomy is to not attempt to do both but to simply focus on one side. For example, to focus on provision of highly efficient utility services and enable others outside the group (an ecosystem) to innovate and then exploit that innovation as it diffuses - the ILC model.

The term ecosystem refers to the collection of people, activities, practices and data which creates our environment and for which we have influence over. Each company is its own ecosystem. The provision of utility services and use of models like ILC is simply about widening our ecosystem to include others.

When we look at a company operating an ILC model with an external ecosystem that is growing faster than its physical size, we see that the company appears to be super linear for innovation (genesis), customer focus and efficiency with physical size i.e. as the company grows then it become more innovative, customer focused and efficient. The reality is the company is in effect vastly larger than its physical size i.e. it’s borders have extended beyond the company.

Within this wider ecosystem we often have a separation of concerns between the company focused on efficient provision of core services, outside companies innovating (taking the uncertain gamble in pursuit of novel and new) and the ecosystem being leveraged to identify successful diffusion. Can this three-part structure be replicated within an organization?

This is the purpose of a structural model known as Pioneers, Settlers and Town Planners where and organization is broken into these three distinct phases. To explain the model, we first need to examine another concept known as Profile & Flow.

Profile & Flow

Take your maps and count the frequency of activities, practices and data at each stage of evolution (e.g. number at a specific stage / total number at all stages). This is what creates the profile chart in figure 55.

Figure 55 – Profile of an Organization

All components are evolving (due to consumer and provider competition) from genesis to commodity. At the same time there exists genesis of the novel and new including higher order systems through componentization effects. Finally the more evolved components tend to become provided by external suppliers. The overall effect is we have a constant flow from left to right and the graph is not static.

The exact profile and rate of flow will vary by company and its value chains along with industry. Hence some industries will tend towards a more commodity focus with efficiency in provision being critical whilst others we tend towards genesis and the creation of novel and new. Within any industry there will also be companies that choose to play a certain role, so in the pharmaceutical industry you may have companies focused on generics and others focused towards novel drugs.

Getting the balance right is important for long-term stability. The more commodity components are highly predictable and when you’re a provider of these create a base line of revenue. Genesis is by nature highly uncertain and risky but also provides the highest rewards. This is also why ecosystems are powerful tools because by focusing on the base line revenue and enabling others to do the gambling for you and then leveraging the ecosystem to exploit any success (commonly called “eating the ecosystem”), you can reduce some of the uncertainty whilst gaining a higher revenue than simply focusing on commodity.

When it comes to internal organization, rather than breaking the profile into type (such as IT, Finance, Marketing) and creating many smaller profiles leading to all the issues of one-size fits all and alignment, we will instead structure by profile.

Pioneers, Settlers and Town Planners

To structure around profile and the flow of evolution in an organization, we will use a structure known as Pioneers, Settlers and Town Planners. (see Figure 56)

Figure 56 – Pioneers, Settlers and Town Planners

The Pioneers will deal with the chaotic and uncertain world of genesis (or the “innovation” of novel and new). They are our artisans, our “creative” minds. They use appropriate techniques such as agile, rapid development, minimal viable system with a focus on experimentation and trying things out. The group understands implicitly that the future value of something is inversely proportional to the certainty we have over it, gambling is a must. As there is no defined market, there are no customers to listen to only gut. Failure is accepted as a norm, rewards are built on future successes and rapid change is the “standard operating procedure”. In order to achieve the speeds necessary, use of component sub systems becomes essential. 

The Settlers cover the custom built to product stage and focus on leveraging what exists. This group steals from the Pioneers whether internal or external (in the wider ecosystem). The act of stealing (or eating the ecosystem) forces those Pioneers to get on with the act of Pioneering. The Settlers in the mean time concentrate on productisation or provision as rental services. The Settler’s focus is on listening to customers and meeting their needs, developing metrics and feedback, incremental improvement, driving a component to feature completeness, maximizing profitability and reducing cost of production. They grow ecosystems, they nurture them and they exploit them. This group is where most of the games of strategy are played e.g. do we open source a component to undermine a competitor or do we slow down evolution through a dark art (branding etc)? 

Settlers tend to use a blend of methods, part science / part art, they are more “cunning” than “creative” and are rewarded on profitability. They tend to be very good at spotting patterns (a necessary requirement for productisation of the novel and new). Similar games are played whether the component is something produced for sale or consumed by the organization. When consumed the focus is on driving down cost, driving it to more of a commodity etc.

The Town Planners cover the commodity and utility stages and focus on commoditization and building of “platforms for innovation”. This group steals from the Settlers and builds the common components that the Pioneers use. The act of stealing is essential due to inertia that Settlers will build up through past success. Hence stealing forces them to move onwards. The Town Planners are almost exclusively metric driven - it’s all about volume, efficiency, resilience, cost and performance and woe betide anyone who turns up without data. Methods are about minimizing deviation, repeatability and continuous operational improvement. Six Sigma and Kaizen rule the roost.

Don’t confuse this with a lack of “creativity”, the people you need are exceptional and able to turn your humble product into a towering beast of efficiency. When it comes to listening to customers, this group is focused on providing volume operations of exceptionally efficient good enough standard components. They know what is needed better than the customer does. They also know how the customer suffers from inertia and becomes deluded over the need for customization. They know how if left to customers then everyone would want their very own highly customized nuclear power plant for their individual needs, there would be no standards and the world would progress at a much slower pace. In my experience, they can be quite a cynical crowd.

Rewards for Town Planners should be based on operational performance, cost efficiency and reliability. As a business you want to accept this is going to be a low margin but stable area.

The balance between Pioneers, Settlers and Town Planners (PST) should vary with profile and flow. The rewards mechanism, techniques and means of operating for each group are different. Even the culture can be different.

The PST structure should be used in a cell-based structure (see Figure 57) as it requires activities, practices and data to be broken down into the different evolutionary states.

Figure 57 – PST and Cells

Whilst departmental structures are common and cell based structure are infrequent, the PST structure is exceptionally rare.  However, the point to note is that cell based structures aren’t the end of the story. There is ample room for improvement beyond the current practices of today’s Next Generation of companies.

On the future 

By now the reader should have an understanding of mapping, how the environment can be manipulated, the process and impacts of change and how organisations can be structured around this. In the next few sections I intend to cover the future and the questions of validity of the work.

However, for the time being I'm going to need to focus on some other work, so I'll have to leave this for some later date.  Hopefully, you've already found the series useful.

---

Post 24 on the Management and Strategy series.

Next post in series ...  Outside in the Distance

Previous post in series ... Attack, Defend and the Dark Arts

Beginning of the Management and Strategy series ... There must be some way out of here

Bimodal, dual operating system and bolt-ons.

I've just read this ZDNet article which describes me as holding a view that

"bimodal concept is flawed because it attempts to "bolt on innovation" rather than develop it more organically from inside the existing IT architecture irrespective of cloud services"

This is completely untrue.

When new things appear, we have historically tended to bolt on departments because our organisational structures are not designed to adapt. My current favourite example of this is the Chief Digital Officer but you could say the same about Chief Electricity Officer and other past transformations. Bolting on structures is a symptom of failure to build an adaptive structure. However, that is separate from my objection to bimodal & dual operating structures.

I'll go through my objections.

1) Practice. The concept of two extremes in organisations date backs to before 2002, and was noticeably highlighted in the Salaman & Storey innovation paradox.

”paradox is at the heart of innovation. The pressing need for survival in the short term requires efficient exploration of current competencies and requires ‘coherence, coordination and stability’; whereas exploration / innovation requires the discovery and development of new competencies and this requires the loosening and replacement of these erstwhile virtues”

Shortly after that time, I became CEO of a Canon subsidiary. I knew the single approach didn't seem to work well and so we tried a more dual structure in IT. What happened was almost warfare between the groups. The development group would create "new stuff" but the operational team wouldn't touch it because it was "flaky". It was not a happy time and after an initial promising start, things had rapidly degenerated into them vs us. Something was missing.

2) The Missing Middle. What was missing was the middle, the transitional stage between the genesis of something new and its industrialisation. To cope with that, we implemented a structure loosely based on Robert X. Cringely's 1993 book Accidental Empires which discussed the three different approaches. The terminology I use is Pioneers, Settler and Town Planners (PST). This worked and the problem had been the chasm between the groups was not only too big but by focusing on the extremes we had accidentally diminished the all important middle. I do mean all important - continuous and sustainable advantage comes from managing the middle not the ends. It seems that ignoring the process of evolution was not a good idea. Oh, and as with most of my work - yes, I've eaten my own dog food and by no means should you consider PST as the solution as no-one yet knows how to organise effectively and remain adaptive. You must accept that there is still some exploration to be done.

3) Spaghetti Junction. Whilst I had implemented the pioneer - settler - town planner structure almost a decade ago, spoken about it at many conferences, my focus in 2008 was diverted elsewhere - namely running strategy for Canonical. However, it was around that time I was asked to speak at an event where a large global company described their latest attempts to rebuild their "platform " because it was unwieldy. I was asked to have a look. The problem was simply they had built their platform with a dual structure and this inevitably leads to the never growing platform and spaghetti junction. I've written more about this here and it is something I've come across several times. It doesn't matter how good your technology is it won't fix your structure. Personally, you should focus on building a cell based structure first as per Haier or Amazon and worry about managing attitude later.

4) Ring fencing. More recently I've seen dual operating structures used as an attempt to ring fence change. In this case, you've got a very operationally run group (often with a non strategic CIO) and there is concern over the threat of this "new digital" bolt-on. The solution is seen as dual structure which is basically a way of saying "you digital lot can play with your crayons over there, don't disturb us". This is not healthy or helpful when faced with an evolving industry and just helps reinforce inertia.

5) Legacy. To compound things people having started to confuse "legacy" (which really should be called toxic IT) as being the role of one group. Not only is this dangerously misguided as to what legacy actually is and how co-evolution causes it (it can appear at different stages of evolution, more on this here) but now you are emphasising one group as the "future new" and one as the "past old". You might as well call them Eloi and Morlocks and give them axes. You're also in danger of highlighting one group as more important when in reality you need brilliant people in all. Furthermore you've buried the all important middle.

There is absolutely nothing good I can say about dual operating system structures as a universal doctrine. Not even as a transitional model. I hold a view based upon experience, practice and an understanding of the principles of evolution that such dual structures are over simplistic thinking. If you want to transition then go cell based first (e.g. Amazon's two pizza, starfish) and deal with attitude later. I'm quite convinced in this meme copying world that lots of companies will still jump on this as the solution and I suspect that some people will try to use it to prevent change to their empires. In my opinion, neither is good for the future welfare of an organisation.

I do know there are potential ways to use a dual structure but these require very high levels of situational awareness, are highly context specific and need the removal of one aspect of organisation. This is far beyond the reach of most.

So certainly organisations have historically tended to bolt-on departments for innovation but this is not new. The polar extremes in an organisation is also not new. Even organising by the extremes and the failure it causes is not new. In reality, it's so not new it's a decade old.

But that won't stop Gartner from promoting bimodal, the "new" (old) hotness and I'm mindful that if they said "The secret was to tie a yellow ribbon around the old oak tree" then some would empty Amazon of stock. They have their adoring fans. When they stuck to technology analysis, producing MQs and hypecycles (which are just aggregated opinion not some scientific measure of physical property btw) then I also generally found them harmless and occasionally useful. This new venture of theirs, I don't view in the same light.

As for Gartner's view that you have to "Go bimodal or go home", well I view this as reckless promotion. Also trying to link this particular form of structure with a technology evolution (e.g. cloud) is very questionable. Yes, organisations are needing to evolve and there is specific phenotype that is emerging that is caused by the underlying evolution of technology. I wrote about this many years ago, and for reference this is the result of that population study published to LEF members in 2011.



Now whilst the phenotype had companies gravitating towards mixed methods (rather than single) - the agile vs lean vs six sigma debate is rather past its sell by date - the structure was firmly heading towards cell based. Very rarely were companies considering attitude (as in the need for pioneers, settlers or town planners) and certainly I found no examples of companies promoting organisation by extremes and only rare mention of a concept such as "two speed IT". Hence I am highly suspicious of bimodal, I would have expected some references to organisation by extremes to have emerged even in those early days especially when the other phenotypic changes were so strong.

Caveat Emptor.

Two Speed Business? Feels more like inertia.

These days I use maps of organisations to apply a cell based structure ideally using a Pioneer, Settler, Town Planner model.  The map is based upon a value chain (describes the organisation), how things evolves (describes change) and the changing characteristics of activities, practices and data from two extremes (the uncharted to the industrialised) - see figure 1.

Figure 1 - PST.

I use these maps across many business and governments to reduce duplication, bias & risk whilst improving situational awareness, gameplay, correct use of multiple methods & communication - see figure 2.

Figure 2 - Map of a Media Company.

Key to mapping is the evolution axis i.e. you can't actually anticipate change over time in any effective manner (we don't have a crystal ball). See figure 3.

Figure 3 - Evolution

A bit of HISTORY.

My early attempts to map an environment were a disaster because I attempted to use time and time based sequences to measure change. I eventually postulated a path for how things evolved and presented this at Euro Foo 2004, EuroOSCON 2006 and many conferences in between. - see figure 4.

Figure 4 - Early Evolution [from EuroOSCON 2006].

This path is what I used to create my early maps in 2005 (though James A. Duncan tells me it was 2004). The problem was, I couldn't demonstrate the path was based upon anything other than a concept. It took until 2007, to collect the data necessary to demonstrate that the evolution path (see figure 3 above) had some merit.

In those early years, I also used to refer to how different methodologies were required e.g. figure 5.

Figure 5 - Different Methodologies [from EuroOSCON 2006]

This was based upon the innovation paradox of Storey & Salaman, Theories about the process of innovation, 2002

”paradox is at the heart of innovation. The pressing need for survival in the short term requires efficient exploration of current competencies and requires ‘coherence, coordination and stability’; whereas exploration / innovation requires the discovery and development of new competencies and this requires the loosening and replacement of these erstwhile virtues”

But it wasn't until 2007 that I could clearly demonstrate the changing characteristics of activities, practices, data and knowledge as it evolved. This I have spoken about at literally hundreds of conferences and video talks to hundreds of thousands of people around the world using various examples (e.g. figure 6 and figure 7)

Figure 6 - Characteristics of Innovation (as in a novel thing) [from Web Strategies 2008].

Figure 7 - Characteristics of the same activity as it evolves to commodity [from Web Strategies 2008].

This also helped explain why the Pioneer, Settler (or what I used to call Colonist) and Town Planner structure worked. I had introduced this structure many years earlier (2005) to replace a failing two bit mode model before it - see figure 8.

Figure 8 - PST [from Web Strategies 2008].

The Pioneer, Settler and Town Planner model is a derivative from Robert X. Cringely's model of Commandos, Infantry and Police in the 1993 book, Accidental Empires.

Of course, some of the terms have evolved over the years to make them more meaningful whilst the basics remain as is.

• I don't use Colonist anymore. I use Pioneer, Settler and Town Planner.

• I don't use innovation anymore. I use the term genesis (of a novel and new thing) because innovation is so abused to mean everything.

• I don't use chaotic anymore. I use uncharted to describe the unknown space.

• I don't use linear anymore. I use industrialised to describe the defined space.

E.g. take a look at older presentations and you'll see many of the same concepts just with different terms.

OSCON 2010

Today, what amazes me is that companies are starting to realise that one size methods don't work. I hear talk of bimodal, two speed IT and dual operating systems for a company.

Why does this amaze me? 

There are a few exceptional leading lights from very early on - Robert Strassmann and Robert Cringely come to mind - but the leading edge of companies were exploring these topics around 2002-2008.  I know, I was there helping the discussion to happen. After this, the early adopters started to appear (Silicon Valley Startups etc). Increasingly I see this work in various Governments.

However, all of a sudden in 2014 - an old model, not cognisant of how things evolve, long thought dead has raised its head. The bimodal, two speed IT, dual operating system is becoming a very popular concept within what I describe as legacy companies. We're talking ten years late to the party and getting the wrong address. 

This feels like inertia. A hope that adding lipstick to the pig will somehow keep the pig alive.

A warning

Mapping, use of a three party system, the extremes of uncharted to industrialised are not new. Despite refinement to the terms, this stuff is all nearing or over a decade old. The field has moved on since then into understanding common economic patterns, weak signal analysis and other forms of organisational learning.

By the time something of use gets written in a book or a publication, the value related to it has often been extracted long before. You can't get to the bleeding edge of competition by reading books or publications. You have to live it. Even models like pioneers, settler and town planner are starting to feel dated and being examined through lenses of a continuous spectrum and other structures.

The laggards are nowhere near getting to the spaces where the leading edge have long since moved on from. 

The gap appears to be widening.

I used to think the gap between the leading edge and laggards was five to seven years, it now seems like fifteen or possibly much more (i.e. how long it will take the laggards to catch up with where the leading edge is today). This may be a normal consequence of inertia, an acceleration in the underlying cycle of change combined with poor situational awareness - of this, I'm not sure. It needs testing.

However, within the laggards it does feel as though the copying of easy to digest memes appears to be more rampant, circulated by those who benefit from the memes to those that need an 'easy solution' in a marriage of convenience. As Rosenzweig once said

“Managers are busy people, under enormous pressure to deliver higher revenues, greater profits and ever larger returns for shareholders.They naturally search for ready-made answers, for tidy plug-and-play solutions that might give them a leg up on their rivals. And the people who write business books – consultants and business school professors and strategy gurus – are happy to oblige.”

I see an awful lot of companies plunging down paths they shouldn't with little or no situational awareness. This isn't getting better for some. There's going to be an awful lot of casualties. 

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.

To Infinity and Beyond

Chapter 17

(very rough draft)

Meeting a spaceman

I was working on the use of printed electronics within a paper book (think of an interactive book which looks like a normal book) when I got that phone call from a friend about "this guy who really wants to meet you". I was curious, so I went along to meet someone called Mark at Canonical. I didn't know what to expect. The first few minutes were certainly interesting.

Shuttleworth : "I'm Mark. I've been told you're a good UX designer."

Me : "I don't know anything about design."

... silence.

It was an awkward pause. Then Mark realising the next hour was probably a waste of his time asked me to tell him what I did know about. I talked about evolution, the changes in the industry and before long we were into graphs, maps and cloud computing. The time flew by. We kept talking. I was introduced to others and in what seemed like lightning speed, I was working at Canonical. I had one job, to bring Ubuntu into the cloud. I called my friend, asked him what had happened. Steve just responded "I knew you'd get along".  Life is full of pleasant trouble makers like Steve.

The first day I arrived for work, I was all excited and had the usual confused look of a rabbit staring at headlamps. My boss, who also happened to be another Steve, did the usual rounds of introductions. That was an interesting moment. Whilst I delighted in the warmth of the people I met, the first five responses to my role of bringing Ubuntu into the cloud were negative - it's a fad, why are we doing that etc. I knew I was going to have to build a cabal pretty quickly and create some momentum. However my first official task was to look at the virtualisation strategy that had been written. It was one of those "oh, what have I done" moments. Fortunately it didn't take long to find others with common interests - Rick Clark, Soren Hansen, Nick Barcet and many others. Steve George was one of the most supportive people I've worked for, a good friend and then there was Mark. Without Mark none of this would have happened. 

The problem to begin with was Canonical was focused on the server and desktop market. It was up against huge giants such as RedHat and Microsoft. It was making valiant, almost heroic efforts but Canonical was small. Many wanted to focus on the server OS, to generate revenue from support licenses and to a few then the Cloud was a distraction. The problem was one of focus and what I needed to do was change the mindset. To explain this issue and why it mattered I'm going to cover a number of concepts from the Three Horizons to Porter.

The Three Horizons

The three horizons was a model put forward in the Alchemy of Growth, 1999. It discussed three views that any corporation had to take.

Horizon 1 : the core business which provides the greatest profits and cash flows that need to be extended and defended.

Horizon 2 : are the emerging opportunities and businesses that will drive medium term growth. These may include new ventures that you are investing in which are expected to generate substantial future profits.

Horizon 3 : These are ventures that should ensure the company long term future.  They can include research projects or pilot programs or even investment in startups.

For Canonical, horizon one was the core support licensing revenue.  Horizon two included new concepts such as online storage, the app store and extending onto more devices. Horizon three ... well, I'm quite convinced a few would have thought that included myself. Whilst this model of three horizons is a reasonable way of examining a company, I personally find it inadequate. I often find that some confuse it with the pioneer - settler - town planner model of organisation by associating town planners with horizon one and pioneers with horizon three.  To explain the weakness with the model, I'm going to use the map of mapping that I introduced earlier. To save you scrambling back through past chapters, I've provided that map here in figure 213.

Figure 213 - The Map of Mapping.

Let us now assume that we decide to use the map of mapping to build a new business. I'm going to take a part of the above map and concentrate around the provision of forecasting (i.e. anticipation of know changes) to others. I could have quite easily built a comfortable life around the weak signals I developed for forecasting change and built myself a small boutique consultancy providing market and technological forecasts. The premise behind such a business is provided in figure 214. My purpose with such a business is to simply survive (i.e. make money), the user wants an advantage over competitors, they measure this by the return on capital invested in a space, I enable this through anticipation services based upon known climatic (economic) patterns that use maps of the industry. It would be a relatively trivial business to create had I the desire. 

Figure 214 - Forecasting Service

Horizon one would be that boutique consultancy business. I'd have been protecting (i.e. not making creative commons) the twenty odd common economic patterns that I know about which impact the environment. I'd probably use a worth based mechanism (or outcome based as it is called today) for charging. I could also extend this map to cover in more detail the social capital components of trust, the activities needed to perform the analysis and run the company. Remember you can make all forms of capital whether data, practice, activity, knowledge or social. Let us hypothesise that I had done this and by hook or by crook turned it into a small success. What would my horizon two be?

In this case, the diffusion of knowledge and evolution caused by supply and demand competition would drive many of those components to a more industrialised space. At some point, I'd have to prepare for my boutique consultancy entering a world where products did the same thing. I would know in advance that we'd have inertia to that, any shift from one stage of evolution to another (e.g. custom to product) has inertia caused by past success. It's one of the those climatic patterns. I've mapped this in figure 215.

Figure 215 - Horizon two

But, with foresight - and I'd hope that I'd be using mapping on myself - then it would be relatively trivial to anticipate and overcome the inertia. How about horizon three? In this case, we get a divergence. I could for example focus on further industrialisation to a more utility service exposed through some form of API - Anticipation as a Service or AaaS for short. Of course, such as change along with mirth over the name would come with significant inertia created by any existing product based business model. Alternatively, I could expand into something new such as the use of doctrine for competitor analysis or the arms sale of context specific gameplay or even some novel, uncharted, higher order system that I haven't even considered. I've shown these divergent horizon threes in figure 216.

Figure 216 - Horizon three

Now let us add the pioneer - settler - town planner model onto the horizon three map (see figure 217). Remember each team has different attitudes (which is what pioneer, settlers and town planners represent) and each not only build but operate their own work. The important thing to note is that horizon three consists of town planners or settlers or pioneers or all of the depending upon what I choose to do.

Figure 217 - PST added to horizon three.

The first thing to note are the horizons are context specific. You cannot simply overlay them onto a PST model or even the concept of evolution (e.g. by saying that genesis is horizon three) as it depends upon where you are and the landscape surrounding you. The second thing to note is that the horizons can often be broadly anticipatable. This is the thing I find inadequate with the horizon model because without a map and the learning of common economic (aka climatic) patterns then it becomes all too easy to miss the obvious. It is why I find the three horizons useful as a high level concept but overall weak in practice on its own. It also fails to help me adequately deal with inertia or legacy.

The issue of legacy

In chapter 9, we examined the climatic patterns of co-evolution i.e. practices can co-evolve with the evolution of an activity. There is usually some form of inertia to a changing activity and this can be compounded by a co-evolution of practice. In figure 218, I've taken the original diagram from chapter and added some inertia points for the shift from product to utility for both compute and also platform.

Figure 218 - Change of Compute and Platform

As previously discussed, there are many forms that inertia can take. However, the question I want us to consider is what represents legacy in this map.  The two obvious areas are those trapped behind inertia barriers e.g. compute as a product and platform as a product (i.e. platform stacks). The next obvious include the related practices i.e. best architectural practice associated with compute as a product. What is not so obvious to begin with is the issue that as components evolve enabling higher order systems to appear then the lower order systems become less visible and for most of us legacy. The departments that ran switchboards in most companies were once a highly important and often visible aspect of communication. For many companies, that activity has been consumed into either reception or call centres in much the same way that email has consumed the postal room. We still send letter to each other (more than ever before) but they are digital. In this case, the role of the components underneath the platform layer are going to become less visible. Dealing with and managing infrastructure will become as legacy to most companies as the switchboard is today.

Hence another area of legacy would be the practices and activities below the platform layer which includes concepts such as DevOps. In 2017, such a statement tends to receive a strong negative reaction. Most react with the same forms of inertia as those who reacted against cloud in 2006. Many will claim DevOps is more than infrastructure as it's about development and culture. Depending upon how far in the future you're reading this from, you'll probably be quite surprised by this and even more likely have never heard of DevOps. As with all such things, DevOps was a child and reaction against the prevailing methods of management. It co-opted concepts from earlier school of thought (e.g. ITIL) including iterative approaches, use of components, configuration management, services approach, a focus on users and measurement whilst simultaneously distancing itself from them. It added its own dogma and sort to create a separate tribe. The same will happen in platform, a new school of thought will emerge that will copy and build upon DevOps but deny it has any relationship to it. DevOps will become "what my mum and dad does" as the rebellious child declares its independence and denies any association to the former.  If you think of concepts as genes, then many of the genes of DevOps will be found in the new generation (though they will rarely admit it, painting DevOps as some strawman version of itself), some of the genes will become redundant and others will emerge. 

I've marked on the main area of legacy onto our map in figure 219.  To do this, I've used the concepts of inertia and how industrialised components enable not only higher order systems but become less visible themselves. I've also added on a typical PST structure. As we can see, many of the legacy areas exist within the settlers and the town planning teams. 

Figure 219 - adding legacy (a consumer perspective)

Obviously there is a perspective to be considered here. I'm looking from the point of view of someone who consumes compute. If I'm a major provider, whether platform in the future or utility compute today then much of this is definitely not legacy any more than power generation systems are to electricity providers. From the perspective of a major provider then legacy would look more like figure 220 i.e. it will consist of activities (and related practices) that are stuck behind inertia barriers but not the impact of lower order systems becoming less visible. What becomes increasingly invisible to others (i.e. consumers) is still very visible to providers.

Figure 220 - legacy from a provider perspective.

There is an unfortunate tendency of people to associate the town planning groups with legacy. As should be clear from above, then that's not the case. The recent future of computing has been industrialisation by town planners to utility services. The legacy has been past product models, a realm of settlers.  If we take the consumer perspective from figure 219, then the future is a mix settlers building application, pioneers discovering emerging practices that combine finance and development (whilst denying any inheritance from DevOps) and town planners busily create the empires of scale around platform utility services. I've shown this future in figure 221 and it's where companies should be investing in 2017.

Figure 221 - the future, from a consumer perspective

It's important to note that legacy can be anywhere. It can be caused by a custom built activity which has failed to evolve or a product based business in a utility world. Legacy is simply a consequence of a failure to evolve and it is not associated with one group such as pioneers, settlers or town planners but instead all.  When it comes to managing legacy then it's really important to understand those points of change and the impact of co-evolution. This should become second nature to you and it's worth practicing. There's another perspective beyond the three horizons, beyond inertia and legacy that we also need to discuss. It's the perspective of Porter's forces.

On Porter

For those unfamiliar with Porter's five forces, these are rivalry within the industry, threats of new entrants, threats of substitution and the bargaining power of suppliers vs consumers. In this section we're going to examine these five forces through the lens of the peace, war and wonder cycle (see chapter 9).

In the time of wonder, it is a battle to become established. The field is not yet developed and there are no "new entrants" as there are no established figures. Everything is new, uncertain and uncharted. The consumers hold the power and it is they who decide whether this industry will succeed or not.

In the time of peace, there is a constant tug of war between supplier and consumer power over the products produced. The developing giants are normally well protected from new entrants in a game of relative competition, except against the occasional threat of substitution. It is this substitution by a different product which is the dominant factor.

In the time of war, new entrants providing a more industrialised form of the act threaten the existing giants that are stuck behind inertia barriers. It becomes a fight for survival for these giants and they are often poorly equipped. It is not a case of a product becoming substituted by another product but instead an entire industry is being changed to more industrialised forms.  It is often assumed that the shift towards utility provision means centralisation but this is not the case. 

Whilst the interaction of all consumers (demand competition) and all suppliers (supply competition) drives the process of evolution, the question of whether a specific activity or data set centralises or decentralises depends upon the actions of individual actors (suppliers and consumers) in this market.  For example, it would have been relatively trivial for the hardware manufacturers to create Amazon clones and a price war in the IaaS space around 2008-2010 in order to fragment the market by increasing demand beyond the capability of one vendor to supply due to the constraint of building data centres. I had these exact conversations with Dell, IBM and HP throughout 2008 and 2009. I even told them their own inertia would fight against this necessary change and they would deny the existence of the punctuated equilibrium until it was too late. The fact they didn't act and lost their own industry is entirely the fault of their own executives and also one of the major factors why have seen  centralisation in the IaaS space. Centralisation depends upon the actions of specific actors (in this case the inaction of hardware suppliers and hosting companies). In the future, this may in fact yo-yo from centralised to decentralised or find a balance between the two (as with electricity provision and self generation). Of course this is a change in the means of production and the interfaces themselves are unlikely to change i.e. a shift from central to self-generation does not mean a change in voltage / frequency for domestic power provision.

The point to remember is the balance between these forces tends to change as anything evolves. It also isn’t static within a stage of evolution. For example, when an activity becomes more of a commodity or provided as a utility we will often experience a yo-yo between centralisation and decentralisation (with a corresponding yo-yo between Supplier and Consumer bargaining power). However as a general guide, I provided in figure 222 the most dominant forces you're likely to encounter.

Figure 222 - Porter's forces and evolution

Examining Canonical

With a basic understanding of horizons, Porter's forces and legacy, we can now examine the business of Canonical. The horizon one (core business) was related to selling support on the server OS (operating system). However, compute was evolving to more utility provision, Hence, with the exception of large cloud providers then the server OS support was likely to become a legacy business. Instead, we'd needed to focus on horizon two and the commercial use of guest OS on top of these large virtualised computing environments. We understood that companies would have inertia to these changes and being a shift from product to more industrialised forms it was likely to be a punctuated equilibrium (period of rapid change). We also understood that the biggest threats into this space would be new entrants and given the state of strategic play in many companies then we were likely to see centralisation. I've drawn these concepts onto the map in figure 222.

Figure 223 - the changing market

We also understood that co-evolved practices would emerge, that Jevon's paradox meant we were unlikely to see significant savings in IT but instead increased development activity and that a further horizon, the shift of platform from product to utility was possible. I've marked up these horizons onto figure 224.

Figure 224 - the horizons.

In terms of play, we understood that moving fast and land grabbing the guest OS was essential. To help in this, we also needed to support those developing applications or building tooling around those co-evolved spaces. If we found examples of platforms plays in this space we needed to be invested in this. We also understood that many potential customers would have inertia hence we'd have to provide some forms of transitional / private cloud offer. We also knew our competitors had inertia. As soon as I discovered Red Hat salespeople were rewarded bonuses based upon satellite subscriptions (used for security updates) then I quickly set about promoting a message that security should be "free" in the cloud.  There's nothing like threatening someone's bonus to get them to turn against and spread fear, uncertainty and doubt around a change. Our focus was clear within my cabal. Mark did an amazing job of making the focus on cloud the focus of the entire company. Rick and others set about putting in engineering effort to make it happen. Steve gave me all the firepower and cover I needed. For my part, I mainly focused on promoting Ubuntu's cloud message, being involved in the community, highlighting targets to bring on board and trying to stop people rebuilding or getting in the way of things that the community was doing. An outline of the play is provided in figure 225 and the result in figure 226. Within eighteen months, Ubuntu went from a small part of the operating system to dominating the cloud guest OS. My part was a minor but instrumental role and I have to applaud the marvellous teams at Canonical and within the community for making it happen. A small company of three hundred took on the might of two giant hordes but unlike the Spartans, this time we won. My proudest moment came from hearing a CIO talk about how "the future was all RedHat and then suddenly it was all Ubuntu". I played a small part in that.

Figure 225 - our focus

Figure 226 - the results

I often hear people talk about Canonical was lucky, well there's always some element of luck but the moves were deliberate. Obviously, people can just say the timing was lucky but they'd be wrong on that as well. I had a helping hand with timing thanks to Gartner. They probably don't even realise but I think it's worth explaining.

On the question of timing

I'm not a big fan of Gartner but figure 227 is one of the most useful graphs they've ever produced. It's a hype cycle of emerging technologies created in 2008.  It uses the earlier y-axis of visibility which later on became expectations. How does the axis change whilst the graph remain the same? Ah, that's the beauty of it but first, a bit more background.

Figure 227 - Gartner emerging technologies, 2008

During my time in the wilderness prior to Canonical, I had been looking at various ways of measuring impacts from evolution. One of the issues with this is when we look at opportunity then the evolution of any single act creates different waves of opportunity. One of these waves is focused on differential value (i.e. it's something you have but I don't) and the second wave is around operational value (i.e. we both provide this but you do so more efficiently). Both the waves appear to have a learning element and then a sharp decline as the change diffuses and evolves further. I've provided examples of these waves in figure 228.

Figure 228 - An example of different waves of value.

Of course, opportunity is only part of the equation. There's also the cost involved, particularly in development of something novel. There's also risk as the uncharted space is by its very nature uncertain. However, I developed a generalised benefit curve which for differential value is shown in figure 229. An almost identical benefit curve exists for operational value but that occurs much later in evolution and is related to co-evolved practices that emerge.

Figure 229 - A benefit curve for differential value

From the benefit curve, the early stages of genesis are all about investment. As it evolves, the cost of production reduces and we start to realise some of the benefit. We're still in the custom build stage, others are starting to copy but in general the cost of production is reducing fast enough to overcome any differential loss due to copying. Alas, at some point the cost of production is low enough and the activity defined enough that someone produces a product. On the upside the cost to implement is plummeting but alas, the differential value is declining faster as more companies do actually implement. The models I developed all had variations of this shape, so think of it more as a mental model.

What I then became fascinated by - I like to explore - was timing issues. Let us say we've recently read a whitepaper on a marvellous new activity. That activity is described as having some benefit but it also involves cost. By the time I get around to implementing the activity it may well have evolved. It might provide a different benefit to what I was expecting i.e. it costs less because it's a product but there's little differential value as everyone else is doing this. I've superimposed the evolution of an act onto the benefit curve in figure 230 to highlight this point.

Figure 230 - Changing benefit with evolution and implementation

I then modelled this delta between what I was expecting to get and what I got over time. The model I used made lots of horrible assumptions and it's about as solid as a tower of jelly.  At some point in the future, I might go and revisit this but I don't normally mention this little side journey in mapping. However, there was one remarkable thing about the delta expectation curve over time - it somewhat resembles a Gartner hype cycle - see figure 231.

Figure 231 - delta expectation over time (the expectation curve).

We have the same peak of inflated expectation, the same trough of delusion. My first reaction was horror. The evolution curve on which mapping is built uses ubiquity versus certainty. If I can model from Gartner's hype cycle to evolution then I can take the points on a hype cycle and measure precisely where something is on the certainty axis of evolution. For things that are uncertain then this should be impossible. My first reaction was Gartner's hype cycle proved evolution was wrong. I was a bit glum at that point especially since I had found mapping so useful. Fortunately, I met with a friend who pointed to a hole in my argument. I was assuming that Gartner's hype cycle was based upon a measurement of some physical property. If it wasn't, if it was just aggregated opinion (of consultants, analysts or industry) then there's no measurement of the uncertain as it's just opinion. This turns out to be the case, the hype cycle is just opinion. For interest, Gartner now uses expectation on that y-axis.

Along with being quietly relieved that I hadn't yet disproved what I was finding useful, it also opened up a new opportunity. I have two benefit curves - one for differential value and one for operational value. They both shared a common expectation versus time pattern. For example, if I look at an evolving component then where it appears in the early stages on the expectation curve for differential value can be the same place it appears on the expectation curve for operational value when it's more evolved. See figure 232

Figure 232 - Evolution of an act on differential and operational expectation curves.

Now, I already have a weak signal using publication types that could identify when things are likely to start to industrialise and enter a war (see chapter 9). I've reprinted the last analysis on this that I undertook in 2014 in figure 233. What I'd like you to notice is that the shift from product to utility for infrastructure was well into a war in 2014. Whereas the war for 3d printing and the use of commoditised 3d printers is some way off.

Figure 233 - When is the war likely

Now, in 2008, I already knew (from my weak signals) that we were entering the war phase for computing infrastructure whereas 3d printing had a long time to go before it started to industrialise. I also suspected that both a relatively novel activity (e.g. 3d printing) and an industrialising activity (cloud) could appear at the same place on two different expectation curves - one for differential value and one for operational value (figure 232 above). So, let us look at that Gartner hype cycle again and highlight two components - cloud computing and 3d printing.

Figure 233 - Cloud computing and 3D printing.

They both appeared at roughly the same place. This told me something which I've subsequently found quite useful. The Gartner hype cycle doesn't distinguish between differential and operational value as both are on the same curve. So, why does that matter? Well, in the case of cloud computing, which was the industrialisation of computing and all about operational value then you'd want to be going all in during 2008. Being in the early stage of this expectation curve just reinforces the point that people are learning about a change which you absolutely want to be a first mover to. The last thing you'd want to do is wait until it reach the plateau of productivity by which time the war would be well and truly over. If you're a vendor, this would be curtains. Gartner even calls out that this is moving fast with its time to mainstream adoption for cloud (light blue circle).

However, in the case of 3D printing then you do want to wait or be a fast follower. It has a long long way to go before it industrialises and you've got an entire product stage it has to evolve through. In fact 3D printing will reach the plateau of productivity and see relatively widespread adoption as a product long before it industrialises. At some future time, as it starts to industrialise then it'll probably reappear in the technology trigger (usually under a slightly different meme). When it comes to 3D printing then you could wait a bit and get involved in the product space or wait much longer until the "war" is upon that industry at which point you'd need to go all in.  Two points - cloud computing and 3D printing - on almost exactly the same point of the hype cycle required radically different approaches to investment and strategy. One was "all in", the other was "wait and see".

Being aggregated opinion, I do find the hype cycle quite useful as long as I separate out what stage of evolution something is in first.  I often talk to CIOs who tell me they invest when something is in the stage of enlightenment. That's a guaranteed way of losing every major technological war in business.  For me in 2008, this hype cycle helped reinforce the message that we had to go all in, it was a land grab for this territory. I also took comfort that many of my competitors probably read exactly the same hype cycle and thought they had time. Thank you Gartner, you have no idea how much you've helped me take out companies over the years. Better luck next time IBM, HP, Dell, RedHat ... assuming they survive what is to come. Anyway, the gameplay above was 2008 to early 2010. It's also worth looking at another part of my journey at this time into Government but that I'll leave for the next chapter.