Tuesday, January 17, 2017

By the pricking of my thumbs

Chapter 13

[draft, more upto date version kept on medium]

It maybe unlucky for some but I'm going to start this chapter by announcing that I'm not going to give you an answer to the scenario - yet. Instead, I'm going to give you some analysis just in case you're needing a bit of help. If you're some wizard that has already worked through the scenario, determined the right strategy and have a solution then that's fine, you can skip unlucky 13 and head straight into the next chapter. This is more for the rest of us mere mortals, who like me, have found themselves totally lost when faced with problems such as the scenario. I'm not going to use any additional information other than that already provided - in other words, there's no mystery character inserted in the last paragraph that committed the crime, see all those loathsome detective novels that make you go "where did that come from?"

I'm also going to explain this analysis in quite some detail. I apologise in advance if this is tedious but I've spent a lifetime reading mathematics texts which go - "it is therefore obvious that" - only to continuously discover that it's not obvious to me. I am going to start by creating a map of the environment and use it with some of those basic climatic patterns. I'm also going to add in a bit about market position, that'll become clear as we go through. Remember maps are just a communication tool and so feel free to annotate and adapt them as you need. 

From this basic map, we're going to examine the state of the company and its proposed strategy. We're finally going to use time-turner magic (for all you Harry Potter fans out there) to wind the clock back in time and give you a chance to choose your order again and decide once more what you want  to say to the executive board.

A map of the scenario

To start with, we need to create a basic map. The company unfortunately doesn't talk a great deal about user needs but we can infer that the user need is either about saving money or being green (possibly even a legal requirement). This need requires some form of efficiency analysis which is provided by the company as a product - Phoenix.  We also know the market whilst reasonably sized (£301 million) is seen to be far smaller than the applicable market (£3 billion) and so the market of clients is not yet fully mature. Hence to begin with, I'm just going to add client which needs efficiency analysis to our map and position the pieces roughly where I think they should be (see figure 167).

Figure 167 - starting the map

I also know that Phoenix requires some form of sensor and this sensor seems to be a highly expensive product. The clue that this isn't some form of resource constraint is that a more commodity version is provided in China. I also know that the sensor (or at least the system using the sensor) requires some form of custom built data set which our own in-house IT team creates. I'm not quite sure how this operates but for the time being I'll attach this as a need for the sensor.  

Finally, I'm aware that Phoenix has some form of system logic based upon best practice use of the sensors. I know that changing the sensor to multiple commodity sensors would "require a complete rewrite of Phoenix" (the CDO told us this). So, I can now extend my map with these components (figure 168). It's not perfect, no map ever is. I've marked on the sensor logic as a practice (i.e. it seems to be connected with how we use sensors) and the environmental data as data.

Figure 168 - extending the map with practice and data

The head of marketing also told us that the US was a more mature market and Brazil was less developed in the area of such efficiency analysis software. I'll assume that the markets are competitive (i.e. there is supply and demand competition) particularly since we're talking about setting up a business in Brazil. It's a bit of a gamble but I'll assume that the head of marketing has done at least a small modicum of homework. We can now mark on these markets, with lines (red dotted) to describe how they are changing - see figure 169.

Figure 169 - adding markets

We also know that a range of "more commodity like sensors" have been launched in China and that there is now a "data set available on the market" which I'll assume is some form of product or rental arrangement. Obviously there's a couple of assumptions here but these could be clarified with a few questions. I've marked on these changes to the map in figure 170.

Figure 170 - Adding China and the data set

Now, whilst it might not be a perfect map, it does provide us some form of overview on the environment and certainly something we can use to challenge the assumptions I've made. There is however a bit more to add. 

We can infer from the comments on the US competitor, the company's plans for Phoenix's own cloud solution to represent a mere 10% of revenue by 2023, their pride at the "technological marvel they have created"  and the statement that "security concerns cited by some clients due to their cloud approach" that this group will have some inertia to the cloud change. We also know more explicitly that with the commodity sensors being described as "not good enough for the the job" and an alternative path of using "lots of the cheaper sensors" being widely dismissed despite the cost of the sensors, the price differential and customer concerns over cost that we will find resistance to change here as well. We should add this inertia to our map (figure 171).

Figure 171 - Adding inertia.

In our market, we have a US player that is also operating in the more mature US market. They are already providing features we do not (we will assume this mets some user need which we might possibly not be aware of), they have companies building novel components and potentially products on top of their API and the system they are offering is more of a utility. 

It's still based however on the expensive sensors and we can assume they have developed their own system logic which is equivalent to ours.  I've added this into figure 172.

Figure 172 - the US player

The shift towards more utility versions requires four factors - concept, technology, suitability and attitude (see chapter 11 - charting the future). In this case concept, suitability and technology clearly exist as we have a US competitor providing the service. In terms of attitude then it's a question of whether your clients are dissatisfied with the current method of provision. It's not the 90% of customers rating Phoenix as good to high levels of satisfaction that concern me, it's the 10% who didn't. Specifically, the concern of a "high cost of the system in the market as was noted in the customer survey". I'm going to assume therefore that we are firmly on the path towards utility as the factors seem to be there and a player is already making that move.

The US player claims to be "doubling in size each year" and the anticipated revenue growth from £15M to £25M is somewhat supportive of this especially if we consider the potential for economies of scale and price cuts. Alas, we have no information to confirm that consideration. We should note that they have a “fairly active development community" growing around their API and have been accused of "eating up the business models of some of those product companies". Contrary to this being a desperate act of cannibalisation, it is more likely part of an ILC like gameplay (as described in chapter 5 - the decision to act). 

This is exceedingly dangerous as the larger that ecosystem grows then the more innovative, more efficient and more customer focused the competitor becomes. They are already ahead of us in both utility forms, provision of an API and core features. Let us add this bit of gloom and doom to our map.

Figure 173 - Ecosystem moves of the US player

In the "P&L" provided by the CFO we have revenue forecasts all the way to 2021, a very wishful bit of thinking.  We know the shift from product to utility tends to demonstrate a punctuated equilibrium and so it's not unreasonable to assume the growth rate of the US player will continue. Added on top of that an ILC model then this growth rate is likely to be reinforced because the US player will extend further ahead of Phoenix. Hence we can add our predicted revenue and extrapolate the US revenue onto the same graph - see figure 174.

Figure 174 - revenue forecasts

There are a couple of comments worth noting. First (point 1) is that by 2020 or thereabout the US player will be about the same size of revenue as Phoenix. The problem is the US player will be an entirely cloud based service with a large ecosystem that they are using to sense future changes. Our Phoenix cloud service would have just launched and we will be a startup, a minnow after spending £45 million in a future market that is dominated by this US giant. Even by 2023 our cloud revenue is only expected to be 10% of our overall revenue. This is calamitous.

To compound this the current market is only just north of £300M (point 2) and by 2020 then the combined revenues of Phoenix and the US player will vastly exceed this. Even given growth of the current market, we can assume we're going to be head to head in a battle with the US player.  One of us is not going to get what we're hoping for. Unfortunately, we will be playing the part of David with our trusty sling versus a Goliath who has turned up with an entire army of brothers armed with general purpose machine guns. This is not going to be pretty for us. Alas it gets worse.

In chapter 9 - charting the future - we discussed the concept of co-evolution of practice with activity. Looking at our map, we can apply the same pattern to sensors. The commodity sensors available in China are likely to trigger an entire new set of practices. Our CIO hinted at this with the statement “a potential solution could be to use lots of the cheaper sensors” which our CDO dismissed with the normal inertia of one wedded to a past practice - "require a complete rewrite of Phoenix". Whether we like it or not, a new emerging practice is coming and our existing system logic needs the rewrite (see figure 175). 

Figure 175 - Co-evolution of practice with activity

What this means is not only do we have a future battle with a Goliath but the entire system logic of Phoenix and our code based that is built upon years of good to best practice with these highly expensive sensors is about to become legacy. I've summarised this all in the map below (figure 176) and we will use this to examine the company strategy. 

Now, you might argue with the position of pieces ob the map or components that have been missed or assumptions that have been made but that's the entire point of a map. To expose all of this in a visual form that we can then challenge.

Figure 176 - The Map

Examining the strategy

With our map in hand, let us now look at the strategy of the company. I've marked on each point which relates to the strategy in figure 177 and we will go through each in turn.

Figure 177 - The Strategy

Point 1 : Creation of a digital “cloud based” service for provision of the software.
By the time our cloud service hits the market in 2020, we're likely to be a minnow against a giant with a well developed ecosystem model. If they're running an ILC model which seems possible then they will be out innovating us, more efficient, more customer focused and larger. They will be far ahead of us and our cloud effort doesn't even mention building an API or running any form of ecosystem game. To cap it all off, we're even bringing an old licensing model with us and a system logic that is likely to become legacy and replaced by co-evolved practice. In terms of getting it wrong, this is a fabulous way of wasting £45 million.

Point 2 : Investigating the use of the data conversion product that is available in order to improve efficiencies and reduce cost.
A fairly sensible proposal on cost efficiency but not one that should be high up the priority list in such a battle. 

Point 3 : Expansion of existing product into overseas markets such as Brazil.
It might create some short term gain but this is also a dangerous path. Our business model in a more mature market is going to be chewed up but rather than face this, we're going to take our model and attempt to re-apply it to a less mature or emerging market. All that will happen is our competitor will chew up both markets and we are simply spending money laying the groundwork for them to attack the emerging market. It would probably be more favourable to our shareholders to give half the money to the competitor for marketing in Brazil and return half the money to the shareholders than to build up future liability. This isn't as bad as the cloud effort but this will increase inertia to change due to the belief that the short term gain translates to our past model still being successful.

Point 4 : Increasing the development effort on our existing product line including more advanced reporting and other innovative features.
There is always value in focusing on user needs but in this case we're not addressing the problem of our competitor but patching over it in the very short term. Unfortunately for us, if the competitor is using an ILC model then we are in competition with the entire ecosystem that has built upon the competitor's API. If for example that includes 200 software companies then our poor product development team is going up against the might of 200 software teams. This situation only gets worse as the ecosystem grows. This is a path of spending money and still losing by ever increasing margins.

Point 5 : Undertake a significant marketing campaign to promote our solution in the existing market
It doesn't fix any of the problems but at least it might gives us a short term revenue boost.

If you want to mess up strategy then the CEO has done a glorious job. Fortunately there's also some opportunities to be considered. Firstly, the market in Brazil is an opportunity but re-using our old business model might not be the wisest idea. 

Secondly, there was an interest in acquisition of this company. Just because you know it's a future train wreck, this doesn't mean others do (remember most don't map). As someone who has done a bit of work in M&A then coming face to face with a company hurtling towards a cliff edge whilst there is "positive noise about the subsidiary from analysts and also some interest by third parties in potential acquisition" is surprisingly common and lucrative. You are a board member for the conglomerate and should look to maximise the opportunity. 

Thirdly, the system logic is heading towards legacy and we will have our own DevOps moment with an emerging practice. Fortunately, we're not the only ones facing this as the US company has the same problem. Maybe they're not as smart as we think? Maybe they're working on a solution? We don't know but this is a potential weakness. 

Lastly, there's a final opportunity in the data set. Yes, a product is now available but that doesn't mean we can't try and out commoditise this and turn data into some form of utility with an open data play (point 1, figure 178).

Figure 178 - Turning data into a utility.

The strategy outlined by the subsidiary needs some serious work on it. However, before jumping the gun let us take a look at the company again. The strategy might be bad but the question is whether the company is recoverable in the time frame?

Examining doctrine

When I want to get a sense of company and its ability to adapt, to cope with the unexpected, to learn and to be resilient to competition itself then I start looking at the universal principles it applies. I'm not looking for resilience to known scenarios but our ability to adapt to the unknown and to cope with the flow of evolution.  In this case the CEO talks about the values of the company which include "responsibility, integrity, transparency, compassion, empathy, adaptiveness and decisiveness."

These values seem all perfectly reasonable, however there are two things to consider. Firstly, companies are often very good at saying one thing and then doing something else. Secondly, executives and consultants are often very good at coming up with simple "truths" that have no data behind them. I can only judge this in terms of what I have evidence for, hence the Wardley Doctrine in chapter 11 - the smorgasbord of the slightly useful.  

For example, let us take empathy. It seems like it should matter, but does it? Is it a universal principle? What evidence do I have that it works in all cases and isn't context specific? Maybe empathy matters more in a care home than on a factory line? I don't know and so I can't judge on this. However, there's lots of things I was told in the scenario which I can comment on. I've highlighted the areas of doctrine in figure 179 using a green (for that warm fuzzy feeling), amber (for concern) and red (potential for setting off alarm bells) motif.

Figure 179 - Doctrine

My areas of concern are :-

Design for constant evolution
When someone talks about how the "organisation was recently restructured" then this is a signal to me that the organisation didn't cope with constant evolution. They may have reformed to a structure which now does but I see no evidence one way or the other.

Think small (as in teams)
Given the above, the discussion on how the "digital group will expand significantly over the next two years" raises an eyebrow. I'd want to know more, are we talking about a hefty department or some cell based way of operating (e.g. two pizza).

A bias towards the new (be curious, take appropriate risks)
The discussion about the sensors and how "it’s worth keeping an eye on the market" raises another eyebrow. I'd expect to see more directed action towards this change. I'm somewhat comforted by the use of the data set.

Listen to your ecosystems (acts as future sensing engines)
When your customers are concerned about the "high cost of the system in the market as was noted in the customer survey" then a response of "renewal price will be frozen for the next two years" is not encouraging.

Strategy is iterative not linear (fast reactive cycles)
There is nothing iterative about the strategy proposed. This might just be a reflection of the way it is presented but it's worth a question.

Strategy is complex (there will be uncertainty)
There is no concept of uncertainty presented. It's more a set of action statements and a plan which goes far into the future. 

Be humble (listen, be selfless, have fortitude)
From "being instrumental to the company’s success" to the quote "some people just have not found adjusting to this new world that easy" to the observation that the company is "clearly proud of its accomplishments, the technological marvel they have created and their ability to deliver against their vision" then there's a touch of entitlement and maybe a bit of arrogance to them.

My areas of concern pale into insignificance compared to the areas which might have me running out the door screaming, setting the klaxon off. These include :-

Focus on high situational awareness (understand what is being considered)
I see no evidence of this and a simple mapping of the environment has raised concerns that are not even discussed. I'd want to see clear evidence the company actually understands its environment.

Use a common language (necessary for collaboration)
I see an abundance of different graphics but no consistent mechanism of discussion other than verbal stories often laced with terminology. I'd want to understand how we actually communicate.

Challenge assumptions (speak up and question)
An extremely valid challenge over sensors was given by the CIO but dismissed and even described as being "discussed several times before". The palpable sense of "frustration with the group and the CIO on this topic" indicates a team that is not listening. The answers given to the challenge are all symbols of inertia - pre-existing practice, assets etc. I'd be digging here.

Focus on user needs
The lack of description of user needs is significant. Statements like "The attrition rate has been high in recent years at 9% but the Sales team believes this is due to a lack of new features and a high cost of software license renewal" are all very well and good but I'm not interested in what the Sales team thinks, I'd want to know what the user needs and wants.

Think fast, inexpensive, restrained and elegant (FIRE, formerly FIST)
A £45 million investment on a cloud effort over two years is not what I'd be expecting from a company following FIRE principles. This may be a simple consequence of summarisation to an executive level but I'd want to see evidence that we're not embarking on building some Death Star.

Manage inertia (e.g. existing practice, political capital, previous investment)
Whilst inertia appears to be clear, the only challenge to it (e.g. sensors) is knocked back. In fact the CEO got in on the act talking about intellectual property. I'd want to ask a few more questions here.

Use a systematic mechanism of learning (a bias towards data)
I see no evidence of this and of past lessons being applied. There's no concept of climatic patterns or learning. I'd want to explore this more.

Exploit the landscape
I see no evidence of understanding let alone exploiting the landscape. It might exist in mental models and some form of intrinsic common understanding but I'm not overwhelmed by this.

By the pricking of my thumbs
In my analysis, the strategy is barking up the wrong tree and I have significant concerns over the company itself.  I would not be confident that this company is either heading in the right direction or capable of adapting to the uncertain future. The only person I have some confidence in is the CIO that the company is so desperately trying to get rid off. But that's me. Your analysis maybe different. You may have seen something I have not. So let us take this unlucky chapter 13, invoke some dark magic and do the time warp again.

You have a call in forty-five minutes with the executive board. That’s how long you have to make your choices. The clock is ticking. So find a stopwatch and start it.

Your first task is to determine whether the company is heading in the right direction. You should determine whether you agree with the priority order given in figure 180. If not, write down what your priority order would be. If you decide to invoke “other” then scribble down what that other is.

Figure 180 - Priority order

Once you’ve decided your priority order then your next task is to determine what you’re going to say to the executive board.


Next Chapter in Series [to be published soon]
GitBook link [to be published soon]
More on mapping from the Leading Edge Forum.
First in series.

This post is provided as Creative commons Attribution-ShareAlike 4.0 International by the original author, Simon Wardley, a researcher for the Leading Edge Forum.

Monday, January 16, 2017

The Scenario

Chapter 12
Who are you?
You are :-
  • a member of the executive board of a huge conglomerate focused on facilities management.
  • attending a meeting of one your wholly owned subsidiary companies with their executives.
  • on a fact finding mission, trying to determine what the future of this subsidiary is. 

There has been some recent positive noise about the subsidiary from analysts and also some interest by third parties in potential acquisition. This company offers a single product which is a software system that monitors a data centre's consumption of power in order to determine whether it is being used effectively. The product is known as Phoenix.

The Company
The CEO introduces the company and their vision to provide customers with the best tool in the market for reducing power consumption and improving environmental performance. The CEO talks about their mission to "help reduce IT's impact on the planet" and there is noticeably a great sense of pride and self belief within the group. The CEO reiterates their core values in a presentation. The values are described as being instrumental to the company's success and they include responsibility, integrity, transparency, compassion, empathy, adaptiveness and decisiveness. The CEO then provides some background information, more for your benefit than anyone else's.

What is Phoenix
The system involves a proprietary software package which performs analytics across data gathered from a sensor that is installed within a customer's data centre.  The sensor is a highly expensive piece of kit that is manufactured by third parties. The sensor monitors both the electricity input, the temperature and airflow within the building.

The analytics software is based upon a decade of best practice experience for the use of these sensors. The algorithms contained within the software package are considered to be the essential core IP of the subsidiary and they differentiate this product from everything else on the market. These algorithms are a carefully guarded secret. The software package also consumes a set of environmental data (which is provided by the company) that contains performance information on common hardware.

Operation of Phoenix
The setup on a client site requires:-
  • installation of the sensor
  • setting up a highly redundant server which contains the software package
  • installing agents on each machine in the data centre to provide performance information to the analytics tool over the network
  • describing the initial layout of the data centre to the analytics tool 
  • allowing the system to run for several days to collect data 

The system contains a learning AI which over time develops recommendations for improving the efficiency of power use from air conditioning, air flow, positioning of equipment, type of equipment and modes of operation. It has been shown to consistently reduce 10% of energy consumption within client sites with constant active monitoring. The process of setting up a new client involves a two day installation of equipment and software on premise. The service is charged for on an initial hardware and setup cost followed by a two year renewable software license. You note that the group is clearly proud of its accomplishments, the technological marvel they have created and their ability to deliver against their vision. Next up to speak is the head of marketing.

Marketing & Business Development
The name Phoenix inspires the ideas of regrowth, of nature and of power and this is heavily used in branding and marketing materials. The company is the largest vendor of such energy efficiency systems in Europe providing a complete service from on premise software package to sensor install. Your systems currently account for 43% of the 2016 market which is estimated at £301 million p.a. according to the latest analyst figures. The head of marketing discusses several successful online campaigns, its strong brand in the European industry and a recently run customer survey that has found a good to high level of satisfaction in over 90% of the client base. 

Whilst the subsidiary has some competitors in Europe, most of these are offering highly custom built solutions that are extremely expensive. The head of marketing also points to data showing the current European market is only a fraction of the £3 billion p.a. applicable market and opportunities exist in growing market share, growing the current market and also expansion overseas. In terms of growing market share, an aggressive sales and marketing plan has been developed to increase MaSh from 43% to 65% by 2021. Phoenix is considered to be the leading European technology in the space according to latest analyst reports. 

In terms of international expansion there are incentives for encouraging growth in markets such as Brazil which currently no-one is providing a well developed solution. The head of strategy agrees and interjects by stating "we consider this to be a highly attractive future emerging market and one the company plans to exploit". You notice the head of sales nodding in agreement.

The US market is larger and considered to be more mature. Over the last seven years there has been a software as a service offering in the US which uses the same sensor technology but with the main software package provided through a public cloud and sold on a utility basis rather than a license fee i.e. the client is only charged for when it is active and running. This has been considered successful and now commands nearly 40% of the US market. However, the US company involved has also been operating in Europe over the last five years. The competitor represented less than 3% of the European market in 2015 but their CEO has claimed in the press that they are growing rapidly and almost doubling in size each year with £15M in revenue in 2015. Though the competitor has not announced its final figures for 2016, it's estimated by some reports to be around £25M. The head of sales adds that this is not a truly digital business as it still requires install of the sensor (either by the client or through a consultancy) and connection of the sensor to the public service. They state "the US competitor might have a cloud based solution but they lack our relationships".

The CIO comments that the US solution provides some features that Phoenix does not have including cross company reporting, industry analytics and a public API. There are also a number of other companies building products on top of this competitor’s public API and their CEO describes a "fairly active development community is growing around this". The Chief Digital Officer (who also runs the product group) adds that we will be building a cloud service. You sense a bit of tension here. You're aware that the organisation was recently restructured with a younger and more dynamic CDO brought into the company. The CIO (the last remaining member of the original team who founded the company) has found herself more sidelined to internal IT and data management. 

The CDO comments that there have also been recent social media stories about the US competitor "eating up" the business models of some of those product companies that have built on their API by adding similar capability into their own system. 
The head of sales suggests that the competitor is struggling to find its way and is being forced to resort to such cannibalistic action. He adds that "we rarely come across the US company in competitive tenders and in any case there are security concerns cited by some clients due to their cloud approach"

The head of sales takes over the presentation and starts to run through the growth of the company. It's obvious that there's a lot of co-ordination between marketing, sales and digital and this team seems to be working well together.  In 2016, the company had a record of £123 million in revenue with over 6,277 customers including 690 new customers, 600 pre-threshold (installed and running but within first two years before renewal begins) and 4,987 on two year renewal. The digital group have been helping in providing mobile tools, communication and other capabilities for the sales team along with marketing for more targeted advertising. The expected growth in clients is provided in figure 161.

Figure 161 - Growth in clients

The attrition rate has been high in recent years at 9% but the Sales team believes this is due to lack of new features and a high cost of software license renewal. To combat this, the digital and product team is being expanded with a focus on new features and the renewal price will be frozen for the next two years (leading to a drop in price in real terms) with possible further reductions due to an efficiency drive. It is believed this combination should enable the company to reduce the attrition rate to 5% or less.

Digital & Product Development
Over the last year, the digital team has worked on improving both the social media reach, the website and the tools used in the company. The focus is now on product improvements and the development of a cloud service.

Cloud Service
This will be one of the most significant investments taken in the history of the company, starting in 2018 and intended for launch near the end of 2020 with £45 million invested. The service will be provided on a license basis in order not to create conflict with the existing model and is considered to be a counter for any future threat from the US competitor as well as necessity for a modern technology company.  It is expected that by 2023 (three years after launch), the cloud service will contribute almost £50M p.a. and account for over 10% of the company's revenue, see figure 162.

Figure 162 - Cloud Service revenue

The Phoenix cloud service will provide cross company reporting and advanced analytics. These capabilities will also be included in the on premise service. The public service will run on a major cloud provider, using emerging DevOps practices. The core algorithms and logic of Phoenix will be maintained but adapted to this new world. The business model was then explored including a business model canvas outlining the new programme (in figure 163).

Figure 163 - Business Model Canvas

Technology changes
Despite the benefit to clients in terms of energy savings through efficiency that Phoenix creates, there exists some concern over the high cost of the system in the market as was noted in the customer survey. There are two potential routes for reducing the cost - the sensor technology and data costs.

Sensor technology
The sensor technology accounts for 73% of the installation charge of £67K. There is a range of new, more commodity like sensors that has been launched in China by an extremely large manufacturer. These are far simpler, vastly cheaper (about 1/100th of the price of the existing sensors) and highly standardised. However, they are also extremely basic and lack the sensitivity and capability of the sensor that Phoenix uses. The CDO points out that the product team have attempted replacing the expensive sensor with one of these cheaper versions but the performance and analysis was severely degraded making the system almost unworkable. The CIO interrupts and says that "a potential solution could be to use lots of the cheaper sensors"

The CDO points out that such an approach has been discussed several times before and would require a complete rewrite of Phoenix and an entirely new set of algorithms and techniques to be developed requiring a new R&D program. The head of operations who manages installations also chimes in that it would require a complete overhaul to process and potentially an extensive upgrade path for over 6,000 existing installations. The CEO also adds that it would undermine the intellectual property developed in Phoenix. This is finally capped off with the Heads of Marketing and Sales both adding that this would create a marketing nightmare at a time of building both a new business in Brazil and a Cloud service. You sense that there is frustration with the group and the CIO and that this is a topic that has been raised many times before.

However, the operations, CDO and sales head all agree that despite these cheaper sensors being not good enough for the the job that the client expects, they nevertheless think it's worth keeping an eye on the market. They are aware of the concept of disruptive innovation and how these cheaper sensors could develop. The CDO now turns to another opportunity. 

Data set
One of the costs to the company is in the environmental data provided in Phoenix. This data requires extensive testing and modelling of various bits of kit commonly used within data centres.  Whilst this is done in-house by the IT department, there is now a data set available on the market which offers this.  It is considered by the product team to be good enough and vastly cheaper than the solution from the in-house IT team. The CDO estimates that by buying in the outside data set then the company could reduce the costs of Phoenix by 3% - 4% and we should move forward with this idea. The Sales and Marketing heads agree the company should not only focus on improving our existing software package but reduce costs where possible. The CIO agrees with this assessment despite the obvious implications for IT.

The head of strategy now discusses the future direction for the company. In a recent meeting, a number of directions were discussed with the entire executive team. These focused on the strengths of the company, the weaknesses in the existing product line, the potential opportunities in emerging markets and future threats such as the US player. Though the discussions have been "challenging", a key number of actions that were considered to be urgent for the company. These were distilled into a new vision document called “Growth and sustainability for Phoenix”. The document highlights the following :-
  • Expansion of existing product into overseas markets such as Brazil. 

  • Increasing the development effort on our existing product line including more advanced reporting and other innovative features.
  • Creation of a digital “cloud based” service for provision of the software.
  • Undertake a significant marketing campaign to promote our solution in the existing market.

  • Investigating the use of the data conversion product that is available in order to improve efficiencies and reduce cost.

These options were investigated with the wider company management team through a collaborative effort, to create a priority list (see figure 164) which was then agreed with CEO to provide a final direction.

Figure 164 - Management priority order

The focus and the priority of the company is :-
  1. build the cloud service
  2. to focus on efficiency including the use of the external data set
  3. to expand into Brazil
  4. to improve features within Phoenix by enhancing product development
  5. to invest in general marketing efforts

The CFO provides an overview of the company performance including a basic P&L for the company with estimates for future years (figure 165) that costs the program of changes highlighted by the strategy.

Figure 165 - P&L

The CFO highlights the following  :
  • The company is profitable with a revenue in excess of £120M p.a., a 10% YoY (year on year) growth and an EBITDA of 26%.  The company has a healthy cash flow and reserves.
  • There has been a recent re-organisation in 2016 with digital combining with product development (previously under the CIO) but now run under the CDO. There has been investment in this space particularly in new technology areas within the company such as the use of social media and cloud based tools. There has also been an investment in features within Phoenix and a recruitment drive for talent.
  • It is expected that the digital group will expand significantly over the next two years with the development of the cloud service which is anticipated for launch near the end of 2020. Though the company is experiencing growth, the investment will have a material effect on EBITDA during 2017 and 2018. There will also be a major marketing campaign around the cloud service starting in 2020.
  • The IT function now runs internal systems and data management. It is expected that efficiency savings can be made in core legacy systems and that shift towards an external data set will reduce IT costs significantly in 2018. This will be offset by some increase due to the cost of setting up operations in Brazil.
  • The launch of the Brazil is planned for 2018. This will include a significant marketing drive, some additional admin (HR), finance and IT costs along with increased sales costs.
  • By 2021, it is expected that the launch of Brazil, the Cloud service along with the efficiency drive in IT will have significantly impacted revenue growth and improved EBITDA. The company by 2021 will have transformed to a more sales, marketing and digital led organisation.

The CEO concludes the meeting and privately apologises afterwards for the reaction of the CIO. He explains "it has been difficult because of the changes. However, this organisation is no longer a startup and some people just have not found adjusting to this new world that easy". You ask what he plans for the CIO and he comments with a wry smile "well, Sarah did express some interest in setting up the Brazil operation but I think she knows that sometimes you just have to move on".

You have a call in forty-five minutes with the executive board. That's how long you have to make your choices. The clock is ticking. So find a stopwatch and start it.

Your first task is to determine whether the company is heading in the right direction. You should determine whether you agree with the priority order given in figure 166. If not, write down what your priority order would be.

Figure 166 - Priority order

Once you've decided that then your next task is to determine what you say to the executive board. 


Next Chapter in Series : Something wicked this way comes
GitBook link [to be published soon]
More on mapping from the Leading Edge Forum.
First in series.

This post is provided as Creative commons Attribution-ShareAlike 4.0 International by the original author, Simon Wardley, a researcher for the Leading Edge Forum.

Wednesday, January 11, 2017

A smorgasbord of the slightly useful

Chapter 11
[early draft version, more upto date version with corrections is kept on medium, still working on this, it will change]

"Here's one I made earlier" is the staple diet of TV programmes when faced with the possibility that something might go wrong. Demonstrations are always a risky business. In the case of this book, doubly so. I want to let you loose on a scenario but alas I'm not even there to correct things if it all goes pear shaped. To manipulate the odds slightly in my favour of a beneficial result then before we get to the scenario (chapters 12 and 13), I'm going to cover some aspects of mapping in a little more detail. This is somewhat naughty because these ideas being fresh in your mind are likely to create a bias which is exactly what I'm hoping for. I'm signposting the answer before we've even got there. It's the closest I could get to "Here's one I made earlier" without writing down the answer first and then doing the scenario.

However, to make this still relevant and challenging then I've hidden these clues throughout this chapter and interspersed lots of useful but not directly relevant concepts in a smorgasbord of the slightly useful. The concepts we will examine are on the opportunity of change, the trouble with contracts, common lies we tell ourselves and how to master strategy.

Opportunity of change

Activities, practices, data and knowledge all evolve and co-evolve in a process which is not always smooth or continuous. In chapter 10, we covered the peace, war and wonder cycle and how previous giants in a peaceful product phase of competition can be overtaken by new entrants in the "war". Those new entrants are likely to settle down to become the titans of that industry. The most interesting aspect of this change is in the change over (point 1 in figure 133) between the two states. Whilst the act itself (e.g. computing) is well understood, this transition causes a great deal of confusion because the nature of the act is changing - we're moving from a world of constantly improving products with feature differentiation to a world of volume operations of good enough. This change is compounded by co-evolved practices, inertia to change, the speed of change due to a punctuated equilibrium and vested interests usually spreading all manner of fear, uncertainty and doubt.

Figure 133 - A time of change

Behind the confusion, what is fundamentally occurring is the rise of new standards, the de facto optimisation of a market and a shift towards commodity. This doesn't mean that alternatives aren't available, we often have a battle over standards e.g. AC vs DC in the "electricity wars" or VHS vs Betamax for video recording standards. It's however marketplace adoption and network effects that will choose the winner and consign others to the niche of history. It's important to understand that in the early stages then everything is up for grabs.

Alternatives in Cloud Computing
When Amazon launched EC2 (its utility compute environment) in 2006, I made a number of calls to executives in traditional hardware companies and offered to help them set up a competing service using our Borg technology - a technology suite that we had be used to provide on demand virtual machines within my company based upon Xen. I was confident we could emulate the APIs of Amazon and though we were behind the game in some areas, we were ahead in others. Overwhelmingly there was no interest and the couple (i.e. two) meetings I had with traditional vendors always ended up with the same result - "how will this help us sell more servers?"

I'd like to say that by 2008 the attitude had changed but it hadn't. In late 2008, in the first of many such trips, I flew to the US, met a number of executives, told them their entire hardware business would be lost, showed them how by creating a market of AWS clones and creating a price war they could exploit a constraint that Amazon would have in building data centres and use this to fragment the market by pushing demand beyond supply. I explained why they wouldn't do this due to existing inertia and why they would lose the war. The lack of interest was palpable. Amazon was not considered a threat but a minnow. To paraphrase what I was told, these companies would be "doing something in the future in that market, creating their own standards and taking this industry away from Amazon if it ever became serious" which they assured me it wouldn't. Amongst this and other prognostications of their own future greatness was the old trope of "how will your stuff sell more servers?"

It was like staring generals in the face and telling them that ordering troops to continue walking north over a cliff wasn't a good idea and getting a response "we've always walked north" and "walking north  is what we do!"

The problem with evolution in business is the threat is much larger than most realise due to the punctuated equilibrium and the rapid speed of change. You can either create a large ecosystem fast which means a very focused effort around creating a marketplace based upon some form of open standards or you can co-opt and eventually aim to own the standard. What you cannot afford to do is dilly dally, rest on your laurels or try to create another differentiated product solution to compete against evolution. Unfortunately, this is exactly what happened. The companies that have lost the cloud war had all the advantage - they had the finances, the skills, the talent, the reach, the brand and everything you could possibly want to win it. They were like generals in charge of massive modern armies going up against a David armed with a sling and a spud gun. Fortunately for David, the generals all ordered their troops to walk north, over the cliff and to their doom.

The cloud war in infrastructure was lost not due to some magical engineering capability of Amazon but instead due to executive failure of past giants. Every single one of them could have won the war with ease. When they finally did act it was too late, with too little investment and often in the wrong direction because of a pre-occupation on what they wanted ("selling servers") and not what their users needed. But users also had inertia to change and in a somewhat tragic act of desperation this was seized upon. Past giants had found their Kodak moment.

When Kodak had finally overcome its own inertia to the shift to digital images, it solved the conflict with its traditional fulfilment business by promoting the idea of the digital photo printer. We can bring fulfilment of printing to photos in this digital world! It tanked because users just started sharing images and bypassed the whole point of the photo.  In the cloud world, the same moment has been created with the private cloud. You can have all the benefits of utility computing but build your own! We can bring "selling servers" into this utility world! It'll tank too.

Certainly private cloud has some merit for dealing with inertia (i.e. often unjustified security concerns) but this is a transitional play at best. It's short lived, it's not the end game. Alas even today, in 2017, there are people arguing that the future is a hybrid mix of public and private cloud. It's not, it never has been. The future has always been a hybrid of multiple public clouds. But why multiple public clouds? The first concern is resilience which is solved through those co-evolved practice such as distributed systems and design for failure. Now, multiple public clouds doesn't necessarily mean multiple public cloud providers. You could use multiple Amazon regions or availability zones and that is a hybrid model. The decision to use multiple providers is a trade between the risk of a single provider failure, the cost of switching between multiple providers and any bargaining power it might provide.

Within the Amazon ecosystem then the cost of switching between regions is low, your bargaining power is relatively weak but you can mitigate risks by designing across many zones. When you combine multiple public providers then you're incurring an increased cost of switching not only through any movement of data but also any change in the syntactic or semantic compatibility of APIs. Syntactic compatibility simply means the APIs have the same structure and form. Semantic means they operate in the same way. Without this compatibility then your management tools which work with one might not work with another and that incurs a cost.

To reduce this cost then either you want multiple public providers with are interoperable or management tools which covers both. But management tools can only cover both by offering the lowest common denominator i.e. the common factors between both. Unless you have a way of ensuring interoperability (e.g. some form of open standards and testing service) then switching incurs an additional cost beyond the movement of data or loss of some useful functionality through a common denominator. But switching is still desirable in terms of bargaining power and ensuring competitive pricing in a market. These are the trade offs you need to consider.  Well, in practice, you don't. There is no interoperable and competitive market between multiple providers. There is instead one continent (Amazon), some substantial islands and then a lot of small atolls most of which are sinking fast into the sea. But it didn't have to be this way, nor will it necessarily stay this way.

If I go back to the Zimki plan (figure 134) then along with creating an ecosystem models around a serverless platform, we also intended to create a marketplace of platform providers and hoped for a marketplace of infrastructure providers. It's worth making a distinction here. You have a consumer ecosystem (as in companies or individuals that use your component), a supplier ecosystem (as in companies or individuals that provide components for you to use) and a marketplace (of consumers and suppliers around a component). These are not the same.

Figure 134 - Marketplace or ecosystem or both?

In the case above, we aimed to provide a consumer ecosystem around platform as a service i.e. we hoped many others would consume our component enabling us to run that "innovate-leverage-commoditse" model and to sense future change. We also aimed to provide a marketplace of providers (i.e. to enable others to set up as platform players) in order to overcome concerns over lock-in to a single provider. We also consumed components of infrastructure and hoped that we'd see a marketplace of providers with interoperability between them. We intended to achieve our goals through the open sourcing of both Zimki (the platform play) and Borg (our infrastructure play) which would co-opt the APIs of any major utility provider if it appeared. Hence my phone calls to those executives.

Open sourcing a technology not only enables it to evolve quickly but it can help in creating an interoperable marketplace with switching between providers especially when combined with testing services. The last part is crucial, as there is always the danger than providers will try to differentiate with features in a commodity market creating what's known as a collective prisoner dilemma - everyone weakening their own position and that of others through self interest. Unfortunately this was the plan in 2005 and by 2007 the entire project had been killed off. By the time the hardware executives finally woke up and started to play an open source game around OpenStack in 2010, they invested far too little, far too late. They failed to co-opt (arguing for differentiation) and failed to prevent a collective prisoner dilemma forming. Hence, we've seen not only industrialisation of infrastructure to a commodity but also centralisation towards Amazon.

It's water under the bridge but if the competitors had reacted more timely, put in enough investment, focused on co-opting APIs, created a price war to force up demand beyond supply due to Amazon's constraint then we might have seen a vibrant marketplace of many providers. The point to get across is that industrialisation to a commodity does not necessarily mean centralisation. What it means is standardisation to a de facto. The question of whether something centralises or decentralises is influenced by other factors beyond evolution including executive gameplay. The reason why Amazon dominates the market is it has played the game well whilst most competitor executives have not despite all their advantage. Equally, this is not a permanent state of affairs. A better set of players may emerge (e.g. from China) and cause the market to decentralise. The game however becomes much harder once a standard becomes established and the victors have emerged. The time to change the players and to play the game well is in the time of transition between the states, in the change-over from product to utility. If you miss this then to change the game again requires a bloody battle of attrition to unseat a titan, a game of last man standing and often political intrigue.

For infrastructure, this time of transition has long passed and the victors have emerged. For the serverless platform world, we're in the midst of this change over at the moment, the war has been raging but it will soon be over. By 2020, we should probably know who the winners and losers are, which will just be in time for a group of software executives to wake up and announce they'll be "doing something in the future in that market".

Opportunity on a map can be found in several places. From the genesis of the novel or the provision of unmet needs to differentiate a product or the time of transition from one state (e.g. peace) to another (e.g. war) - see figure 135.

Figure 135 - Opportunity and change

The maps won't tell you what path you should take but they are a guide to help you discuss and decide.

The trouble with contracts

Contracts like plans are often the bane of my life. It's not that don't have a use, they do in terms of setting expectations. Unfortunately, for some reason I have yet to fathom, people tend to believe that the contract or plan represents a static reality. If it's in the contract then it must happen as it is written followed by disputes when it doesn't. To explain why this is a problem then I'm going to use an example for a communication platform for a large organisation with a distributed workforce that often worked on events.
They had a detailed plan for the communication platform, an exhaustive specification (hundreds of pages) and a division of the system into lots for contracting. It all seemed very sensible. However, as is my usual style, when I first met the team then I asked the question - "What is the user need?"

The responses were somewhat elusive and wispy. It was felt that the answers were in the pages of the specification but they were not to hand. No-one had put them together. So, we spent a few hours and mapped the system out (see figure 136).  The basic user needs were device to device communication (e.g. "I need to tell Joe to pick up a box"), point to multiple points (e.g. "I need to tell all my team to come to Sheffield"), emergency function  (e.g. "We need more staff at this event"), scheduling (e.g. "I need to know where to go next") to various applications, video recording and even simple use as a telephone.

Figure 136 - Communication Platform

To make the system manageable, the organisation had broken it into sensible contract "lots" based broadly upon financial value and other characteristics. However, when I overlaid those lots onto the map then there was an obvious problem.  One lot was very broad including items which were industrialised and others which were highly specialised, often custom made (see figure 137).

Figure 137 -  Trouble with outsourcing

Why is this a problem? Let us assume we apply an outsourcing approach through some form of contract structure. Obviously we want to know what's being delivered hence we put effort into a specification. The provider, in order to manage its own risks will introduce a change control process as it's only reasonable that if we change our mind then we incur the cost of this. But look again at the map above. Some of the components are industrialised and these won't change. We can specify what we want here. However, some of the components are nearer the uncharted space. We don't know what we want here, these will change and we will incur that change control cost. The change control process tends to be burdensome and expensive because it's design for minimising change (what you want in an industrialised space) but we're applying it across the entire spectrum. The one thing we can guarantee is those custom built activities (still relatively unknown) will change, our change cost will spiral and dispute will happen. Let me be clear, we can anticipate dispute even though we haven't yet started. I can also tell you that some fool of a Took will decide that the solution is for future projects to be "better specified" incurring not only increased costs in trying to specify the unknown but repeating the same mistake of change control costs. Unfortunately, without mapping the environment and overlaying the contract structure then you won't be able to find this problem until you hit it i.e. after the contracts are signed. Specification documents and business process diagrams don't provide you with the situational awareness you need.

In 2008, I spent quite a bit of time looking at various projects and would commonly see this problem. Outsourcing had already got a bad name but the problem isn't outsourcing, it isn't even contracts, it's the way we apply such approaches across very broad systems containing both industrialised and often novel components. There's a far better way to deal with such systems.

One case worthy of praise in business, is the truly marvellous work of Lieutenant Colonel Dan Ward. If you've never read FIRE or the Simplicity Cycle then stop what you're doing (i.e. reading this) and go read them. I first came across FIRE (fast, inexpensive, restrained and elegant) when it was called FIST (fast, inexpensive, simple and tiny) and was used in military circles. The rename is more about a reboot to make it applicable to the wider marketplace. I happen to prefer the old term (probably my own inertia for having used it) because it's just a bit more punchy.

Fast means build things quickly i.e. short time scales. It's a constraint on time and reduces the risks of change which comes with long schedules. Inexpensive is more than a constraint on budget, it's a mindset of thrift and re-use. Simple is a constraint on complexity but also a mindset for the pleasing elegance of simplicity. It's less about adding on more but taking stuff away. Whereas the A10 Warthog is an example of elegant simplicity in ground attack aircraft, the F35 is the polar opposite. Tiny means small, as in constrained or restrained as in small budgets, short schedules, small documents, small teams and small components. It's again about mindset, a love of the detail and of self control. It's about saying "Do we really want to add short take off and vertical landing to our bombing run, ground attack, air-to-air combat and reconnaissance aircraft?"

Taking these FIRE principles, I've applied them to our map of a communication platform form above which I've broken down into small discrete areas. Each of which should be managed using small budgets, short schedules - see figure 138.

Figure 138 - FIRE

With such a map we can now apply the use of appropriate methods and techniques. For the more industrialised components we can look to re-use market standards or outsourcing arrangement or even utility providers. For the more novel we can build in-house or have contracts based upon time and material basis (see figure 139).

Figure 139 - Using standard components and appropriate methods

It's worth noting that with novel items then you will tend to try and build these in-house. You might outsource these under a time and material basis to a group that specialises in creating the novel and the experimentation required but this is a different type of arrangement from outsourcing for volume operations.

We can also use the map to organise ourselves with small teams, distributing power away from some central planning office and giving autonomy and control to those on the "ground", at the "coal face" who can make decisions more quickly, with a greater understanding of detail (see figure 140).

Figure 140 -  Distribute power

Using appropriate methods, tighter control on schedules and budgets with empowered people - what's not to like? Actually, there's often huge resistance to this. One of the advantages of the all encompassing contract is that it makes it simple to manage. The unpleasant old phrase of "one throat to choke" comes to mind. It provides someone else to blame when things go wrong or as change control costs spiral (as they would in the original contract structure). Of course, the vendor will blame you for not knowing what you wanted thus leading to the endless calls for better specification which only exacerbates the problem, We inevitably fall for this in business because of the fear of taking the risk, of managing what we need to manage, of embracing the complexity and uncertainty that is life. We instead try to outsource this risk through massive, one size fits all contracts that ultimately incur excessive cost through change control far beyond any risk. To compound this, given enough time we even outsource the skills we need to effectively negotiate "reasonable" terms (if such a thing exists) for these contracts. These problems are acute in business but generally swept under the carpet. They are more visibly exposed in Government contracts with Government IT and "horrendous, costly failure" being synonymous in some quarters.

The normal counter reaction to breaking down a complicated (and possibly complex) system is that it makes it difficult to manage. It exposes many areas to consider, many teams and many interfaces (see figure 141). The reality is those areas and interfaces existed beforehand and the use of a large (and broad) contracts is just a way of trying to make it someone else's responsibility to manage.  We are often willing participants in a game where to avoid managing the environment then we accept excessive cost overruns, inappropriate methods, loss of strategic control and ultimately greater risk whilst claiming the approach reduces risk.  Outsourcing is a global practice that is often disparaged in the popular press due to these associations.

Figure 141 -  Exposing interfaces

I need to emphasise that the problems are not with outsourcing per se but instead with what is being outsourced. The concept of outsourcing is based upon a premise that no organisation is entirely self-sufficient nor does any have unlimited resources and some work can be conducted by others at a lower cost. This is entirely reasonable. The organisational focus should not be on the pursuit of capabilities that third parties have the skills and technology to better deliver and can provide economies of scale.  Every tea shop does not need to be a power generator, a tea plantation, a dairy herd and a kettle manufacturer. This practice occurs safely in more mature industries; the machine manufacturer doesn’t have to make its own nuts and bolts and can instead buy those from a supplier.

Alas IT is not such an industry. A recent study that examined 5,4000 projects concluded that over 66% of large sized (in excess of $15M) software projects "massively blow their budgets" and 17% went so bad that they threatened the very existence of the company. The larger the project, the higher the rate of failure. In comparison, the approach of SOCOM (special operations command) in the US Military is towards smaller projects, short acquisition cycles and re-use. As Dan Ward points out, 88% of SOCOM projects fit the FIRE principles with over 60% of those projects staying within cost and schedule estimates with the remaining 40% experiencing only "modest" overruns. The problems are not outsourcing as a concept but the size and breadth of the projects under such contracts. It is far more effective to think small - as in small teams, small contracts and small areas of focus.

But there's more to the game than this. It also offers up opportunities. Within the communication platform there is a requirement for an application store (see point 1, figure 142). It's not uncommon even in 2017 with the abundance of well established application stores such as Google Play for companies to still believe that they need to build their own. Often such actions can be taken over concerns of control or because some pre-existing effort is under way or in production.  These are all forms of inertia. But how do you deal with such inertia and any pre-existing systems? How can you turn this into an opportunity?

Figure 142 -  Dealing with legacy

In 2008, one of the big inertia barriers to adopting cloud services was legacy environments. These systems depended upon different architectural principles and were not suited to adoption of cloud infrastructure. Many companies decided that what they needed was a cloud service which acted like their "enterprise" environment and thereby gave them the benefits of cloud but without the cost of re-architecting. The reality is that such environments are a trade off between the cost of re-architecting versus the benefit of standardised commodity components. Whilst not a long term future, the appearance of vendors offering such enterprise clouds does provide an opportunity for exploitation. To explain this, I'll outline three basic ways of dealing with legacy :-

dealing with toxicity
The first and most obvious is simply to recognise that a change is occurring, that you have inertia caused by past systems and to invest in re-architecting for the change. All technology investment is toxic over time and you need to continuously refactor to remove this. In many cases such refactoring is not done on a continual basis which stores up problems for the future by creating a large (toxic) landscape which needs to evolve. To avoid huge scale projects (known in the industry as "Death Stars") which attempt to resolve this mess (with the usual catastrophic results) then the change is best done in a piecemeal fashion using small components over time. Even a relatively new company such as Netflix took seven years to remove its legacy and become data centre zero (all cloud). Unfortunately many will wait (avoiding the cost) until it becomes obvious that they have to change at which point they will scramble to build a "Death Star" along with many other companies who have now realised the same. This creates an inevitable shortage of skills which piles on the misery. So, start early!

sweat and dump
A variation of the approach is to deliberately sweat the legacy (i.e. minimise investment) whilst you build the new world. In the case of cloud, this is where enterprise cloud services might have some benefit. By shifting a legacy environment to an "enterprise cloud" provider with minimal architectural changes then you move any responsibility for capex investment to the provider. You sweat the legacy whilst building or using components to replace it in a public cloud service using co-evolved architectural practices. What you want is for the "enterprise cloud" service to provide utility based charging with no long term contract. Despite the empty words you might have given the provider regarding long term future, when you are ready you unceremoniously start dumping the legacy. By such an approach you're shifting capex investment to the provider and reducing this cost for yourself. This method is unlikely to make you friends with the provider so plan accordingly.

pig in a poke
By far the best approach is to convince someone to pay you for your legacy. Just because you are aware that the environment is changing does not mean everyone else is aware. You'll need a bit of misdirection here such as generating a future story for the legacy. In the case of the communication platform, you might convince another company that enterprise application stores designed for companies are the future. If you have a pre-existing home grown application store then you can sell it including some of the underlying environment (from infrastructure to staff) as a "future business" whilst ensuring you have access to it hence providing a revenue stream for the buyer and making the deal seem "sweeter". During this time you work on your replacement (e.g. shifting to Google Play) before dumping your access. This can be a surprisingly effective way to monetise legacy. This will definitely not win you friends with the people you sell it to but then caveat emptor!

When you think about contracts, then look to break them down into small components, don't be afraid to manage the risk and also think about how you can even turn your legacy into an opportunity with a bit of sleight of hand.

It’ll save me money and other lies we tell ourselves.

There are many lies we tell ourselves in business:- the environment changes slowly, we can predict the uncertain, that we can outsource our own risk, that management can be made simple, that the key to success is implementing this culture or that innovation or this principle or that method. If anything, I hope that mapping is teaching you that there are no single methods or simple answers. Even mapping itself doesn't give you the answers, it's just a tool for communication and learning. Whilst not everything is uncertain (for example, the evolution of an act), you have to embrace uncertainty (for example, the genesis of a new act). There is no magic solution that fits all.

Our maps simply describe an environment that consists of multiple evolving components. They contain simple components that have the perception of being well known, well defined and common - the nut and bolt, the plug. They also contain chaotic components that are uncertain and we do not understand such as the genesis of the new. The environment itself can be complicated with many components and at the same time complex in that you have to dynamically respond to changes both caused by climatic patterns and other competitors actions. These terms of simple, chaotic, complex and complicated have quite precise meanings and I'd recommend the reader spending some time becoming familiar with the work of Dave Snowden and the Cynefin framework.

Despite all of this, we try to grab for simple truths. In 2008, this was common place in the world of cloud computing. I thought I'd use a few to illustrate some climatic patterns that are worth knowing about.

Efficiency will reduce our budgets
One of the most common ideas was that cloud computing would reduce IT budget expenditure. It's a notion that if cloud computing is more efficient then to do the same activities then we will spend less. I gave a talk at IT@Cork (in 2008) on how this assumption ignored creation of new industries, componentisation and price elasticity effects. By increasing efficiency and reducing cost for provision of infrastructure then a large number of activities which might have been economically unfeasible become feasible. Furthermore, the self-service nature of cloud not only increases agility by enabling faster provision of infrastructure but accelerates user innovation through provision of standardised components and componentisation effects. This latter effect can encourage the creation of new industries in the same manner that the commoditisation of electronic switching - from the innovation of the Flemming valve to complex products containing thousands of switches - led to digital calculators and computers which in turn drove further commoditisation and demand for electronic switching. The effect of these forces is that whilst infrastructure provision may become more efficient, the overall demand for infrastructure will outstrip these gains precisely because infrastructure has become a more efficient as a standardised component. We end up using vastly more of a more efficient resource. This effect is not new. It was noted by Willam Stanley Jevons in the 1850s, when he "observed that England's consumption of coal soared after James Watt introduced his coal-fired steam engine, which greatly improved the efficiency of Thomas Newcomen's earlier design"

In figure 143 I've outlined the main effects. First (point 1) you have an activity that has evolved from genesis through to product and finally becoming more industrialised e.g. a commodity or a utility. Ultimately, this will allow for more efficient provision of the act.

However, the more industrialised component can enable greater use of the component as previously uneconomical acts become viable (point 2). There can also be a long tail of things we'd like to do, unmet needs which are enabled by the efficiency of provision.  If you look at computing then I can buy a million times more resource for the same money than I could twenty years ago. This doesn't mean IT budgets have reduced a million fold in that time, instead we've ended up doing more stuff. The final aspect (point 3) is that as new acts evolve becoming more ubiquitous they increase consumption of the underlying component.

Figure 143 -  Jevons paradox

But can't I just ignore this? Won't it reduce my budget because all I care about is what I produce and not what new fangled industry is created or what unmet needs can now be met? That depends upon your competitors. They too will enjoy the benefit of efficiency and may well opt to create those unmet needs, to build that long tail of desired things. You might be that conglomerate of tea shops whooping with joy that the public internet will reduce the cost of transferring stock control information versus your past pre-installed private network. Alas, your customers are now expecting WiFi access with their cup of tea. Your competitors are providing this.

Cloud will be green
One of the common talking points in 2008 was whether cloud computing would be green. There was a lot to this from the substitution of physical goods for digital to the levels of inefficiency in the existing industry to the material waste in unused capacity to the means of energy provision. There was undoubtably a lot of waste and potential for improvement hence in an argument could be made for Cloud being green. However, there's something more long term to be considered here. When we consider a value chain, we're constantly industrialising components and building new systems on top of them. Machinery on top of the nut and bolt. Intelligent software agents on top of databases on top of computing on top of electricity. We are constantly creating higher order systems built upon more industrialised and ordered components. We are building towers of order out of the chaos. As with other biological systems, we are decreasing local entropy and that requires energy. We might be far from efficiently using energy today but regardless our underlying demand and consumption of power will increase (see figure 144). In order for progress to be green then inevitably we need to turn to the means of energy production.

Figure 144 -  Feel the power

We can deal with it later.
At the beginning of a shift from products to more industrialised forms, then most large companies (with the exception of the enlightened) will tend to ignore the change due to inertia caused by pre-existing practice, assets and markets. The most telling signs are often overlooked until it is too late. One of these signs is the flow of capital. We tend to see a marked movement of capital away from the existing industries (the past) and towards both the more industrialised forms and new activities built upon it.

If I take figure 143 from above and overlay this flow of capital and the peace, war and wonder cycle onto it then we can get a sense of what is happening. At the same time as an act is become more efficiently provided through industrialised forms with its demand increasing due to a long tail of unmet needs and the creation of new industry then capital is flowing away from past product vendors towards the new vendors and new companies serving those new markets. Add in the co-evolution of new practice caused by the evolving act, the new forms of organisation that arise, the speed of change caused by a punctuated equilibrium, the inevitability of change (i.e. the Red Queen) and the inaction of past giants caused by inertia to the change then what you have is destruction of the past at the same time as the future is being created. The combination of competition with basic climatic patterns such as inertia and co-evolution creates this constant pulse of new consumer needs, new vendors, new methods of production, new markets and new forms of industrial organisation. This heart-beat was described by Joseph Schumpeter as "creative destruction" (see figure 145) and by the time it becomes obvious, it's usually too late to react.

Figure 145 -  Creative destruction

But hang on! If we know about the cycle, if we can use weak signals to anticipate it, if we understand the different forms of inertia then surely we can prepare and adapt when it occurs? Why on earth would any company be destroyed by it? The problem is blindness and this leads to the next lie we tell ourselves.

Execution matters more than strategy
One thing I had become more aware of in my journey around companies was that few seemed to have examples of maps. They had things they called maps but these diagrams lacked those essential characteristics of being a map e.g. visual, context specific, position relative to an anchor and movement. When I pointed this out, I'd often get a lot of pushback especially on the aspect of movement. This still happens today, so it's worth emphasising.  Movement isn't simply about drawing a line on a picture it's about the consistency of meaning of such a line. Position, anchor and movement are essential for navigation. Take a look at figure 146. It's a farm (that's the context), it's visual, it has position of fields relative to an anchor (in this case the compass) and you can draw movement on it. You'd probably agree that you can give this map to someone else and they could quite happily find the barley field with it.

Figure 146 - A map of a farm.

I've taken the same map, kept the same number of fields plus their shape and relative area sizes but removed any concept of position and the anchor. I've just placed the field in order of what type they are - fruit, livestock and crop. I've added a movement line to it. The question is, could you hand this "map" (figure 147) to someone else and expect them to find the barley field?

Figure 147 - A "map" of a farm.

It should be obvious that the answer is no. Movement and its consistency - you can follow this path to go from A to B - are not only essential qualities of a map but they also turn out to be essential for map making. These navigational qualities enable us to learn about the environment whether through a visual form or a equivalent internalised mental model. Take for example the tube map. The stations might not be in exactly the right geographical position but it is nevertheless a useful map. It has position of stations (anchored by the tube network itself) and consistent movement between them. If I'm at Bond Street there are multiple routes for me to get to Cannon Street but there is consistency. If I'm travelling anticlockwise on the circle line, then I know I will travel through South Kensington, Sloane Square, Victoria, St James' Park and Westminster on my journey (point 3, figure 148). If there was no consistency then the circle line might take me via Victoria, St James' Park and Westminster one day and Victoria, Edgeware Road and Mornington Crescent the next. I wouldn't know where I would end up and it would be impossible to navigate.

Figure 148 - A  tube map

Of course, the tube map doesn't have to look like the above. You could build your own by simply travelling on the trains and recording the stations but as long as you can consistently describe movement then it is a map you can share with others. Now, tube maps are currently a vogue in the business world with various companies creating them to describe complex environments. Unfortunately these "maps" lack consistency of movement. For example, in figure 149 we have a "tube map" of the digital world. The maps lacks context being simply a grouping of technology and digital concepts. It has position of components but it is not clear what anchor is used. Lastly, according to the "map" then to go from Online Ad Networks to Agency Holding Companies you need to travel through social advertising then email marketing then digital agencies then management consultants then campaign management then media metrics then media agencies to reach the destination. Is this true? On what basis is that movement consistent and justified? I suspect it's not. This is not a map, it's a diagram of loosely connected concepts and questionable relationships.

Figure 149 - A tube "map" of the digital world

So, why does this matter? Without maps then situational awareness will be poor.  Of course, back in 2008, I was still firmly under the illusion that people were just keeping their maps secret from me but doubts were growing. I started to have this notion that companies were actually blind to change and if people couldn't see the environment they were operating in then how could they prepare for predictable forms of change?  By the time such changes would become obvious, the inertia and their pace would make them unsurmountable and even fatal. However, in discussion with others I was often told that this didn't matter, that strategy was fairly meaningless compared to the real key which was execution. I had serious doubts about this because firing a gun rapidly doesn't help you if you don't know where to fire it.

In 2010, Professor Roger L. Martin challenged this notion head on in the Execution Trap. If you haven't read it, go do so. Martin's argument was there was no distinction between execution and strategy, they were part of the same thing. By pure chance, in 2012 under an LEF research project then I had the opportunity to test this. Every company told me they had strategy but I was acutely aware that there existed different levels of situational awareness. I had been interviewing 160+ Silicon Valley companies looking for examples of open gameplay whether open source, open data or open standards. I plotted these 160 odd companies against their level of strategic play based upon situational awareness (i.e. using their understanding of own and competitors value chains and how they were evolving) versus their propensity to take action (in this case to use an open approach to change a market). The result is shown in figure 150.

Figure 150 - Awareness vs Action

The bigger the bubbles, the more companies at that point. This was Silicon Valley, supposedly the top end of competition and even here there were companies building strategic play based upon low levels of situational awareness and hence near blindness to their environment. Now, if execution rules then the companies on the right hand side of this graph with a high tendency towards taking action should probably on average perform better. Of course, if strategic play based upon situational awareness was important then the companies at the top of the graph should perform better. I decided to take those companies and examine market cap changes over the last 7 years. The results are shown in figure 151.

Figure 151 - Market Capitalisation impact

What the data strongly suggests is those companies with high levels of strategic play based upon situational awareness and a propensity towards action perform better. Just having a focus on action is not enough.

In the case of companies having low levels of situational awareness (i.e. those in the bottom half) then action (and how well you execute on it) does matter. Those with poor situational awareness and low propensity for action performed negatively whilst those with poor awareness but a high tendency towards action were neutral. In other words, if you're blind to the environment then it's better to shoot faster and with more impact just in case you did hit something. Hence if you're competing against others with poor situational awareness then I can see how an argument that "execution matters more than strategy" can occur.

However, if you have poor situational awareness and are competing against someone with high situational awareness then you might have a much higher propensity towards action and better execution of such but they will still tend to outperform you. I find myself strongly in agreement with Professor Martin that strategy and execution are part of the same thing but also I'll add that situational awareness is a key part of this. This study however was in Silicon Valley and the levels of situational awareness tended to deteriorate outside that cauldron of creativity.  It had taken me several years to discover some weak evidence to back up my initial suspicions that corporate blindness (i.e. very low levels of situational awareness) was a problem. But how common place is this?

In 2014, I was messing around with modelling agents in a competitive market and looking at company longevity. This was partially out of curiosity, a desire to learn and general play. I wasn't expecting to find anything. I created a simulation with 1,000 agents (companies) competing against each other with each company having a starting age of 45 years. I added some variables for disruption through product vs product substitution, overlaid a peace, war and wonder cycle including new entrants and disruption of past players. I then added steps for acceleration of evolution due to industrialisation of communication mechanisms.  I ran a multitude of scenarios and noticed patterns starting to emerge. One of the most interesting is shown in figure 152

Figure 152 - Agent modelling of competition.

What's happening in the above is a constant undulation in average company age as the environment moves through these cycles.  The system is constantly attempting to return to a higher average age but the constant wars and disruption by new entrants (on top of the normal product to product substitution) keeps this in check. However, the acceleration of the cycle (due to industrialisation of means of communication) is causing a shift downwards to a lower age (and a new stable plateau around which age will oscillate). What's interesting about this pattern is it reasonably closely mimics Richard N. Foster's examination of average company age in the S&P 500 despite being a random agent model with set rules and parameters. Why is that interesting? Well, one of assumptions made in the model was the agents were blind.  The pattern is highly influenced by the ability of the agents to adapt i.e. if we assume high levels of situational awareness and the ability of companies to evolve then this pattern doesn't happen and a completely different pattern of dominance emerges. This, combined with my own experiences of industry and previous experiments on situational awareness versus action was enough to give me some confidence in what I started to suspect in 2008. Large parts of industry are blind to the environment they are competing in.

We're not blind, we have principles!
A common counter to this idea that companies were playing blind was that it didn't matter. If we could find the ideal algorithms, rules or principles then we could create that sustaining organisation. You can think of this as a variation of Conway's Game of Life but with the conceit that all we need to do is to find the right code. I’ve often found World of Warcraft (a massive multiplayer online role playing game) to be a useful vehicle for explaining basic concepts of strategy and this is no exception.

In this example, I want you to imagine two teams of players — the Horde and the Alliance — preparing to fight for the first time in a battleground called Warsong Gulch. Both teams have a short time to prepare before the battle - which revolves around capturing the opponent's flag - commences. Neither team has been to Warsong Gulch before or has experience of fighting in battlegrounds. Just for reference, when your character is killed in the battleground it resurrects a few moments later in your team’s graveyard. One team (the Alliance) outlines its strategy for how it’s going to win the battle. It consists of what they describe as five “universal” principles that they’ve all agreed upon. These are :-

Focus : Capture the flag and win the game!

Doctrine :
  • Do this with great people! We’re going to be the best fighters, wizards and healers.
  • Be prepared to take risks and fail fast! We’re not going to just play it safe.
  • A supportive culture! We’re going to help each other when asked.
  • Open to challenge and asking the hard questions.

The team is enthusiastic and ready to go. Facing off against them is the team of Horde players. They’ve also spent their time preparing but the result is somewhat different. This team understands the importance of maps and uses them for strategic play. They have a map of Warsong Gulch and have developed a “strategy” which consists of  :-

Focus : Capture the flag and win the game!

Doctrine :

  • Develop mastery (perform your role the best you can) .
  • Act as a cell (a single unit) e.g. use concentrated fire, work and move together.
Context specific play :

  • To begin with team will act as one cell in an initial all out attack. The group will quickly move through central tunnel towards enemy base, taking out opposing players that interfere. Always take out opposing healers first, then wizards and then fighters.
  • Once their flag is captured by our fighter, the group will work to take out opposing players and setup camp in their graveyard (see map in figure 153) killing off opposing players as they are resurrected and before they create any form of group. Taunting opposing players is encouraged.
  • Once their graveyard is contained, the cell will split into two cells. A small offensive group consisting of a couple of wizards will take out opposing stragglers and the larger cell (including our flag carrying fighter) will continue to camp out in the opposing team graveyard killing all players that resurrect. Once opposing players are contained in graveyard the cell will reform and a solo mage will keep running the flag. If the plan fails then the group will reform around our flag carrier.
Figure 153 - the Map of the play

Now, the Horde team has focus, principles and some form of context specific strategy based upon an understanding of the environment. It might not work but then the Horde players can use their maps to refine their gameplay with time. I can almost guarantee that when the battle kicks off, the first questions from the Alliance players will be “Should we attack or defend?” and “Where do we need to go?”

Arguments within the Alliance team will then happen and before they know it the Horde will be upon them. The next cries you’ll hear from the Alliance members will be “Help!” and “Why is no-one helping me, I need help here!” and “Where are you?” followed by endless bickering that this or that player isn’t good enough to be part of the team and lots of shouts for “What is going on?” or “Where is everyone?” or “Should I grab their flag?”. In all likelihood, the Alliance team will be quickly broken into a panicked rabble. I know, I've been on that team and watched the mayhem. The point I want to emphasise is that principles are fine and yes strategy has to adapt to the game but don’t confuse the two. A set of principles does not make a strategy. Though it’s certainly better to have a set of principles than to have no principles and no strategy. This is equally applicable in business.

There is however another aspect to consider. Within World of Warcraft there are many teams of Horde and Alliance players. Imagine that the Alliance players not only have no map, they’re not even aware of the concept of a map. All they can do is try some principles and share them from one team to another as “Secrets of success”. Imagine the Horde players understand the concept of maps, use them and share between them. Pretty soon, every Horde team will be winning using a wide variety of strategic plays. The Alliance doesn’t stand a chance until every player in the Alliance has built some mental model of the world (an internal map). Of course, every new player that joins the Alliance reduces this shared understanding. The best the Alliance can do is to tell the new player to "follow Morgana the Wizard and just do what she does" in the hope the new player will build up some mental map.

Now ask yourself, what do we do in business? Are we using maps for context specific gameplay, learning and communication or is our strategy more akin to copying “secrets of success”, "following others" and principles from other companies i.e. we should be like Amazon, Netflix or AirBnB? Are we playing the game like the Alliance or the Horde? As tempting as it is, there is no secret formula, no magic secret to success. Conway's game of life consisted of cellular automaton that did not learn from the environment. We are not that. Awareness of the environment will always create an advantage over others and yes, I'm afraid the very nature of competition (even cooperative competition) is about creating an advantage. If anything, understanding the landscape better than competitors is the one area of continual sustained advantage because the landscape of business is always shifting.

Focus on core!
Another common counter point that was raised was the importance of core, having a goal and clearly defined purpose. At the same time, Silicon Valley was raving about "the pivot". In short, you should have a goal unless you pivot to another goal. The problem of course is that strategy is not a long linear path but a constant iterative process. The actions you or others take can change that game. All you can hope to do is to set a direction and adapt along the way or Deng Xiaoping would say "cross the river by feeling the stones". Core is at best transitory, it doesn't matter whether you're a software company or a legal firm.

Let us take the example of a legal firm. You only need to travel back to the 1980s to find a world where Will writing was a rather bespoke activity and legal firms made not inconsiderable sums from such practices. There was a constraint in terms of lawyers and it was a rather cosy world. Of course, industrialisation happened, Wills became more of commodity automated through standard templates and online services. Despite the gnashing of teeth and inertia created by past success (point 1, figure 154) the industry had to adapt. I've taken a liberty and simplified the components such as templates & computing to automation. What I want you to note is that the constraint between lawyers and wills was broken. Fortunately there was a wide variety of other contract structures which users demanded.

Figure 154 - Change to Wills

Alas, despite recent experience of this change, the industry is once again facing industrialisation of general contract writing through the use of AI systems. Naturally, there is the usual inertia to such changes - it's a relationship business, they won't be good enough - but since we've gone through this cycle in that industry within living memory it's hopeful that more will adapt successfully this time. I suspect not (see figure 155). Once again the constraint of lawyers but this time to contracts will be broken.

Figure 155 - Change to Contracts

The point of this is that if your vision had been to provide personal will and contract writing services based upon access to lawyers, then what worked in the 1980s will by 2030 be mainly irrelevant or at best a niche market. There's nothing you can do about this because you're not solely in control, there are other players in the market and just because you don't want it to become a commodity doesn't stop someone else exploiting it as such. These sorts of changes can also hit you from multiple directions including from lower down the value chain, for example through reducing barriers to entry into your market. The newspaper industry has suffered a recent example in the printing press. Back in the 1980s, if you wanted to be a journalist then you had to work for  a newspaper which owned or had access to a distribution network and printing presses. These capital intensive assets were a constraint that acted as a barrier to entry. They were also a mechanism of control over journalists - there was a limited number of newspapers you could work for.

Industrialisation of the means of mass communication through the internet was first considered a potential boon for media industries. However, it broke the constraint which has meant a flood of new entrants came into the market. Also any journalist can now set up their own online paper. This liberation changed the main reason why you'd work for a newspaper. It was no longer because they control the means of distribution but instead because of social capital - its network, brand, reputation - and access to other services. But even the act of collecting, curating and writing news is now under pressure from AI with its more widespread use in business and sport reporting. The National Society of Newspaper Columnists, founded in 1977, has a core focus to promote professionalism and camaraderie among columnists and other writers but how does that mission fit into a world of computer generated copy? It's the same with automotive industry where a core focus on the human driving experience might be relevant for the past but irrelevant or niche in a future of self driving cars. Of all the terms I come across then focus on core is probably the most destructive for the longevity of a company. To overcome it, you simply to have to accept the truth that there is no core other than a transient focus.

Mastering strategy as simply as I can

We've covered a lot of ground in these chapters, so I thought in this final sections I'd recap some of the basics and how to master strategy. You'll need this for the scenario.

Step 1 — The cycle
Understand that strategy is a continuous cycle. You don’t have all the information you need, you don’t know all the patterns and there are many aspects of life that are uncertain.  Fortunately not all is uncertain. Start with a direction (i.e. a why of purpose, as in “I wish to win this game of chess”) but be prepared to adapt as the game unfolds (i.e. the why of movement, as in “should I move this chess piece or that one?”). Your first step on the journey is to understand the cycle of strategy - figure 156. Lots of people can help you here from John Boyd (OODA loops) to Sun Tzu (art of war).

Figure 156 - the strategy cycle

Step 2 — Learn the landscape
Your next step is to observe the game i.e. to look at the landscape - figure 157. This is essential for you to be able to learn about the game, to communicate with others and to anticipate change. To observe the landscape you must have a map of its context. Any map must have the basic characteristics of : being visual, context specific (i.e. to the game at hand including the pieces involved), position of pieces relative to some anchor (in geographical maps this is the compass, in chess it is the board itself) and movement (i.e. how things can change, the constraint of possibilities). In business, extremely few companies have maps and so don't worry too much about where others are going and grand proclamations they might make.

Figure 157 - Build a map

Step 3 — Learn and use climatic patterns
Once you have a map, then you can start to learn the next part of the strategy cycle i.e. climatic patterns.  In business maps, these are the common economic patterns that effect all players and can be considered the rules of the game. Use those patterns to try and anticipate where the market is heading. The more you play, the more rules you’ll discover.  It's really important that before you start trying to organise and structure yourself (i.e. apply doctrine) that you do this around where the market is going and not where it has been. No-one ever wins by building the perfect structure for the past. We've covered a pretty extensive number of the basic economic patterns but as I reminder, I'll list them adding a few more flourishes where needed.

Climatic Patterns

Everything evolves through supply and demand competition
If the conditions exist that a person or groups of people will strive to gain some form of advantage or control over others due to a constraint (i.e. a limitation of a resource or time or money or people) then we have competition. If competition exists then the components effected will evolve until they become industrialised. This impacts everything from activities (what we do), practices (how we do something), data (how we measure something) to knowledge (how we understand something). The map is never static but dynamic.  It's also important to understand that if competition exists then you will be in conflict with others. Sometimes the best way of resolving this is through coopetition (i.e. cooperative competition) and building alliances. In other cases, depending upon the context, then you have to fight even to the point of a game of last man standing. In any significant landscape then you're likely to find yourself building alliances on one part of the map whilst at the same time fighting other companies in another and withdrawing from a third. However as the components on your map evolve then your former allies can become foes and vice versa. Microsoft and open source used to be mortal enemies, they're now often found to be best buddies. To manage such a dynamic and fluid environment then you're going to need to be able to observe it.

Evolution consists of multiple waves of diffusion with many chasms.
Evolution consists of many instances of the same act e.g. a phone, a better phone and an even better phone. Every instance of an evolving act will diffuse through its applicable market. Those markets will change as the act evolves i.e. the market for first custom built phones is not the same as market for more industrialised phones. The process of evolution can include sustaining, incremental and discontinuous change e.g. product to product improvements or product to product substitution. This path is not smooth, it is not linear, it has many branches and dead ends (e.g. phones that failed). Furthermore the actions of individual players are unpredictable. Hence you can know the direction (e.g. phones will industrialise over time) but not the steps and the exact path taken (this phone will be more successful than that phone) until you have walked it.

You cannot measure evolution over time or adoption, you need to embrace uncertainty.
The only consistent mechanism I've found for measuring evolution is ubiquity and certainty i.e. how well understood, complete and / or fit something is for the environment.

The less evolved something is then the more uncertain it is
By definition, the novel and new are more uncertain than industrialised components such as commodities and utilities.  The uncharted space consists of the unknown i.e. "Ere be dragons".

No choice over evolution
In a competing ecosystem then the pressure for adoption of a successful change increases as more adopt the change. This is known as the "Red Queen" effect i.e. you have to continuously adapt in order to keep still (in terms of relative position to others). The one thing that standing still will guarantee is that you will be overtaken. It has a secondary effect which is by adaptation then competitors limit the growth of a single company and prevent a run away process.

Commoditisation <> Centralisation
Don't confuse evolution to a commodity with centralisation. They are governed by different factors and an industrialised component can easily yo-yo between centralised and decentralised forms. Competitor gameplay is one of those factors which determine whether we're going to start with a more centralised or decentralised world.

Characteristics change as components evolve
The characteristics of a component in the uncharted space are not the same as the characteristics of the same component when it becomes industrialised. In any large system then you're likely to have components at different ends of the evolution scale. This leads to the Salaman & Storey Innovation paradox of 2002 i.e. the need to innovate requires polar opposite capabilities to the need to be efficient. However, a word to the wise, a company has to manage both the extremes along with the evolution between them. It's really important to remember that there is a transition from uncharted to industrialised. Don't organise by the extremes alone.

No single method fits all
Because of this changing characteristics there is no one size fits all methods or technique applicable across an entire landscape. You have to learn to use many approaches and so avoid the tyranny of any single one. However, expect tribes to form and endless pointless debates such as agile versus six sigma or outsourcing vs insourcing.

Components can co-evolve
All components can evolve whether activities, practices, data or knowledge but they can also co-evolve. This is commonly seen with the co-evolution of practice (how we do something) with the evolution of an activity (what we do) especially as we shift from products to more industrialised forms. What causes this is the change of characteristics of the activity. DevOps is one such example of co-evolution.

Efficiency enables innovation
Genesis begets evolution begets genesis. The industrialisation of one component enables novel higher order systems to emerge through componentisation effects. But it also enables new features for existing products to appear or even the evolution of other components. The industrialisation of mass communication to a standardised utility such as the internet enabled the industrialisation of computing to a utility. I use the word innovation to describe all those changes from the genesis of a new act, feature differentiation of an existing act or a change of business model (e.g. shift from product to utility). The evolution of one component and its efficient provision enables innovation of others.

Higher order systems create new sources of value
It is the genesis of new acts, enabling new user needs that creates future sources of differential value. I specifically state "enabling" because in many cases the users are unaware of the future needs they might have.

Future value is inversely proportional to the certainty we have over it.
Genesis of a component is inherently uncertain but it is also the point at which a component has its highest future value. You have to gamble with the novel but there's also the potential for huge rewards. As the component evolves, its potential for differential value declines as it becomes more ubiquitous in its applicable market.  This also means that any component that has not reached ubiquity must retain some uncertainty and some element of risk. The only conditions where a well understood, risk free component exists that is not ubiquitous and is of high value is when there is some form of restriction on competition e.g. a constraint through patents or monopoly. Care must also be taken not to confuse the terms common as in "everyone has one" with ubiquity to its applicable market. Many components have resource constraints (e.g. gold) or the market need is specific (e.g. wigs for barristers and judges).

Efficiency does not mean a reduced spend
Whilst evolution does result in more efficient provision of a component this should be not be confused with a reduction of spending on it. In many cases there is a long tail of unmet demand that efficiency will enable or previously uneconomical acts that become feasible or even the creation of new industries that result in greater demand. This is known as Jevon's paradox.

Evolution to higher order systems results in increasing local order and energy consumption
The constant evolution of components and creation of higher order systems that then evolve means we are always moving to a more ordered environment by reducing local entropy. This requires the constant input of greater amounts of energy though in some cases this can be hidden due to efficiency in previous wasteful consumption.

Capital flows to new areas of value
The lines on the map represent flows of capital whether it's between two existing components or a component and its future more evolved self. Financial capital will seek the area of most consistent value. Hence in the evolution from product to a utility then capital will tend to move away from the pre-existing product forms and towards the more industrialised component and the new industries built upon it

Evolution of communication mechanisms can increase the speed of evolution overall
Evolution consists of many diffusion curves. If a means of communication evolves to a more industrialised form - whether printing press, postage stamp, telephone, the internet - then the speed of diffusion curves can increase. This in turn can accelerate the rate at which future components evolve. Care should be taken here, not to confuse faster evolution with us becoming more innovative as a people. Certainly we have greater opportunity to build new things but don't assume we're getting smarter.

Change is not always linear
There can often be a perception that change is gradual because one instance of a component (e.g. a product) is replaced by another in the same stage of evolution (i.e. a more feature complete product). This illusion of smooth and gradual change lulls us into a false sense of security that all change is such.

Shifts from product to utility tend to demonstrate a punctuated equilibrium
The shift across a boundary e.g. from custom to product or from product to commodity tend to visibly exhibit rapid exponential change and a shift from the past. This is known as a punctuated equilibrium.

Success breeds inertia
Any past success with a component will tend to create resistance to changing that component. There are many different forms of inertia.

Inertia increases the more successful the past model is
The more success we have had with a component then the more resistance and bias we have against it changing.

Inertia can kill an organisation
Contrary to popular belief, it's not a lack of innovation that harmed companies such as Blockbuster and Kodak but instead inertia to change created by past success. Both these companies helped develop the future industries but suffered at the hands of their past business models.

Creative Destruction
The combination of inertia, a punctuated equilibrium, the red queen and co-evolution of practice means that as we shift across a boundary e.g. product to utility then we tend to get rapid destruction of the past (from business models to practice) along with creation of the new (industry and practices). This was described as creative destruction by Joseph Schumpeter.

Competitors actions will change the game
Climatic patterns are ones that depend upon aggregated market effects e.g. evolution through supply & demand competition. This means that you cannot stop them without preventing competition in the market and the existence of competitors will cause them to happen.

Most competitors have poor situational awareness
Competitor actions are an important part of anticipation. In general however this is not something that you can directly control or even anticipate beyond aggregated effects. Fortunately in today's climate then most competitors act as blind players in which case you do not need to dwell too much on their actions. When you make a move, they are unlikely to understand why or counter you. In the near future, given the potential interest in business algorithms, they maybe even become anticipatable blind automatons following coded secrets of success. In much the same way that Dan Mirvish noted that when Anne Hathaway was in the news, Warren Buffett's Berkshire Hathaway's shares went up which was hinted at being due to sentiment analysis run by robotic trading platforms. This could make the game even easier.

Not everything is random
Not everything is uncertain within the map. There are various aspects which can be anticipated though the level of predictability is not uniform. In some cases you can say what will happen due to aggregated market effects (e.g. this act will evolve) but not precisely when the next iteration of a more evolved product will appear (e.g. it depends upon actors action). In other cases you can anticipate both the what and the when.

Economy has cycles
The economy demonstrates cycles such as the peace, war and wonder cycle.  We start with the wonder of a new, uncommon and poorly understood thing. As we learn more then the applicable market grows and products are produced. New giants form and dominate a rather peaceful time of sustaining competition. There is some disruption (i.e. product to product substitution) and the competition is still fierce but the giants generally weather these storms. Then the act evolves to more industrialised forms, new entrants become the new titans, past giants tend to fall being stuck behind inertia barriers created from their own success. This is the time war where competition becomes life threatening for those past giants. New industries built on the industrialised components form and a new state of wonder is born.

Two different forms of disruption
There is more than one form of disruption such as the unpredictable product to product substitution to the more predictable product to utility substitution. The latter can be anticipated through weak signals.

A “war” (point of industrialisation) causes organisations to evolve
The industrialisation of an act will tend to cause co-evolution of practice and changes to how organisations operate. If the component is significant then this can lead to a new form of organisation.

You need to apply these patterns to your map to start to learn how things could change. You then need to allow others to challenge your assumptions and the scenarios you create - another key part of learning - until you've got a map you all agree with or at least understand e.g. figure 158

Figure 158 - Anticipating change

Step 4— Learn and use doctrine
Now you have an idea of your landscape and how it can change, you’ll want to start doing stuff about it. However, there are two classes of choice ; those which are universally applicable and those which are context specific. The universally applicable choices are a set of principles which we all should apply. These are your ‘doctrine’. At the time of writing, this is my list of basic doctrine - hence Wardley's Doctrine (I really am that unimaginative). This is based upon my observations over many maps with many organisations and contains universal principles that I consider to be reasonably sound.  Many of these we have already covered

Wardley's Doctrine

Be transparent
Have a bias towards openness within your organisation. If you want to effectively learn about the landscape then you need to share your maps with others and allow them to add their wisdom and their challenge to the process. Building maps in secret in your organisations is a surefire way of having a future meeting where somebody points out the blindingly obvious thing you have missed.

Focus on high situational awareness
There is a reasonably strong correlation between awareness and performance, so focus on this. Try to understand the landscape that you are competing in and understand any proposals in terms of this. Look before you leap.

Use a common language
A necessity for effective collaboration is a common language. Maps allow many people with different aptitudes (e.g. marketing, operations, finance and IT) to work together in order to create a common understanding. Collaboration without a common language is just noise before failure.

Challenge assumptions
Maps allow for assumptions to be visually exposed. You should encourage challenge to any map with a focus on creating a better map and a better understanding. Don't be afraid of challenge, there is no place for ego if you want to learn.

Know your users
When mapping a landscape then know who your users are e.g. customers, shareholders, regulators and staff.

Focus on user needs
An essential part of mapping is the anchor of user needs. Ideally you want to create an environment where your needs are achieved by meeting the needs of your users. Be mindful that these needs will evolve due to competition and in the uncharted space they are uncertain. Also, be aware that users may have different and competing needs and be prepared to balance the conflict

Think fast, inexpensive, elegant and restrained (FIRE)
Break large systems down into small components, use and re-use inexpensive components where possible, constrain budgets and time, build as simply and as elegantly as possible.

Be pragmatic
Focus on meeting the user needs and simplify as much as possible. There will always be edge cases or a way to make something more perfect nut but if what you're building could use a component that already exists then try to avoid the urge to re-invent it. If you're a taxi company then investing your funds into making that perfect tyre will not help your business. Always challenge when you depart from using something that already exists. The old adage of "It doesn’t matter if the cat is black or white as long as it catches mice" is relevant here.

Remove bias and duplication
Use multiple maps to help you remove duplication and bias within an organisation. You will often find in any large organisation that there are people custom building what is a commodity or rebuilding something that exists elsewhere. Remember, that they're not doing this because they're daft but because of pre-existing inertia or the lack of any effective communication mechanism i.e. they simply don't know it exists elsewhere. Be warned, the level of duplication within most organisations vastly exceeds any expectations that they might have and you're often treading on the toes of someone's pet project. Large distributed companies often talk about duplication in the single digits e.g. we have six enterprise content management systems. They tend to react poorly when it is "discovered" that they have hundreds or even "thousands". People can get very defensive in this space.

Use appropriate methods and tools
Try to avoid the tyranny of one. Understand that there is no magic solution and that you have to use multiple methods  (e.g. agile or lean or six sigma) as appropriate. In any large system, multiple methods may be used at the same time. Be mindful of ego here, tribes can form with almost religious fervour about the righteousness of their method.

Focus on the outcome not a contract
When using contracts then try to focus on the outcome and what you're trying to achieve rather than the contract itself.  Realise that different types of contract will be needed e.g. outsourced or time and material based or worth based development. Along with a focus on outcomes, try and keep contracts constrained in terms of time and budget.

Use standards where appropriate
If something is industrialised and if standards exist then try to use them. There's always a temptation to build a better standard but try to avoid this or building layers on top of other "standards" unless you have an extremely compelling reason to do so. If you need a toaster, buy a toaster and don't try building one from scratch.

Optimise flow
Within a map there will be many flows of capital - whether information, risk, social or financial. Try to optimise this and remove bottlenecks.

Effectiveness over efficiency
Whilst optimising flow is important, be careful not to waste valuable time making the ineffective more efficient. Understand the landscape and how it is changing before you attempt to optimise flow. Remove the ineffective before you focus on efficiency.

Manage inertia
At some point you will face inertia to change e.g. existing practice, political capital or previous investment. Try and understand the root cause. Ideally use a map to anticipate before you encounter and hence have prepared solutions & counter arguments. If possible, use the maps to enable people to discover their own inertia.

Manage failure
In any system there is risk. Use the maps where possible to help you understand failure modes, what can go wrong and what will be impacted if a component fails. Try where possible to mitigate risks by distributing systems, by designing for failure and by the constant introduction of failure (use of chaos engines such as Netflix's chaos monkey). Mitigate against known failure modes such as building large scale (death star) like efforts.

Think smal1
Know the details, use small teams and break large landscapes into small contracts. Don't be chased away by fears of complexity of management or "too many interfaces to manage".

Distribute power and decision making
Have a bias towards distributing power from the centre including yourself. Put power in the hands of those who are closest to the choices that need to be made.

Provide purpose, mastery & autonomy
Provide people with purpose (including a moral imperative and a scope) for action. Enable them to build mastery in their chosen area and give them the freedom (& autonomy) to act.

Think aptitude and attitude
Understand that people not only have aptitudes (e.g. finance, engineering, operations and marketing) but different attitudes (pioneer, settler and town planner). The mindsets are different.

There is no one culture
Understand that a company which plans for longevity needs to cope with not only the discovery of uncharted components but the use of the industrialised and the transition between these two extremes. You will need different attitudes. You will therefore create many cultures in your organisation e.g. pioneers, settlers and town planners have different cultures. This is not a negative and don't try to grind everyone into a single bland culture. It will not make them happy.

Seek the best
Try to find and grow the best people with the best aptitude and attitude for their roles. Invest in keeping them. Don't force them into becoming something they're not. It's perfectly reasonable for a truly gifted systems tester who excels in a town planning world of massively complicated and automated systems to be paid more than the project manager. What you want to avoid is taking exceptional people out of their role and putting them into something they are not suited to simply because they think that is the only way to progress. Leadership, management and engineering are all aptitudes, they are all valuable and they have to work in concert. If the hierarchy of your organisation uniformly reflects your pay scales then you're likely to be draining talent from where it should be and putting it into roles that it is not suited for. This is often done for arguments of "responsibility" or "managing bigger teams" (which also causes people to try and accumulate empires) or "spreading experience" or "career path" but there are alternative ways of achieving this than taking a gifted engineer and turning them into a mediocre project manager. This is probably one of the most difficult areas as ego is quickly encountered.

Design for constant evolution
Create an organisational system which copes with the constant ebb and flow in the landscape. Ideally, changes should flow through your organisation without the needed for constant restructuring. A cell based structure using a system of theft with pioneers, settlers and town planners is one such system.

Use a systematic mechanism of learning
The purpose of mapping is not just to create a map and a shared understanding but also to learn climatic patterns, doctrine and context specific play. Maps provide a systematic way of doing this as long as you collate, review and learn from them. Have a bias towards such learning and the use of data.

A bias towards action
This is best explained through the word's or Rimmer's Study Habit (an episode from Red Dwarf).

"The first weeks of study, he would always devote to the construction of a revision timetable. Weeks of patient effort would be spent planning, designing and creating a revision schedule which, when finished, were minor works of art.

Every hour of every day was subdivided into different study periods, each labelled in his lovely, tiny copperplate hand; then painted over in watercolours, a different colour for each subject, the colours gradually becoming bolder and more urgent shades as the exam time approached. The effect was as if a myriad tiny rainbows had splintered and sprinkled across the poster-sized sheet of creamwove card.

The only problem was this: because the timetables often took seven or eight weeks, and sometimes more, to complete, by the time Rimmer had finished them the exam was almost on him. He'd then have to cram three months of astronavigation revision into a single week. Gripped by an almost deranging panic, he'd then decide to sacrifice the first two days of that final week to the making of another timetable. This time for someone who had to pack three months of revision into five days"

Do not attempt to create the perfect map. Have a bias towards action because the landscape will change and you will discover more through action. You learn by playing the game.

Listen to your ecosystems
There are many different forms of ecosystems and ways to exploit them. These can be powerful sensing engines (e.g. the ILC model) for future change as well as sources of co-operation with others along with defensive and offensive alliances. But ecosystems need management, they need tending as a gardener tends a garden - sometimes you allow them to grow wild, sometime you harvest, sometimes you help direct or constrain them. These are particular skills that you can develop but most important is the principle - listen to them.

A bias towards the new
Whatever you do will evolve. So have a bias towards the new, be curious and take appropriate risks. Be willing to experiment.

Be the owner
Take responsibility for your environment, your actions within it and how you play the game. You could outsource this to a third party in the way a chess player could outsource their gameplay to another but you won't learn and it is still you that loses.

Strategy is iterative not linear
Understand that strategy is iterative. You need to adapt in fast cycles according to the changing environment. The best you can hope for is a direction, a constant process of learning and improvement of your gameplay along the way.

Do better with less
Have a bias towards continual improvement.

Set exceptional standards
Don't settle for as good as or slightly better than competitors. Always strive for the very best that can be achieved.

Strategy is complex
There will be uncertainty, emerging patterns and surprises along the way. That's the very nature of competition due to the involvement of other actors. Embrace this, don't fall for the temptation that you can plan the future. What matters is not the plan but the preparation and your ability to adapt.

Commit to the direction, be adaptive along the path
Once you've set a direction commit to it. There will often be hurdles and obstacles but don't just simply abandon a direction because a single step is challenging. Try to find paths around the obstacles. If you're building a system and a common component is not as expected then that can often prove a market opportunity.

Move fast
The speed at which you move around the cycle is important. There is little point implementing FIRE like principles in developing a system if it takes you a year to make decision to act. An imperfect plan executed today is better than a perfect plan executed tomorrow.

There is no core
Everything is transient, whatever you think is core to your company won't be at some point in the future. The only things that are truly static are dead.

Exploit the landscape
Use the landscape to your advantage, there are often powerful force multipliers. You might decide not to take advantage of a competitor or a change in the market but that should be a conscious choice.

Think big
Whilst the actions you take, the way that you organise and the focus on detail requires you to think small when it comes to inspiring others, providing direction and moral imperative then think big. Your purpose is not to defend the narrow pass of Thermopylae but instead to defeat the Persian army and save the Greek states.

Be humble
Listen to others, be selfless, have fortitude and be humble. Inspire others by who you are and what you do. There are many ways to manipulate the landscape e.g. through marketing, persuading others that what is a commodity is somehow different or that a product is unique to them. But these manipulations come with a cost not just externally but internally. We can start to believe our own hype, our own infallibility and our "right" to the market.

As with climatic patterns, the more you play the game then the more forms of doctrine you’ll discover. It's important to learn these continuously, so get used to using maps as a retrospective. Look for what has changed and always ask why?  Of course, knowing about doctrine is not enough — you’ll want to apply it. Don't pick and choose, apply them all. When it comes to applying doctrine then there are three basic cases:- the map solves doctrine for you (e.g. having a common language), you can use many maps to apply doctrine (e.g. use of multiple maps of different lines of business to reduce duplication and bias) or you can apply doctrine directly to a map (e.g. cell based structures, cultural forms such as pioneer — settler — town planner) as shown in figure 159.

Figure 159 - Apply doctrine

Step 5— Learn and use gameplay
The other class of choice is context specific. You will learn there exists many approaches that you can deployed in order to influence the map. These approaches depend upon the map and the position of pieces within it i.e. they are not universal and you have to learn when and where to use them. To get you start, some basic from of gameplay (often called stratagems) are :-


Open approaches
Whether source or data or practice, the act of making something open reduces barriers to adoption, encourage collaboration and accelerates the evolution of the component.

Intellectual property rights (IPR) can be used to slow evolution by limiting competition even to the point of ring fencing a component making it difficult for others to evolve it further.
Fear, uncertainty and doubt
Often used to slow evolution by exploiting inertia to change within customers and forcing new entrants to divert energy away from the components and into countering the accusations.

Exploiting constraint
An existing constraint can be exploited to fragment a single player by increasing demand beyond their ability to supply (e.g. by creating a price war).

Sweat and Dump
A mechanism of disposing of legacy liability onto a third party by exploiting their own inertia to change.

Pig in a poke
A mechanism of dressing up a liability as some form of future business before divesting to a third party.

Two factor markets
A mechanism of bringing providers and consumers together and exploiting network effects and aggregated data

Sensing Engines (ILC)
A mechanism of being the first mover to industrialise a component, allowing others (the ecosystem) to build new industries upon it and then using consumption data to determine future candidates for industrialisation.

As with climatic patterns and doctrine, then the more you play the game then the more context specific patterns you will discover.  With your understanding of the landscape, an ability to anticipate change based upon climatic patterns and a knowledge of context specific play that you can use to manipulate the map then you should be able to determine where you could attack and how you can use gameplay to increase your odds of success. At the very least, you should be able to create a common understanding of where we're going and why we're taking certain approaches within the company - see figure 160.

Figure 160 - Applying gameplay

You then decide to act. You loop around the cycle and repeat this whole exercise. Don't hesitate with action, make your plans and roll the dice. It’s worth remembering that one of your actions maybe to change direction of the company itself, to alter your very purpose. You might start of as a paper mill but you might become a telecommunications company. Get used to it, there is no “core” to a company beyond short term immediate focus.

A few things to remember

1. The map is constantly changing. These are living documents. With practice it should take a few hours to map a business from scratch and these have to adapt as you discover more. This is relatively simple if they become embedded as a means of communication.

2. Maps are a means of learning about the environment and communicating this. It’s an iterative process and it will take you years to become good at it. The really important lesson about maps is not how accurate or perfect they are but how you use them to continuously learn.  Maps are not the “truth” but a guide which an entire army can collaborate and communicate around.

3. All models are wrong, some are merely useful. Someone will produce a more useful method of mapping, a better list of doctrine, a more insightful set of patterns.

You are now ready. So let us now play the game with the scenario in the next chapter.


Next Chapter in Series : The Scenario
GitBook link [to be published soon]
More on mapping from the Leading Edge Forum.
First in series.

This post is provided as Creative commons Attribution-ShareAlike 4.0 International by the original author, Simon Wardley, a researcher for the Leading Edge Forum.