In this chapter, I’m going to introduce some basic concepts that we will use and expand upon when exploring the issue of strategy itself. These concepts include stepping stones, use of policy, nature of capital and finding a balance.

Stepping stones

Manipulating the environment to your advantage is the essence of strategy. In the case of Fotango, we understood our competitive environment and that we were losing the battle in the online photo service business. We were losing this external battle because we had to focus internally on our parent company’s needs and that absorbed what little resources we had for investment. Alternative services such as Flickr were rapidly dominating the space. Any differential we had with the service was in image manipulation but being a relatively novel act and uncertain we had no way of foretelling its future. We certainly were unable to predict the rise Instagram and what would happen next, this was 2005. We were also aware that our existing business with the parent company would eventually be caught up in their outsourcing efforts. In other words, I was losing the external battle and would eventually lose the internal one.

The strategy game starts with being honest with yourself. You’re not going to improve if you believe everything is perfect despite the evidence. If you accept this, then even failure provides an opportunity to learn. Strategy is all about observing the landscape, understanding how it is changing and using what resources you have to maximise your chances of success. Obviously, you need to define what success is and that’s where your purpose comes in. It’s the yardstick by which you currently measure yourself. However, as this is a cycle, your very actions may also change your purpose and so don’t get to stuck on it. Ludicorp was once a failing online video game company that shut down its Neverending game in 2004 and became a massively successful online photo service known as Flickr. It’s worth noting that after Flickr, the founder Stewart Butterfield then went on to create another online video game company — Tiny Speck. Its game, known as Glitch, was shut down in 2012. As with Ludicorp, the founder had once again singularly failed to deliver on the promise of a huge online video game but in the process of doing this for a second time, he had also created Slack which is now a massively successful company valued in the billions. If Stewart had “stuck to his purpose” or “focused on the core of online video games” then we probably wouldn’t have Flickr or Slack and we’d all be the poorer for it.

Back to Fotango, I knew we had to act. We needed to free up resources and find a new path. I knew that such action would have to create a new purpose for the organisation in order for us to have a future. I didn’t now how much time I really had, how much political clout I could use to hold back the wolves nor even what it was we were going to do. Somehow, we needed to find a way to flourish as the unwritten purpose of every organisation and of every organism is always to survive. Using our maps, we determined that creating a utility platform or infrastructure play was the best option as there were established product markets, these markets were suitable for utility provision and incumbents would have inertia to change. Both approaches would not only enable us to build a new business but free up capital through more efficient use of resources in our existing business. However, infrastructure itself was capital intensive and despite our profitability we had imposed constraints from capital expenditure to being both profitable and cashflow positive each and every month.

However, I gambled that if we believed the market was about to change then others would see the same. Some new entrant such as Google would play the infrastructure game. If they launched such a play, we could then exploit this by building our platform on top rather than just consuming our own infrastructure. The timing was going to be critical here. We could make enough savings from our existing business through the provision of our own utility infrastructure environment to initiate our own public platform play. To grow the new business quickly, we would need someone else to make that big infrastructure play or else constrain our own platform growth to a manageable level. I had talked to the rest of the board, highlighted this future trillion-dollar market opportunity and bought enough slack (or rope depending upon your point of view) to do it anyway.

The PaaS play (what you would call Serverless today) also suited our capabilities because we had the skills required to build a low cost, large-scale distributed architecture. This would also act as a barrier to entry for others. The nagging question was who would trust this online photo service for their coding platform? By open sourcing the PaaS technology itself (Zimki) we planned to overcome many of the adoption fears and rapidly drive towards creating a standard. If we were lucky then others would set up as Zimki providers (offering their own PaaS play). This suited us because our ultimate goal was not to be a PaaS provider but to build the exchange, brokerage and assurance industries on top of this. We had used maps to extend far beyond the obvious and speculate at what was coming next. The PaaS play was simply our beach-head. Our strategy was developed from our map and our understanding of it. We would use both the landscape and our capabilities to our advantage to the best of our understanding.

We launched, and shortly after Amazon (not Google) launched an infrastructure service known as EC2. We didn’t care who it was as we were over the moon. We positioned our platform to build upon Amazon’s infrastructure, we rapidly grew and then we were shutdown (in 2007). The parent company’s outsourcing plan overtook my own. They did not believe in this space, this purpose. The future to them was not cloud and I had miscalculated. I had enough political capital to get started but nowhere near enough to stop the outsourcing change. I tried the usual routes of management buy-out even VC funding but the asking price was either too high, the VC too focused elsewhere or just too skeptical. You have to remember, this was between 2006 and early 2007. Investors wanted to hear web 2.0, collective intelligence and user driven network effects. Terms like “compute utility” and “coding platform” were just not “something we’d invest in”. There were exceptions, such as BungeeLabs but as one investor told me “Wrong approach, wrong technology and wrong place. No-one has ever heard of a successful tech firm from Old Street, London”. It was a cutting point but fair enough, we were operating in a barren land with the barest whiff of tech companies and good souls. This was a long way from the heartland of Silicon Valley though of course, Old Street these days is known as Silicon Roundabout.

The crunch then came, and I had choice. Dismantle the service and the team, take a cushy number within the parent company or resign. I decided to take the hit. Cloud became that billion-dollar industry and Serverless will grow far beyond that, realising that trillion-dollar dream. If you’re reading this and that hasn’t happened yet then you still might not agree. Just wait. This story has its uses. When we consider mapping, there are multiple methods to use them to create an advantage or an opportunity. For example : -

Method 1) You can use a map to see how components that are evolving can be combined to create new activities or to support your own efforts. If what you’re doing is focusing on building something new in the uncharted area of the map then you should note that whatever you do will be risky — it’s the adjacent unexplored, an unknown area. In figure 246, I’ve given an example in the mobile phone space where each higher order system combined underlying components with more industrialised technology. The map assumes a timeframe of the early to mid 2000s, obviously these components have evolved since then. The play of combining industrialised components to expand into the adjacent unexplored with some new higher order activity is a high-risk stepping stone. You don’t know what you’ll find nor where it could lead next. It might be the next best thing since sliced bread but the past is littered with failed concepts. The problem with figure 246 is we always look back from the perspective of today and highlight the path by which success was achieved. There were other ideas such as phones integrated with projectors, printers, firearms, umbrellas, clothing and even into a tooth that have all been, gone and quickly forgotten.

Figure 246 — Combination Plays

In our case, we used our maps to anticipate future developments including exchanges, assurance reporting, application marketplace, billing facilities and a brokerage service.

Method 2) Beyond removal of duplication and bias, you can also use a map to find efficiencies and constraints by examining links within the value chain. For example, take something as trivial as a desktop role out. You might find that you’re forced to treat the operating system as more of a product than a commodity because some essential business application is tightly coupled to the operating system. By understanding and breaking this link, such as forcing the application into a browser, you can often treat a wide number of other components as a commodity. From our position, we understood that building data centres would be a constraint to building an IaaS play and that infrastructure was a constraint to building a PaaS. This also created opportunities i.e. if one player launched in IaaS and became dominant then competitors could launch equivalent services and use a price war to force up demand beyond the ability of the first mover to supply (this assumes that competitors had their wits about them). Given we had the underlying infrastructure technology known as Borg to do this, we could exploit such an opportunity.

Method 3) Another way is to take advantage of both evolution and inertia itself e.g. by driving any component to a more evolved state such as from product to commodity. These are potential goldmines hence I tend to look at those components that are described as being in the product stage but are close to becoming a commodity. I look for those four factors (concept, suitability, technology and attitude) to exist in the market. I even double check by asking people. The problem here is that people who work in that space often have inertia to this idea and will tell you endless reasons why it won’t work and this or that thing can’t become a commodity. You want that inertia to exist because then all your competitors will have that inertia and equally dismiss the change but you also wanted to get to the truth of the matter. The question becomes how do I find out whether it’s really suitable for a shift to commodity when almost everyone in the field will tell me it isn’t because of inertia? To find out if something is viable, I cheat. I find a group of people familiar with the field and ask them to imagine we have already built such a service. I then ask them to write down exactly what it looks likes and what it would need. The modern way of doing this is to get them to write the press release. If they can do this clearly, precisely and without recourse to hand waving then we’ve got something widespread and ubiquitous enough to be suitable for an industrialised play.

Whichever method you use, aim to make this a stepping stone to a further play. For example, in the case of Zimki then:-

• creating a utility service in the platform space and exposing it through APIs was a stepping stone towards running an ILC (ecosystem) like game.
• open sourcing Zimki was simply a stepping stone to achieving an exchange with many providers.
• the play to open source Borg (our underlying infrastructure system) was a counter play against any one competitor becoming dominant in the IaaS space.

This idea of future possibilities through stepping stones is an important concept within strategy. If we look at the first method again (i.e. banking on recombination efforts in the uncharted space) then this is often a bad position to find yourself in. More often than not it leads to a dead end — the phone firearm or the phone tooth. I tend to refer to these high risk approaches as “gambling” rather than “opportunities” because opportunities should expand your future possibilities and not reduce them. If you’re going to gamble then the only way to consistently make this work is to be lucky. Try instead not to gamble as much as focus on expanding future possibilities. Just because you could do something, doesn’t mean you should do it. Strategy is as much about saying what you won’t do as it is about what you will do. This is summed up in the highly mischievous phrase “opportunities expand as they are seized” which is often misinterpreted as “grab everything” which is precisely not what you should be doing. This is also why Fotango pivoted from a declining online photo service to a platform play, as it expanded our possibilities. See also Stewart Butterfield who seems to have become a master of such pivots. This doesn’t however guarantee success as these are opportunities and not certainties.

Policy or technology?

Through-out this book, I’ve heavily relied upon examples from the technology industry. The reason for this is that information technology has been undergoing profound change in the last decade. If it had been the legal industry that had been impacting so many value chains (though there are past examples of industrialisation with will-writing and current trends for general purpose contracts through AI) then this book would have mainly focused on the legal industry. Despite this technology industry focus, most of my work tends to deal with nation or industry level competition and touches upon areas of policy. The concepts of strategy, mapping and finding opportunities apply equally well in this space. Remember your map is not just activities but includes practice, data, knowledge and all forms of capital (including social).

Scenario — first pass.

Since Brexit is very much the talk of the town, I’m going to focus on one specific area namely that of standards. However, I’m not going to start with a UK centric view but instead let us pretend you’re a regulator in some mythical country. Your role is covering the pharmaceutical industry e.g. you’re working for the Office of Compliance within an administrative body (i.e. equivalent to the Food & Drug Administration, USA). Your purpose is to shield patients from poor quality, unsafe, and ineffective drugs through compliance strategies and risk-based enforcement actions. To this end, you use strategic and risk-based decisions that are guided by law and science to foster global collaboration, promote voluntary compliance and takes decisive and swift actions to protect patients. It’s exciting and noble sounding stuff! Well, it should be as I lifted those words from the FDA website. But why do you exist? You exist because bad medicines kill people and those people tend to be voters. Any Government knows that being in charge and doing nothing when people are dying doesn’t tend to win elections in a democracy. There are no positives about bad medicines and there’s no way to spin this.

When something goes wrong then you need to investigate and take action (often legal enforcement). In light of this, you tend to do audits of facilities and enforce compliance to standards which you also develop. But there’s a problem. The pharmaceutical industry is a global and complicated supply chain. The drugs in your local chemist shop probably were delivered through a series of warehouses and transportation systems (facilities) with plenty of opportunities for things to go wrong. Before this it was manufactured (in another facility) with the active / inactive components being chemicals which themselves were delivered through a series of warehouses, import/export, transportation systems and manufacturers. Even the raw material to make the chemicals can come through another set of facilities which can include refiners and miners. The supply chain can be very long, very complicated and provides many points where disaster can be introduced. It’s also global and when you cross international borders then you have no guarantee that the standards which you apply are also the standards that are in practice applied elsewhere. Which is why you, as a regulator, probably push for global standards and close co-operation with other agencies. You work with other nations to develop supply chain toolkits covering good manufacturing practice, transportation practice, product security to track & trace.

Let us assume you have brought in legislation which demands that pharmaceutical companies must know their supply chain i.e. we want the origin, history and interactions of every component that went into the drug. Let us also assume that some companies don’t see the benefit of exposing their supply chain but instead see cost beyond a one up, one down approach i.e. they know the boundary of their suppliers — we bought this from them — and who they supplied their products to. From a regulatory viewpoint whether pharma, automotive, consumer goods or any other then this is not enough especially when the supply chain crosses an international boundary. We could attempt to introduce legislation that they must know about the entire supply chain but this will invoke potentially huge lobbying bodies against us. At this point, someone normally shouts a technological solution such as “use blockchain” to create a chain of custody. Beyond the issue of implementation, the idea of a public blockchain is normally faced with criticism that being public it would expose the sales of the company to competitors. Often, there is a push to modify the idea and make it private. Such a private chain would in itself create a new hurdle for new entrants trying to get into an industry and whilst barriers to entry might be welcomed by some companies to reduce competition, the purpose of regulators didn’t include “protect incumbents from competition”. It’s a thorny issue. How to protect the public but allow for competition?

Part of the problem noted above is the inertia to having a publicly visible global supply chain whether using blockchain or not. It is amusing that if you ask executives within the industry whether they know what their competitors are selling they will often answer “Yes”. There is an entire industry of marketing, competitor analysis and surveillance companies that everyone feeds in order to gain competitive intelligence on what others are doing. In fact, so complicated is the internal supply chain of gigantic manufacturers that when combined with discounts, promotions, variability in production, fraud, returns and even error within their own internal systems then sometimes companies can only approximate what they’ve sold. One executive even told me that they knew what their competitors were selling better than they knew what they were selling themselves hence they had also started to use a marketing analysis company on their own company. An argument for radical transparency is to simply recognise this (i.e. be honest) and eliminate the cost of such competitive intelligence by making the blockchain open. However, this also threatens to expose the inefficiencies, waste and practices within the supply chain which is probably where the real inertia exists. The problem with exposing waste is that it doesn’t tend to go down well with either customers or shareholders. Let us assume this is the scenario in our case. First thing I want you to do is to take 30 minutes and come up with ideas of how you will solve all of this?

Scenario — second pass

So, how do you as a regulator manage this? Well, let us start with a map. I provided the map in figure 247 and will give a brief explanation underneath.

Figure 247 — Regulator’s Map

From the map, we start with the industry itself. It has a need for investors (i.e. shareholders) which involves a bidirectional flow of capital e.g. investment from the shareholders and return on investment to the shareholders. I’ve simply marked this as a “$” to represent a financial flow in both directions. Remember each node (circle) is some form of stock of capital (whether physical, practice, information or otherwise) and each line is a flow of capital. In order to pay for the return on investment (whether dividends or share buybacks) the industry needs to do something that makes a profit. This involves making the DRUG which in this case I’ve described as a quite well evolved product. Obviously, in practice there is a pipeline of drugs (from the novel and new to the more commodity) but this map will suffice for our purposes.

To make a profit on the drug then there are costs in making it and hopefully revenue from selling it. Our drug therefore needs consumers. Hence we have a bidirectional flow of capital with consumers i.e. the physical drug is exchanged for monetary $. Now, those consumers also want the drug not to kill them and hence they need standards that ensure (as much as it is possible) that the drug is safe. Those standards add to the cost of the drug i.e. certification to a standard doesn’t come for free. Let us assume that if our industry could get away without standards, they probably would as such costs reduce profits which the industry needs in order to pay the return to shareholders. Fortunately for those consumers, someone else needs them. That someone is the Government and what it needs are voters. These voters just happen to be also consumers. Hence in order to gain its voters the Government has a need for regulators who in turn create and police the standards that satisfy the needs of the consumers. Naturally, standards without enforcement is worthless and hence the regulators use audits which in turn use legal enforcement against the drug itself. This gives the industry two costs. The first cost is that of implementing the standard which is usually a bidirectional capital flow of investment in standards for a certification that the drug meets the standard. The second cost is the cost of legal enforcement i.e. a failure to meet the standard which can take many forms from court cases to product recall to enforced action.

But how are those audits conducted? In general, it is against the facilities involved whether this is the distribution point (i.e. the chemist shop), the warehouse, the transportation system or the manufacturer. Product can be taken from any of these points and tested or the facility inspected. Obviously, that involves a cost which in part is hopefully recovered from the standards process or at worst from taxes from the voters. You can simply follow the lines on the map (which represent capital flow) to determine possible ways of balancing this out. How you balance that out is a matter of policy.

At this point the map starts to become a little bit more complicated. For this map, I have considered all of the flows so far to be inside a border i.e. we manufacture and distribute within a single market (the dotted blue line border in our map). This could be a single nation or a multilateral FTA (free trade agreement) or a common market with agreed standards. Now let us look at the raw materials (another source of cost for the drug) and bring in the idea of import and export from outside of this market. This is going to bring into play a bewildering array of import & export arrangements, warehouses, manufacturers, transportation systems and an entire global supply chain. As per the scenario we have a one up, one down form of understanding within the industry and hence the global supply chain in all its details is poorly understood. Also, as per the scenario there is significant waste in these global supply chains. In general, from experience, I have yet to find one where there isn’t. Another problem is that outside of the common market then standards will tend to be specific to other countries. These might be more evolved than within the market but I’m going to assume for this exercise that they are less evolved, less developed hence the manner in which I’ve drawn standards on the map.

Our regulator has all the power it needs to enforce legislation on facilities within its market, but it wishes to gain access to information related to the global supply chain. It wants to make these supply chains both more clearly defined and transparent. It also wants to bring standards in the outside market upto its own level and ideally increase co-operation with other countries. However, both efforts will face inertia i.e. resistance to change and extensive lobbying if we attempt to do this trough legislation. The inertia over global supply chains will normally be disguised as competitive reasons (fear of exposing information to competitors) but it is usually related to cost and fear of exposing the waste that exists. The second case of inertia includes resistance from other nations and their regulators to any imposition of standards by another party. Sovereignty is a big deal for lots of people. So, considering your ideas from the first pass at this scenario, take another 30 minutes and come up with what you would do and try to avoid “use a blockchain”. Think of non technical opportunities i.e. policy.

Scenario — my answer

One of the beauties of maps is that I can describe a space and what I intend to do about it, allowing others to challenge me. Now, I’m no regulator but I can propose a solution. It might be a dreadful solution, there might be far better ways of doing this, the map could be more accurate but that’s the point. Maps are fundamentally about communication. It’s also important to note, that every choice you make (if you have a map) can be reviewed in the future and learnt from. Mapping itself isn’t about giving you an answer, it’s about helping you think about a space and learn from what you did. You won’t get good at mapping or strategic play if you don’t either act or put the effort into understanding a space before you act and review it later. It’s a bit like playing a guitar — there’s only so much you can read from books, eventually you have to pick up the instrument and use it. This is when you really start learning.

Hence I’ll give you my answer which took about thirty minutes but on the provision that we all understand that many of you will have a better answer. If you shared those maps with me, then I might learn (something I’d appreciate). Let us start with a map on which I’ve marked my play (see figure 248) and I’ll go through my reasoning after.

Figure 248 — My answer

I have two parts to my answer. The first (marked as number one in red circles) is to open up the data, practice and systems that I use to build and manage standards to other countries. The reason for this is that I want to drive standards to a globally accepted norm and make it as easy as possible for other nations to learn from our experience and reduce cost. In return for such a generous gesture, I’m aiming to “buy” both ease of use and interaction when dealing with other country agencies including good co-operation through a hefty element of goodwill. By opening it all up, I’m also carefully avoiding trying to impose any standard but instead encourage adoption. I might have invested in building those systems (i.e. invested financial capital in activities, practices and data) as a Government but I’m trading that capital for data and social capital from others.

The second part of my play (the red number two) is to name and shame. I would aim to deliberately undertake a campaign of highlighting waste in global supply chains and the poor understanding that companies have over their actual supply chain. This will involve us working with other countries to understand the supply chain hence another purpose to step one. I’m going to direct this campaign towards shareholders and customers in order to create pressure for change despite the inertia that executives within the company might have. I don’t care how the industry solves the problem (they can use blockchain if they wish) but I’d intend to use policy to drive for a more open approach on global supply chains. The two parts are needed because having a global supply being transparent is useful but not as useful if the standards involved throughout the chain are similar or at least the details can be accessed. Now, you might fundamentally disagree with this approach and that’s fine. It might surprise you to discover that I’m not a regulator and have little to no idea about the current state of the pharmaceutical industry. Hence, the mythical company. But disagreeing is part of the purpose of a map. It exists to enable precisely these sorts of discussions by exposing the assumptions. However, it’s also important to note that action and strategy doesn’t have to involve specific technology (e.g. blockchain) but can instead be driven through policy. There is a tendency in today’s world to immediately jump for a technological solution when other routes are available e.g. frictionless trade doesn’t necessarily require magic smart borders.

The nature of capital and purchasing it.

A map of a competitive environment is simply a map of capital (i.e. stocks of physical, knowledge, data, social, financial and information assets) and flows between them. What a map also adds are the concept that those capital stocks have a position in a chain of needs and they are not static, they are moving (i.e. evolving) themselves. From the original evolution graph, then evolution is itself related to the ubiquity and certainty of the thing. The value of any thing is also related to certainty i.e. some things we’re more certain about and can precisely define a value because the market is defined, whilst other things we’re unsure of. This uncertainty is often embedded in a concept know as potential value i.e. when we say “this has potential value” we mean “this has an uncertain amount of future value” compared to the current market. Roughly speaking (and based upon an idea proposed by Krzysztof Daniel) then :-

What this is saying is that novel and new things that have a high potential value have inherently a lot of uncertainty around them. Hence all the risk in the uncharted space as we just don’t know what is going to happen despite our belief in some huge future potential value. As the market develops and more actors become involved because that market becomes more defined, then the uncertainty declines because of competition. But, so does the potential value as the current market is becoming more defined, divided and industrialised. In other words by investing in some activity (e.g. computing in the early days) then by simply doing nothing at all the value of that investment will change as the industry evolves through competition.

I said roughly for two reasons. Firstly, potential value itself implies uncertainty and hence the “equation” above breaks down to uncertainty is inversely proportional to certainty i.e. the less certain of something we are then the more uncertain we become. It’s the self referencing flaw of Darwin’s evolutionary theory and survival of the fittest. We define the “fittest” by those who survive. Hence evolutionary theory breaks down to survival of the survivors. This obvious circular reference doesn’t mean it isn’t useful. The second issue is the actual relationship between value and evolution isn’t simple. The value of an investment in an activity and its related practices and other forms of capital which we spend financial capital on to acquire (e.g. by training) doesn’t just decline with evolution. There are step changes as it crosses the boundary between different evolution stages. For example, a massive investment in computing as a product (e.g. servers, practices related to this and other components such as data centres) changes as compute shifts from product to utility. What was once a positive investment can quickly become a technical debt and a source of inertia. The act of computing might be becoming more defined, ubiquitous and certain but our past investment in assets can quickly turn into a liability.

In practice, the early adopters of one stage of evolution (e.g. buying compute as a product such as servers) can quickly find themselves as the laggards to the next stage of evolution (e.g. cloud) because of their past investment and choices. The same change appears to also happen up and down the value chain. For example, with serverless (a shift of platform from product to utility) then often the first movers into the world of cloud (i.e. utility infrastructure) and DevOps (i.e. co-evolved practice) exhibit the characteristics of laggards to the serverless world whilst some companies that many would describe as laggards to cloud are the early adopters of serverless.

These changes in the value of a stock are problematic because in accountancy and financial reports we rarely reflect the concept of evolution. At best, we use the idea of depreciation of some form of static stock but fail to grasp that the stock itself isn’t static. The balance sheet of a company might look healthy but can hide a huge capital investment that has not only been depreciated but is now undergoing a potential change in the stage of evolution e.g. data centres, servers and related practices that will quickly become a huge financial burden requiring massive investment, retraining and re-architecting.

The idea that suddenly an asset can become a liability due to a change of evolutionary stage in the industry is not one that fits well with double entry book-keeping. In other words Assets = Equity + Liability doesn’t work quite so well when Assets become Liabilities due to outside forces. It’s not that these things can’t be accounted for, it’s simply that we generally don’t. This is one of the dangers of looking at a company financials. We can often make statements on the market evolving and impacting revenue but less frequently consider the debt that a change in evolution can cause. This also is not something that should surprise us. Unless there are genuine constraints then with enough competitive pressure, all the technical/operational obstacles to evolution (the four factors of technology, suitability, attitude and concept) will be overcome and such changes will happen. It’s never a question of if but when.

However, it’s not just accounting methods that tend to be inadequate when it comes to evolution. As we’ve discussed at length, it’s also development methods and even purchasing techniques. In figure 249 below, I’ve provided a map of a system which starting from user needs is disaggregated into components through a chain of needs. This has in turn be broken into small contracts with appropriate methods applied. However, the method of purchasing is also context specific. In the uncharted space where items have high potential value combined with lots of uncertainty then a venture capital or time & material type approach is needed for investment. As the same act evolves and we start to develop an understanding of it with introduction of concepts like MVP (minimal viable product) then a more outcome based approach can be used. We’re still trying to mitigate risk but this time we have a targets and a rough goal of what we’re aiming for. As a product evolves we can switch to a more commercial off the shelf (COTS) type arrangement. Finally, as it becomes defined, we have a known market and are focused on a more unit or utility based pricing around defined standards and expectations.

Figure 249 — Capital and Purchasing.

The point of this is that not only does capital evolve (whether activities, practices, data or otherwise) but so does the means by which we should purchase it. In any organisation you need at least four different purchasing frameworks across the company. In any large complicated system, there isn’t such a thing as a one size fits all purchasing method and you’ll need to use multiple of these frameworks. Unless of course, you like things such as explaining massive change control cost overruns and trying to blame others. Maybe that floats your boat because it’s simple and at least the vendor provides nice conferences. Oh, and if you want to fry your noodle, the implications of the above is there isn’t actually one way of accounting for things. That field also happens to be context specific i.e. the way you account for things in the uncharted space (the genesis of the things) is different from how you account for commodities in the industrialised space. However, getting into discussions on different accounting methods — innovation accounting, the use of options, how we combine them — and attempting to upset the entire world of financial reporting is something that we’ll have to leave until much later on. Having written the global chart of accounts for one enormous multinational, I have a lot of sympathy for accountants.

Finding a balance

Whether it’s finding opportunities (i.e. stepping stones that expand your future possibilities), using policy to change the game rather than just technology or whether it’s the flows of capital within a system and how we account for or purchase it — these are all elements which we use in gameplay. There is also the issue of balance within the system i.e. inertia is both a good thing in terms of keeping you from industrialising an industry too early but a disaster if you haven’t effectively managed it when an industry is industrialising. In the same manner, an investment in some form of capital asset can rapidly become a liability as the space evolves. As you develop, you’ll learn to keep all of this in balance.

The maps themselves can help guide you but you’ll need to scenario plan around them. There are rarely simple answers. In the next chapters, we’re going to start going through a long list of specific patterns of play before we come back and break down an entire industry. To prepare you, I’ve listed the general forms of gameplay in figure 250. I’ve organised the table by broad category i.e. user perception, accelerators, de-accelerators, dealing with toxicity, market impacts, defensive, attacking, ecosystem, competitor, positional and poison. Each of the following chapters will deal with a single category (eleven chapters in total) using maps and where possible examples to demonstrate the play. By now, you’re probably ready and dangerous enough to start playing chess with companies or at least start learning how to do so.

Figure 250 — Gameplays.

The book so far

Chapter 1 — On being lost
Chapter 2 — Finding a path
Chapter 3 — Exploring the map
Chapter 4 — Doctrine
Chapter 5 — The play and a decision to act
Chapter 6 — Getting started yourself
Chapter 7 — Finding a new purpose
Chapter 8 — Keeping the wolves at bay
Chapter 9 — Charting the future
Chapter 10 — I wasn’t expecting that!
Chapter 11 — A smorgasbord of the slightly useful
Chapter 12 — The scenario
Chapter 13 — Something wicked this way comes
Chapter 14 — To thine own self be true
Chapter 15 — On the practice of scenario planning
Chapter 16 — Super Looper
Chapter 17 — To infinity and beyond
Chapter 18 — Better for Less
Chapter 19 — On Playing Chess

This post is provided as Creative commons Attribution-ShareAlike 4.0 International by the original author, Simon Wardley.

Simon’s site and other writings https://www.swardleymaps.com/
EPUB and PDF versions https://www.swardleymaps.com/writings-books#wardley-maps

Originally published at blog.gardeviance.org on March 7, 2018.

On playing chess was originally published in wardleymaps on Medium, where people are continuing the conversation by highlighting and responding to this story.

All change please

In early 2009, I met Liam Maxwell. That name might not mean much to you unless you work in Government but he has been an influential figure in government technology throughout the world, a strong advocate of mapping and a good friend since that first encounter. We met when I was speaking at some random conference in London on evolution and technology. By happenstance Liam was in the audience. We got chatting and discovered we had common interests and ways of thinking about technology. I was soon invited to the “Triple Helix” group which consisted of a motley crew of interesting people — Jerry Fishenden, Mark Thompson and others. They wanted to try and help fix problems they saw in Government IT. It was a non-partisan group i.e. many of us came from different political backgrounds.

For myself, I felt completely out of my depth. This was “big IT” as in huge projects with hundreds of millions spent on massive scale systems that I had usually only heard about because of some failure hitting the mainstream press. There were also big personalities. I met Francis Maude (he was in the opposition Cabinet at the time) which mainly consisted of me trying not to mumble “you’re Francis Maude” given I was a bit awestruck. What on earth was I, a state school kid who had lived on a council estate doing in the Houses of Parliament talking to people I’d seen on TV.

I was also introduced to various departments who kindly offered to give me an hour or so explaining how “big IT” happened. What I saw shook me but then I hadn’t really seen “big IT” in the commercial world having mainly built companies or worked for moderate sized groups. The first, and most obvious thing, I noted was the lack of engineering skills despite the scale of these engineering projects. I would be introduced to engineer after engineer that in effect turned out to be a glorified project manager. The answer to everything seemed to be “outsource it”, a mantra that had been encouraged by hordes of management consultants. I tried to explain how this would inevitably lead to cost overruns because some components would be novel but usually got an answer blaming poor specification. It seemed that no matter how many times a project failed, the answer was “better specification” or “better outsourcing”. This was dogma run wild. I became increasingly aware that these groups were not only dependent upon the vendors but many lacked the skills necessary to challenge the quotations given.

There was no concept of maps and no effective mechanism of communication, learning or sharing. Everything was isolated. Duplication was rife. Before anyone goes on about how bad Government is, let me be clear that this pales into insignificance compared to the inefficiencies and ineffectiveness of the private sector. I might have seen the same system rebuilt a hundred times in Government but in the commercial world, I’ve seen 350 separate teams of people rebuilding the same IT project in one organisation at the same time. Anything that the Government gets wrong, the private sector excels at showing how much more wrong is possible.

Anyway, Government was still a shock. There were some weak measures of cost control but barely any concept of price per user or transaction or user needs or anything that I had started to take for granted. There was one project that Liam asked me to guess the price on, I responded around £300k after looking through the details. It was north of £50m. I had real trouble wrapping my head around such figures but then I’ve seen a billion dollars spent on no-hope, obviously doomed to fail from the beginning efforts in the private sector. I’d always assumed there was some greater wisdom that I wasn’t aware of. It was becoming clear that this wasn’t the case. In Government, however this tended to make me annoyed. I don’t mind survival of the least incompetent in the private sector because eventually someone will come along and do a better job. In Government, there is no someone and getting things right is critical. I have family that live in social housing who would be horrified at the waste.

In between plotting Ubuntu’s dominance of cloud, I started to spend my spare time working with this group on writing the “Better for Less” paper. It had rapidly become clear that not only did Government spend huge sums on individual projects but that those projects had deplorable rates of success. “Only 30% of Government IT projects succeed, says CIO” shouts the May 2007 edition of Computer Weekly. How was it possible for projects to spend such inflated sums and fail so frequently?

The more I looked, the more I uncovered. This wasn’t a problem of civil servants and a lack of passion to do the right thing but instead a cultural issue, a desire to not been seen to fail which inevitably ended up in failure. The skills had been outsourced to the point that outsourcing was the only option with few left that could effectively mount a challenge. There was a severe lack of transparency. Getting the IT spend in Government to the nearest billion was nigh on impossible. The words “How can you not know this” seemed to constantly trip from my tongue. Shock had become flabbergasted.

Of course, the reasons why we were building things often seemed even more ludicrous. Most of the systems were being designed badly to fit legislation and policy that had barely considered their own operational impact. Any concepts of what users (i.e. citizens) might want from this was far removed. Interaction with citizens felt more of an inconvenience to achieving the policy. You should remember that I had spent five years running online services for millions of users. This policy driven approach to building IT was the antithesis of everything I had done.

To compound it all, the silo approach or departmentalism of projects had meant that groups didn’t even talk with each other. Whitehall had somehow developed an approach of creating and maintaining expensive, often duplicated IT resources that often failed but also didn’t interact with each other in effective ways. In 2003, I was used to web services providing discrete component services that were consumed by many other services. In 2005, I was used to mapping out environments with clear understanding of user needs, components involved and the potential for sharing. In 2010, whilst sitting in one of these department meetings, flabbergast became horror. I was looking at approaches that I hadn’t seen since the mid 90s and discussing policy issues with people that lacked the skill to make rational choices. Where skill did exist, the Government had bizarre stratifications of hierarchy which often meant the people who could make the right choices were far removed from the people making the choices. “Big IT” just seemed to be a euphemism for snafu and it was only “Big” in terms of cost, lack of solid management information and failure rates. When it came to the number of users served and performance it was decidedly “Average” verging on “Small”.

With Fotango, we had dealt with millions of users from our warehouse base in the technology desert (at that time) of Old Street. We used an open plan environment which brings its own problems, we used hack days, scrum meetings and town halls to counter communication difficulties. Despite our best efforts, our use of small teams and our small size it was inevitable that the layers of hierarchy and politics would impact communication. However, the scale of our communication issues was trivial compared to entrenched structures, politics and communication failures within these departments. The scale of the problems was “Big” even if the IT wasn’t.

The “triple helix” group needed to start somewhere, so we started with a basic set of principles.

Doctrine: Think big
We need to get out of the mindset of thinking about specific systems and tackle the whole problem. We needed to break away from these isolated individual systems. We needed to change the default delivery mechanism for public services towards online services using automated processes for most citizens. We needed an approached that focused relentlessly on delivery to the citizen and their needs. This was going to be the “Big” idea.

Doctrine: Do better with less
Such an approach had to be transparent and measured in terms of cost. It had to provide challenge for what was currently being built. From this we developed the idea of a scrutiny board which later became spend control under OCTO. It wasn’t enough to simply reduce spending; our focus was on dramatically reducing waste whilst improving public services. We couldn’t do this without measurement.

We understood that this would not be a big bang approach but an iterative process — a constant cycle of doing better with less. To this end, we proposed the use of open data with a focus on the Government becoming more transparent. We also added the use of open source including the practices associated with it and the use of open standards to drive competitive markets.

Doctrine: Move fast
We understood that there would be inertia to the changes we were proposing and that existing culture and structures could well rise to combat us. We put in place an initial concept of work streams that targeted different areas. The idea was that if we ever put this in place then we’d have 100 days or so to make the changes before resistance overwhelmed us. If it wasn’t up and running in that time then we would have missed our window.

Doctrine: Commit to the direction, be adaptive along the path
To enable the change, we needed a clear and effective message from authority combined with a commitment to change. However, in the past this has been notoriously difficult as only one minister in the Cabinet Office (Tom Watson MP) prior to 2010 had any real commitment to understanding technology. However, with a change of Government there might be an opportunity with a new ministerial team.

To support of all this, we proposed a structure based upon the innovate — leverage — commoditise model. The structure included innovation funds operating at local levels, a scrutiny board encouraging challenge along with a common technology service providing industrialised components. The structure was based upon concepts of open, it was data driven with emphasis on not just defining but measuring success. It was iterative and adaptive using constant feedback from the frontline and citizens alike. To support this, we would have to develop in-house capabilities in engineering including more agile like approaches. We would also need to build a curriculum for confidence and understanding of the issues of IT for mid ranking to senior officials and ministers. We would need take a more modular approach to creating systems that encouraged re-use. We would need to be prepared to adapt the model itself as we discovered more.

Doctrine: Be Pragmatic
We accepted that not everything would fit into the structure or work streams that we had described. A majority would and it was the cost reduction and improvement in those cases that would generate the most savings. However, it was important to acknowledge that a one-size fits all approach would not work and will be vulnerable to inertia. Pragmatism to achieve the change was more important than ideology. We also had to maintain the existing IT estate whilst acknowledging the future will require a fundamentally different approach based upon agile, open and effective local delivery. We would have to not only audit but sweat the existing assets until they could be replaced.

Doctrine: A bias towards the new
We focused on an outside-in approach to innovation where change was driven and encouraged at the local level through seed funds rather than Government trying to force its own concept of change through “big IT”. The role of central Government was reduced to providing engineering expertise, an intelligent customer function to challenge what was done, industrialised component services, encouragement of change and showing what good looked like.

Doctrine: Listen to your ecosystems (acts as future sensing engines)
We viewed the existing centralized approach as problematic because it was often remote from the real needs of either public service employees, intermediaries or citizens alike. We envisaged a new engineering group that would work in the field and spot and then nurture opportunities for change at the frontline, working closely with service delivery providers.

Though the bulk of the work of the “triple helix” group was completed sometime beforehand, Liam published the resultant paper “Better for Less” in Sept 2010. Whilst the paper is certainly not as widely known as Martha Lane Fox’s letter on “revolution, not evolution” it had some small impact. The ideas and concepts within the paper were circulated within Government and provided some support to structures that were later created whether spend control or the development of in-house engineering capability in Government Digital Services or the development of training programs. I occasionally meet civil servants who have read the paper or used its concepts. I can feel comfort in knowing that the work was not in vain but helped tip the needle. But I also discovered that I had made a terrible mistake in the paper. That mistake was assumption.

A little too much of what you wanted

With the transformation starting within Government IT, Liam had taken the role as CTO of HMG. I would occasionally pop in and discuss the changes, even meeting up with departments to review projects with part of spend control. I was often brutal, challenging the cost, the lack of customer focus and the endless attempts to specify that which was uncertain. It was during one of these discussions that I mapped out the space and used the map to show a particularly galling cost overspend and how a vendor was trying to lock-us in with ever increasing upgrade costs. Using the map, I pointed out to Liam how we could break this vendor’s stranglehold. He nodded and then said something very unexpected — “What’s that?”

What happened in the next five minutes was an eye-opening revelation to me. I had known Liam for some time, we had worked together on the “Better for Less” paper and discussed the issues of evolution but somehow, in all of this, I had never explained to him what my maps were. Whilst Liam could see the potential of maps, I was befuddled. How did he not know what these were?

I started talking with other CEOs, CIOs and CTOs and rapidly discovered that nobody knew what maps were. Even more shocking, despite my assumption that everyone else had their own way of mapping, it turned out that no-one did. It finally dawned on me that the incredibly wise senior executive in the Arts Hotel who had asked “Does this strategy makes sense” wasn’t testing me, he didn’t have a clue. But this question had sent me spiralling off on this journey (see chapter 1). It seemed it wasn’t just me who had been faking it as a CEO.

It was in 2013 that this revelation truly hit home. I was working for the Leading Edge Forum (a private research organisation) with access to the great and good of many industries and many Governments. I had undertaken a very informal survey of around 600 companies and concluded that only four of those companies had anything remotely equivalent to a map. In each of these cases, they were using mental models. The entire world was playing a game of chess without ever looking at the board. Suddenly, my success at taking over the entire cloud space with Ubuntu despite the wealth and size of competitors made sense. Their inability to counter my moves was simply due to blindness. The executives may have been paid million dollar salaries but they were playing snap in a game of chess.

Part of the problem with the “Better for Less” paper was I had assumed that everyone had some form of maps. Without these, it would be next to impossible to remove duplication and bias, to introduce challenge into the system and to apply the right methods. I had talked about spend control becoming the institutional seat of learning for Government but this wasn’t going to happen if nobody had maps to compare. I cannot underestimate how important that simple statement from Liam was. Without it, I could have carried on assuming everyone knew how to map for many more years. I owe Liam a great debt of thanks.

An Opportunity

In late 2013, I wrote a paper for the Cabinet Office called “Governance of Technology Change”. I used this paper to try to combat what I saw as a “tyranny of agile” and to introduce the ideas of continuous learning through maps. I already had a handful of examples where maps had proved useful in Government, such their use in the development of IT systems within HS2 (High Speed Rail) by James Findlay. These examples were few and far between. The problem within Government was a past tendency to one size fits all. Outsourcing was now being overtaken with a new and inappropriate one size fits all called agile. Without maps, it’s easy to fall into one size fits all trap. To show you what I mean, let us take a map for an IT system in HS2 and overlay the different methods, techniques and types of attitudes you would use — see figure 235

Figure 235 — High Speed Rail Map with overlaid techniques

By now it should be obvious to you how we need to use a changing landscape of multiple methods at the same time to manage a complex system such as this. However, imagine if you had no map. The temptation and ease at which a one size fits all can be used or replaced by another should be obvious. How would you counter an argument for using an agile technique to build an HR system given the success of agile in building a land registry system? They’re the same, right? This is what happens when context is lost. It is how you end up trying to outsource everything or agile everything.

Be warned, this path won’t win you many friends. I’ve been in conferences where I’ve got into raging arguments with people trying to explain to me that agile works everywhere. This is often followed by other conferences and raging arguments with people trying to explain that six sigma works everywhere. In both cases, they’ll often explain failure as “not doing it in the right way” or “using the wrong bits” and never that there exists a limit or context to the method. It’s no different with the “better specification” problem. The failure is always blamed on something else and not that specification, agile or six sigma shouldn’t have been used for those parts.

During my years of using mapping, the “use of appropriate methods” was just one of a long list of context specific gameplays, climatic (economic) patterns and doctrine (universally useful principles) that I had discovered through my use of maps. I turned to my list of doctrine to help write the “Governance of Technology Change” paper and to correct some of my failures in the original “Better for Less”. I used these principles to propose a new form of governance structure that built upon the work that was already done. The key elements of doctrine used were: -

Doctrine: Focus on high situational awareness (understand what is being considered)
A major failing of “Better for Less” was the lack of emphasis on maps. I had to increase situational awareness beyond simple mental models and structures such as ILC. To achieve this, we needed to develop maps within government which requires an anchor (user need), an understanding of position (the value chain and components involved) and an understanding of movement (evolution). To begin with, the proposed governance system would clearly reflect user needs in all its decision-making processes. The users included not only departmental users but also the wider public who will interact with any services provided. It was essential, therefore, that those users’ needs were determined at the outset, represented in the creation of any proposal and any expected outcomes of any proposal are set against those needs. But this was not enough, we needed also the value chain that provided those user needs and how evolved the components were. Maps therefore became a critical part of the Governance structure.

Doctrine: Be transparent (a bias towards open)
The governance system had to be entirely transparent. For example, proposals must be published openly in one place and in one format through a shared and public pipeline. This must allow for examination of proposals both internally and externally of Government to encourage interaction of departments and public members to any proposal.

Doctrine: Use a common language (necessary for collaboration)
The governance system had to provide a mechanism for coordination and engagement across groups including departments and spend control. This requires a mechanism of shared learning — for example, discovery and dissemination of examples of good practice. To achieve this, we must have a common language. Maps were that language.

Doctrine: Use appropriate methods (e.g. agile vs lean vs six sigma)
Governance had to accept that there are currently no single methods of management that are suitable for all environments. The use of multiple methods and techniques based upon context had to become a norm.

Doctrine: Distribute power and decision making
Departments and groups should be able organise themselves as appropriate to meet central policy. Hence the governance procedure should refrain from directly imposing project methodologies and structure on departments and groups and allow for autonomous decision making. Improvements to ways of operating could be achieved through challenging via maps i.e. if one department thought that everything should be outsourced, we could use their own maps to help them challenge their own thinking.

Doctrine: Think fast, inexpensive, restrained and elegant (FIRE)
Governance should encourage an approach of fast, inexpensive, simple and tiny rather than creation of slow, expensive, complex and large systems to achieve value for money. Any reasonably large technology proposal should be broken down into smaller components with any in-house development achieved through small teams. The breaking down of large systems would also help demonstrate that multiple methods were usually needed along with encouraging re-use. However, we would have to be prepared for inertia and counter arguments such as the “complexity of managing interfaces”. The interfaces existed regardless of whether we tried to ignore them or not.

Doctrine: Use a systematic mechanism of learning (a bias towards data)
The governance system must provide a mechanism of consistent measurement against outcomes and for continuous improvement of measurements. This is covered in chapter 6 and it is a primary role for any spend control group.

The paper was written and delivered in 2013. Unfortunately, I suspect in this instance it has gathered dust. The problem with the paper was familiarity. Many of the concepts it contained are unfamiliar to most and that requires effort and commitment to overcome. That commitment wasn’t there, the tyranny of agile continued and the inevitable counter reaction ensued. There was and is a lot of good stuff that has been achieved by Government in IT since 2010. The people who have worked and work there have done this nation proud. However, more could have been achieved. In my darkest and more egotistical moments, I suspect that had I not assumed everyone knew how to map then I might have been able to move that needle a bit more by introducing these concepts more prominently in the “Better for Less” paper. But alas, this is not my only failure.

Assumptions and bias

Assumption is a very dangerous activity and one which has constantly caught me out. In the past I had assumed everyone knew how to map but the real question is why did I think this? The answer in this case is a bias known as the false consensus bias. I tend to assume that if I know something then everyone else must know it as well. It’s the reason why it took me six years to discover that others weren’t mapping. It was also behind my assumptions in the “Better for Less” paper.

When it comes to bias with maps then there are two main types you need to consider. The first is evolutionary bias and our tendency to treat something in the wrong way e.g. to custom build that which is a commodity. By comparing multiple maps then you can help reduce this affect. The second broad and powerful group of biases are cognitive biases. Maps can help here but only through the action of allowing others to challenge your map. The most common and dangerous types of cognitive biases I have faced (and my description of these as “most common and dangerous” is another bias) are: -

Confirmation bias
A tendency to accept or interpret information in a manner that confirms existing preconceptions. For example, a group latching onto information that supports their use of some process being different from industry and hence justifying the way they’ve built it.

Loss aversion bias
The value of losing an object exceeds the value of acquiring it e.g. the sunk cost effect. Examples heard include “had we not invested this money we wouldn’t use this asset to do this”. Often a significant root cause of inertia.

Outcome bias
A tendency to look at the actual outcome and not the process by which the choice was made. Commonly appears in meme copying other companies when little to no situational awareness exists e.g. “we should be like Amazon”.

Hindsight bias
A tendency to see past events as being more predictable than they were. An example would be describing the evolution of compute from mainframe to client / server to cloud as some form of ordained path. The problem is that the “apparent” path taken at a high level depends upon how evolved the underlying components were (e.g. storage, processing, network). If processing and storage were vastly more expensive than network then we would tend toward centralization. Whereas if network was more expensive then we would tend towards decentralization.

Cascade bias
A belief that gains more plausibility through its repetition in public circles e.g. many of the false myths of cloud such as Amazon’s “selling of spare capacity”.

Instrumentation bias
The issue of familiarity and a reliance on known tools or approaches to the exclusion of other methods. Summarised by the line “If all you have is a hammer, everything looks like a nail.”

Disposition bias
A desire not to lose value i.e. selling of assets that have accumulated value but resist selling assets that have declined in the hope that they will recover. This is another common source of inertia through the belief that an existing line of business or asset acquired that is performing poorly will recover.

Dunning–Kruger effect
Tendency for the inexperienced to overestimate their skill and the experienced to underestimate.

Courtesy bias
A tendency for individuals to avoid giving their true opinion to avoid causing offence to others e.g. to not forcibly challenge why we are doing something especially when it is considered a “pet project” of another.

Ambiguity bias
A tendency to avoid uncertainty where possible and / or to attempt to define uncertainty e.g. to specify the unknown.

Survivorship bias
Only examining the data which achieves some end state rather than that which doesn’t. At the heart of mapping is a survivorship bias. The evolution curve (described in chapter 7) that is used as the basis of the x-axis of a map was built from data for components that had survived to become a commodity. It shows a path of “If a component evolves to a commodity then it will traverse through these stages”. But what about the components that didn’t survive? Unfortunately I was not able to distinguish another pattern to explain them other than to say they followed the path of evolution and died in one of the stages. Most visibly (because we can get access to data), components die in the custom built stage and I can only assume (because it’s nigh on impossible to get data) that the most common stage of death is genesis where there exists the highest degree of uncertainty. Of course, assumption is a dangerous thing.

Applying doctrine

So far in this chapter, I’ve covered various aspects of doctrine and the issues of bias and assumption. There is a reason to my madness. One of the most common questions I’m asked is which bits of doctrine should we apply first? The answer to this is, I don’t know.

Based upon my experience, I do believe (and that maybe bias) that there is an order to doctrine. For example, before you can apply a pioneer — settler — town planner structure (i.e. design for constant evolution) then you need to first implement other forms of doctrine. A rough order is: -

1. Start by understanding your user needs (i.e. focus on user needs).
2. Improve your understanding of the detail by describing the value chain needed to support your user needs (i.e. know the details).
3. Increase your situational awareness by creating a map of the environment. This is achieved by taking your value chain and adding in evolution to visualise how things change (i.e. focus on situational awareness).
4. Use your map to apply appropriate methods, to constrain the system into small contracts and to remove bias and duplication.
5. Convert the small contracts into a cell-based structure with autonomous teams (i.e. think small teams)
6. Apply appropriate attitudes to the teams, such as pioneer, settler and town planner, and introduce a system of theft to enable a system that copes with constant change (i.e. think aptitude and attitude).

Though we can deduce an order for some of the principles within doctrine, beyond broad strokes then I don’t know what bits of doctrine matter more i.e. is transparency more important than setting exceptional standards?

Alas, it will probably take me many decades to sort through this and obviously due to co-evolution effects then new practices and new forms of organisation will appear during that time. Hence doctrine is itself changing over time. This is one of those painting the Forth bridge situations which by the time I’ve finally sorted out an order, it has changed. However, I can take a guess on the order of importance based upon experience. I’ve split doctrine into a set of discrete phases which you should consider but at the same time, I want you to remember that I will be suffering from my own biases. So, take it with a big pinch of salt and don’t feel concerned about deviating from this. It is only a guide. My phases of doctrine are provided in figure 236.

Figure 236 — Phases of Doctrine

The phases are: -

Phase I — Stop self-harm.
The focus in this first phase is simply awareness and removal of duplication. What I’m aiming for is not to radically change the environment but to stop further damage being caused. Hence the emphasis is on understanding your user needs, improving situational awareness, removing duplication, challenging assumptions, getting to understand the details of what is done and introducing a systematic mechanism of learning — such as the use of maps with a group such as spend control.

Phase II — Becoming more context aware
Whilst phase I is about stopping the rot, phase II builds upon this by helping us to start considering and using the context. Hence the emphasis is on using appropriate tools and methods, thinking about FIRE, managing inertia, having a bias towards action, moving quickly, being transparent about what we do, distributing power and understanding that strategy is an iterative process.

Phase III — Better for less
I name this section “Better for Less” because in hindsight (and yes, this is likely to be a bias) there were some fundamental lessons I missed (due to my own false-consensus bias) in the original paper. Those lessons are now mostly covered in phase I & II. In this phase, we’re focusing on constant improvement which means optimising flows in the system, seeking the best, a bias towards the new, thinking big, inspiring others, committing to the path, accepting uncertainty, taking responsibility and providing purpose, master & autonomy. This is the phase which is most about change and moving in a better direction whereas the previous phases are about housekeeping.

Phase IV — Continuously evolving
The final phase is focused on creating an environment that copes with constant shocks and changes. This is the point where strategic play comes to the fore and where we design with pioneers, settlers and town planners. The emphasis is on constant evolution, use of multiple cultures, listening to outside ecosystems, understanding that everything is transient and exploiting the landscape.

Are the phases, right? Almost certainly not and they are are probably missing a significant amount of undiscovered doctrine. However, they are the best guess I can provide you with. There are two other parts of doctrine which I’ve glossed over. Both are worth highlighting. One is managing failure, the other is being humble

On the question of failure

When it comes to managing failure then life is a master. To categorise failure I tend to use CS Hollings’ concepts of engineering versus ecosystem resilience — see figure 237

Figure 237 — Types of Failure

Engineering resilience is focused on maintaining the efficiency of a function. Ecological resilience is focused on maintaining the existence of the function. In terms of sustainability then the goal of any organisation should be to become resilient. This requires a structure that can adapt to constant evolution along with many supporting ecosystems. Unfortunately, most larger organisations tend to be in the robust category, constantly designing processes to cope with known failure modes and trying to maintain the efficiency of any capital function when shock occurs i.e. constantly trying to maintain profitability and return to shareholders. Whilst efficient, the lack of diversity in terms of culture & thought means these organisations tend to be ill prepared for environments that rapidly changes outside of its “comfort zone”.

Doctrine: Be Humble

If we’re going to discuss bias and failure in the technology world then there’s probably no better example than Open Stack. It’s also one that I’m familiar with. When I was at Canonical, one of my cabal who helped push the agenda for Ubuntu in the cloud was Rick Clark. He is a gifted engineering manager and quickly picked up on the concepts of mapping. He is also a good friend. It was a year or so later that Rick was working for Rackspace. Rick and I had long discussed an open play against Amazon in the cloud , how to create an ecosystem of public providers that matched the Amazon APIs and force a price war to increase demand beyond Amazon’s ability to supply hence fragmenting the market. I was delighted to get that call from Rick in early 2010 about his plans in this space and by March 2010, I agreed to put him centre and front stage of the cloud computing summit at OSCON. What was launched was OpenStack.

My enthusiasm and delight however didn’t last long. At the launch party that evening, I was introduced to various executives and during that discussion it became clear that some of the executive team had added their own thought processes to Rick’s play. They had hatched an idea that was so daft that the entire venture was under threat. That idea, which would undermine the whole ecosystem approach, was to differentiate on stuff that didn’t matter — the APIs. I warned that this would lead to a lack of focus, a collective prisoner dilemma of companies differentiating, a failure to counter the ecosystem benefit that Amazon had and a host of other problems but they were adamant. By use of their own API they would take away all the advantages of Amazon and dominate the market. Eventually, as one executive told me, Amazon would have to adopt their API to survive. The place was dripping in arrogance and self confidence.

I tried to support as much as I could but nevertheless I had quite a few public spats on this API idea. In the end by 2012 I had concluded that OpenStack rather than being the great hope for a competitive market was a ‘dead duck’ forced to fighting VMware in what will ultimately be a dying and crowded space whilst Amazon (and other players) took away the future. I admire the level of marketing, effort and excitement that OpenStack has created and certainly there are niches for it to create a profitable existence (e.g. in the network equipment space) but despite the belief that it would challenge Amazon, it has lost. The confidence of OpenStack was ultimately its failure. The hubris, the failure to be pragmatic, its decision not to exploit the ecosystems that already existed and its own self-belief has not served it well. It was a cascade failure of significant proportions with people believing OpenStack would win just because others in their circles were saying so in public. Many would argue today that OpenStack is not a failure and the goals of supporting a competitive market of public providers were not its aim nor was it planning to take on Amazon. That is simply revisionist history and an attempt to make the present more palatable.

Yes, OpenStack has made a few people a lot of money but it’s a minnow in the cloud space. Certain analysts do predict that the entire OpenStack market will reach $5 billion in 2020. Even if we accept this figure at face value and this is for an entire market, AWS revenue hit $12 billion in 2016. The future revenue for an entire market in 2020 is less than half the revenue for a single provider in 2016 and growing at a slower rate? You’d have to stretch the definition to breaking point to call this a success hence I suspect the importance of a bit of revision. Nevertheless, the battle is a long game and there is a route back to the public arena through China where many better players exist.

You need to apply thought

One of the problems of mapping is people expect it to give them an answer. Maps aren’t a 2x2 where your goal is to get into some corner to win the magic prize. All maps do are help you understand the environment, challenge what you’re doing, encourage learning and the application of a bit of thought. There can exist all sorts of feedback loops for the unwary. For example, let us consider healthcare.

A question of healthcare

You have a Government that has needs including a need for people to vote for it, assuming it’s a democracy. Those voters also have needs one of which is to survive. In the case of medical conditions this requires treatment of which there is a pipeline of treatments. From once novel treatment such as antibiotics which have become highly industrialised to more novel treatments today such as CRISPR. Overtime, all these novel approaches evolve to become industrialised and other novel approaches emerge. Hence a pipeline. Obviously, such treatment has a cost hence we assume there is a budget for healthcare along with treatment centres. Now, let us assume the Government has decided to provide universal healthcare. Since this won’t be cost free then we will require some taxes. We can quickly map this up — see figure 238

Figure 238 — Map of Universal Healthcare

As maps go this is incredibly simplistic, missing a whole raft of stuff and could be significantly improved. But, I’m using this for an example and so it’ll do for now. Let us look at that map. We can certainly start to add financial figures for flow and we can start to question why are treatment centres not highly industrialised? Surely, they’re the same? However, let us add something else. We shall consider preventative care.

The Government has decided to introduce a preventative care program that voters are required or encouraged to attend. Obviously, there’s a budget impact (i.e. the spending on preventative care) but the good news is that through the use of preventative care we can reduce the overall volume of treatment (i.e. some diseases are preventable), thereby reducing cost and meeting the needs of patients to survive longer. Everyone is happy! Except, there’s a problem. Whilst the aim of reducing cost, providing a better service to more people and enabling people to live longer is a noble goal, the problem is that our people live longer! Unfortunately, what we subsequently discover is longer lived people incur increased treatment costs due to the types of disease they die from or the need for some form of support. There is feedback loop between preventative care and treatment, I’ve marked this up in figure 239.

Figure 239 — Healthcare Feedback

The problem we now face is a growing older population (due to the preventative healthcare we introduced) that requires increased treatment costs. What at one point seemed to be a benefit (preventative healthcare) has turned into a burden. What shall we do? Assuming we’re not some sort of dictatorship — we did need people to vote for us — and so the Viking ceremony of Ättestupa is out of the question, we need to somehow reduce the treatment costs. The best way of doing this is to accelerate the pipeline i.e. we want treatments to industrialise more quickly. To achieve this, we need more competition which could either be through reducing barriers to entry, setting up funds to encourage new entrants or using open approaches to allow treatments to more rapidly spread in the market. Let us suppose we do this, we set up a medical fund to encourage industrialization — see figure 240.

Figure 240 — Medical Fund

So, people are living longer but we’re countering any increased cost due to our approach of industrialisation in the field of medicine. Everyone is happy, right? Wrong. You have companies who are providing treatments in that space and they probably have inertia to this change. Your attempts to industrialise their products faster mean more investment and loss of profits. Of course, we could map them, use it to help understand their needs and refine the game a bit more. However, the point I want to raise is this. There are no simple answers with maps. There are often feedback loops and hidden surprises. You need to adapt as things are discovered. However, despite all of this, you can still use maps to anticipate and prepare for change. I know nothing about healthcare but even I know (from a map) that if you’re going to invest in preventative care then you’re going to need to invest in medical funds to encourage new entrants into the market.

I italicised the above because unfortunately, this is where a lack of being humble and the Dunning-Kruger effect can have terrible consequences. It is easy to be seduced into an idea that you understand a space and that your plan will work. Someone with experience of medicine might look at my statement on preventative care and medical funds and rightly rip it to shreds because I have no expertise in the space, I do not know what I’m talking about. But I can create a convincing story with a map unless someone challenges me. Hence always remember that all maps are imperfect and they are nothing more than an aid to learning and communication. They are not “right”.

A question of planning — OODA and the PDCA

The idea that we should plan around a forecast and the importance of accuracy in the forecast is rooted in Western philosophy. The act of planning is useful in helping us understand the space, there are many predictable patterns we can also apply but there is a lot of uncertainty and unknowns including individual actors’ actions. Hence when it comes to planning we should consider many scenarios and a broad range of possibilities. As Deng Xiaoping stated, managing the economy is like crossing the river by feeling the stones. We have a purpose and direction but adapt along the path. This is at the heart of the strategy cycle — Observe the environment, Orient around it, Decide your path and Act — and it is known as OODA.

At this point, someone normally mentions Deming’s PDCA cycle — plan, do, check and act. To understand the difference, we need to consider the OODA loop a little more. The full OODA loop by John Boyd is provided in figure 241

Figure 241 — OODA

There are several components that I’d like to draw your attention to in the orient part of the loop. Our ability to orient (or orientate, which is an alternative English version of the word) depends upon our previous experience, cultural heritage and genetic disposition to the events in question. In terms of an organisation, its genetic disposition is akin to the doctrine and practices it has.

Now, if an event is unknown and we’re in the uncharted space of the map then there is nothing we can really plan for. Our only option is to try something and see what happens. This is the world of JDI or just do it. It is a leap into the unknown and an approach of do and then check what happened is required. However, as we understand more about the space, our previous experience and practices grow in this area. So, whilst our first pass through the OODA loop means we just do and check, further loops allow us to start to plan, then do, check the result and act to update our practices. This is PDCA. As our experience, practices and even measurements grow then our decision process itself refines. We can concretely define the event, we can provide expected measurements, we can analyze against this and look to improve what is being done and then control the improvements to make sure they’re sustainable. This is DMAIC. The OODA loop can result in very different behaviours from just trying something out to DMAIC depending up how much experience and heritage exist with what is being managed i.e. how evolved it is and how familiar and certain we are with it. I’ve summarised this in figure 242.

Figure 242 — JDI to PDCA to DMAIC

A question of privilege

Whilst all plans must adapt, that doesn’t mean we can’t scenario plan and prepare for possible outcomes. Let us take another example, in this case the self-driving car. In figure 241, I’ve described the automotive industry in mapping form. We start with the basic user need of getting from A to B. We then extend into route management (i.e. doing so quickly), comfort and affordability. We also include status — a car isn’t just about moving from A to B, it’s also about looking good whilst doing so. From this we extend into a pipeline of cars with some more commodity like, especially in terms of features. I call out a couple of discrete parts from entertainment to infotainment systems and we continue down the value chain itself. You might disagree with the components and their position but that’s the purpose of a map, to allow this form of challenge.

Figure 243 — The automotive industry

However, that is a map for today or more specifically for 2015 when it was written. What we can now do is roll the map forward into the future. What emerges is a picture of self-driving cars (i.e. intelligent agents in all cars), an immersive experience (the Heads Up and Screen have been combined) and the vehicle itself becoming more commodity like, even potentially more utility like.

Hence you can think of a world in 2025 where increasingly we don’t own cars but pay for them on a utility basis. The cars are self-driving and increasingly immersive. The car that drives me to a meeting might have been the car that drives you to the theatre last night. However, using this map we can also see some other connections which we might not have considered before — see figure 244

Figure 244 — The automotive industry, 2025

First is the rising importance of design in creating the immersive experience (shown as red connection line). Second is the issue of status and that immersive experience. If the cars are the same we still have that need of status to be met. One way to achieve this is to have digital subscription levels e.g. platinum, silver and bronze and to subtly alter the experience in both immersion and the look of the car depending upon who is currently occupying. A standard bronze member might get adverts whilst a platinum member would be provided to more exclusive content. But that doesn’t really push the concept of status. The third addition is a link (in red) between status and route management. If a platinum member needs a car then they should be higher priority. But more than this, if you need to go from A to B then whilst you’re driving (or more accurately being driven) then lower class members can pull over into the slower lane. With human drivers that isn’t going to happen but with self-driving vehicles then such privilege can be automated.

Of course, there’d be reactions against this but any canny player can start with the argument of providing faster routes to emergency vehicles first (e.g. fire, ambulance) and once that has been established introduce more commercial priority. Later, this can be further reinforced by geo-fencing privilege to a point that vehicles won’t drive into geographies unless you’re of the right membership level. To many that will probably sound reasonable right up until the point that some future member of Government is facing the press after an environmental disaster (e.g. a flood) where all the wealthy people with the right digital status escaped quickly and most of the poor people were stuck in cars in long traffic jams. Embedding social inequality in transportation is going to happen (i.e. the market is foolish enough and Government is gullible enough) and it’ll lead to a lot of angry voters i.e. potential pitchfork holders.

Obviously, this sort of change has all sorts of knock on social effects and such reinforcement of privilege and the harm it could cause needs to be considered. Governments should scenario plan far into the future. However, the point of maps is not just help to discuss the obvious stuff e.g. the loss of licensing revenue to DVLA, the impacts to traffic signalling, the future banning of human drivers (who are in effect priced off the road due to insurance) or the impacts to car parks. The point of maps is to help us find that which we could prepare for. Of course, we can take this a step further. We’ve previously discussed the use of doctrine to compare organisations and the use of the peace, war and wonder cycles to identify points of change. In this case, we can take the automotive industry map rolled forward to 2025, add our weak signals for those points of war and try to determine what will rapidly be changing in the industry at that time. We can then look at the players in that market, try to identify opportunities to exploit or even looking at nation state gameplay.

In the case of the automotive industry, I’ve marked on the points of war that will be occurring (or would have just occurred) by 2025 and then added on the gameplay of China in that space. This is provided in figure 245. What it shows is that China is undergoing significant strategic investment in key parts of the value chain prior to these points of industrialization. It is also building a strong constraint based form of gameplay around raw materials by acquiring significant assets in this space. If you overlay the Chinese companies in the market and then run a similar exercise for the US then what emerges is quite surprising. Whilst many have assumed that this future will be dominated by US and Silicon Valley companies, it looks increasingly likely that the future of the self-driving car belongs to China.

Figure 245 — Automotive, points of war and gameplay

An exercise for the reader

We’ve covered quite a bit in this chapter from fleshing out various concepts around doctrine to the issue of bias to the question of failure and feedback loops to scenario planning. Some of these concepts we have touched upon before in previous chapters but then learning mapping is like the strategy cycle itself — an iterative process. Of course, practice matters.

First, I’d like you look at your organisation and go through figure 236. Work out which bits of doctrine you use and which bits you’re poor at or don’t exist at all. Using the phases as a guide, come up with a plan of action for improving doctrine.

Second, I’d like you to take one line of business and using a map push it ten years into the future. Think about what might happen, what feedback loops might appear and what opportunities you could exploit.

Lastly, since you’ve already compared yourself against doctrine, I’d like you to look at competitors for the line of business that you mapped into the future and examine their doctrine. Don’t limit yourself to existing competitors but think about who could exploit the changing environment and look at them. I want you to think about any bias you might have which will convince you they won’t be a threat. Also, if they did make a move then how resilient is your organisation to change? Do you have a diversity of culture, practice and thought that would enable you to adapt?

The book so far

Chapter 1 — On being lost
Chapter 2 — Finding a path
Chapter 3 — Exploring the map
Chapter 4 — Doctrine
Chapter 5 — The play and a decision to act
Chapter 6 — Getting started yourself
Chapter 7 — Finding a new purpose
Chapter 8 — Keeping the wolves at bay
Chapter 9 — Charting the future
Chapter 10 — I wasn’t expecting that!
Chapter 11 — A smorgasbord of the slightly useful
Chapter 12 — The scenario
Chapter 13 — Something wicked this way comes
Chapter 14 — To thine own self be true
Chapter 15 — On the practice of scenario planning
Chapter 16 — Super Looper
Chapter 17 — To infinity and beyond
Chapter 18 — Better for Less
Chapter 19 — On Playing Chess

This post is provided as Creative commons Attribution-ShareAlike 4.0 International by the original author, Simon Wardley.

Simon’s site and other writings https://www.swardleymaps.com/
EPUB and PDF versions https://www.swardleymaps.com/writings-books#wardley-maps

Originally published at blog.gardeviance.org on August 23, 2017.

Better for Less was originally published in wardleymaps on Medium, where people are continuing the conversation by highlighting and responding to this story.

I was working on the use of printed electronics with paper (think of digital interactivity within a normal book) when I got that phone call from a friend about “this spaceman who really wants to meet you”. I was curious, so I went along to meet someone called Mark at Canonical. I didn’t know what to expect. The first few minutes were certainly interesting.

Shuttleworth : “I’m Mark. I’ve been told you’re a good UX designer.”
Me : “I don’t know anything about design.”
… silence.

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

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

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

The Three Horizons

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

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

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

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

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

Figure 213 — The Map of Mapping.

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

Figure 214 — Forecasting Service

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

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

Figure 215 — Horizon two

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

Figure 216 — Horizon three

Now let us add the pioneer — settler — town planner model onto the horizon three map (see figure 217). Remember each team has different attitudes, which is what pioneer, settlers and town planners represent. Each team not only builds but operates and maintains their own work until such time that another team takes it away from them. The important thing to note is that horizon three consists of town planners or settlers or pioneers or all of them depending upon where I choose to focus.

Figure 217 — PST added to horizon three.

The horizons are context specific. You cannot simply overlay them onto a PST model or even the concept of evolution by saying “genesis is horizon three” as it depends upon where you are and the landscape surrounding you. For example, depending upon where the business is in the map then horizon three could be either genesis of a new act, or shifting a product to a commodity or even a new product. That of course assumes that by horizon three you mean far future. If you stick with horizons as being broadly evolution based (i.e. genesis to product to commodity) then you can find horizon three is sometimes your core business, sometimes your future and sometimes your far future. Horizon’s don’t stack up well with evolution and it quickly becomes messy unless you accept a terminology of horizon one as current to horizon three as far future and allow them to exist on different parts of the map.

Another thing to note is that the horizons can often be broadly anticipatable. This is the thing I find inadequate with the horizon model because without a map and the learning of common economic (aka climatic) patterns then it becomes all too easy to miss the obvious. It is why I find the three horizons useful as a high level concept but overall weak in practice on its own. It also fails to help me adequately deal with inertia or legacy.

The issue of legacy

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

Figure 218 — Change of Compute and Platform

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

Hence another area of legacy would be the practices and activities below the platform layer which includes concepts such as DevOps. In 2017, such a statement tends to receive a strong negative reaction. Most react with the same forms of inertia as those who reacted against cloud in 2006. Many will claim DevOps is more than infrastructure as it’s about development and culture. Depending upon how far in the future you’re reading this from, you’ll probably be quite surprised by this and even more likely you will have never heard of DevOps.

As with all such things, DevOps was a child and reaction against the prevailing methods of management. It co-opted concepts from earlier schools of thought (e.g. ITIL) including iterative approaches, use of components, configuration management, services approach, a focus on users and measurement whilst simultaneously distancing itself from them. It added its own dogma and created a separate tribe. The same will happen in platform, a new school of thought will emerge that will copy and build upon DevOps but deny it has any relationship to it. DevOps will become “what my mum and dad does” as the rebellious child declares its independence and denies any inheritance from the former. Many of the genes of DevOps will be found in this new generation (though they will rarely admit it, painting DevOps as some form of strawman version of itself), some of the genes will become recessive and new genes will dominate.

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

Figure 219 — adding legacy (a consumer perspective)

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

Figure 220 — legacy from a provider perspective.

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

Figure 221 — the future, from a consumer perspective

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

On Porter

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

In the time of wonder, it is a battle to become established. The field is not yet developed and there are no “new entrants” as there are no established figures to be “new entrants” against. Everything is new, uncertain and uncharted. It is the wild west, ‘ere be dragons and the home of split infinitives. The consumers hold the power and it is they who decide whether this industry will succeed or not despite their initial inability to know whether they need it.

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

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

Whilst the interaction of all consumers (demand competition) and all suppliers (supply competition) drives the process of evolution, the question of whether a specific activity or data set centralises or decentralises depends upon the actions of individual actors (suppliers and consumers) in this market. For example, it would have been relatively trivial for the hardware manufacturers to create Amazon clones and a price war in the IaaS space around 2008–2010 in order to fragment the market by increasing demand beyond the capability of Amazon to supply due to the constraint of building data centres. I had these exact conversations with Dell, IBM and HP throughout 2008 and 2009. I even told them their own inertia would fight against this necessary change and they would deny the existence of the punctuated equilibrium until it was too late. The fact they didn’t act and lost their own industry is entirely the fault of their own executives and also one of the major factors why have seen centralisation in the IaaS space.

Centralisation depends upon the actions of specific actors (in this case the inaction of hardware suppliers and hosting companies). In the future, this may in fact yo-yo from centralised to decentralised or find a balance between the two (as with electricity provision and self generation). Such a change in the means of production is however unlikely to change the interfaces themselves i.e. a shift from central to self-generation does not mean a change in voltage or frequency for domestic power provision. The future interfaces of computing have already been defined.

The point to remember with Porter’s forces is the balance between these forces tends to change as any component evolves. It also isn’t static within a stage of evolution — for example the yo-yo between centralisation and decentralisation with a corresponding yo-yo between Supplier and Consumer bargaining power. However as a general guide, I’ve provided in figure 222 the most dominant forces you’re likely to encounter.

Figure 222 — Porter’s forces and evolution

Examining Canonical

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

Figure 223 — the changing market

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

Figure 224 — the horizons.

In terms of play, we understood that moving fast and land grabbing the guest OS territory was essential. To help in this, we also needed to support those developing applications or building tooling around those co-evolved practices. If we found examples of platforms plays in this space we also needed to be invested in this. We understood that many potential customers would have inertia hence we’d have to provide some forms of transitional or private cloud offer even if this did nothing more than get the conversation started.

We also knew our competitors had inertia. As soon as I discovered Red Hat salespeople were rewarded bonuses based upon satellite subscriptions (used for security updates) then I quickly set about promoting a message that security should be “free” in the cloud. There’s nothing like threatening someone’s bonus to get them to turn against a change. Our focus was clear within my cabal. Mark did an amazing job of turning this into the entire company focus. Rick and others set about putting in engineering effort to make it happen. Steve gave me all the firepower and cover I needed. For my part, I mainly focused on promoting Ubuntu’s cloud message, being involved in the community, highlighting targets to bring on board and trying to stop people rebuilding or getting in the way of things that the community was doing.

An outline of the play is provided in figure 225 and the result in figure 226. Within eighteen months, Ubuntu went from a small part of the operating system to dominating the cloud guest OS. My part was a minor but instrumental role and I have to applaud the marvellous teams at Canonical and within the community for making it happen. A small company of three hundred took on the might of two giant hordes but unlike the Spartans, this time we won. My proudest moment came from hearing a CIO talk about how “the future was all RedHat and then suddenly it was all Ubuntu”. I played a small part in that.

Figure 225 — our focus

Figure 226 — the results

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

On the question of timing

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

Figure 227 — Gartner emerging technologies, 2008

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

Figure 228 — An example of different waves of value.

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

Figure 229 — A benefit curve for differential value

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

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

Figure 230 — Changing benefit with evolution and implementation

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

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

We have the same peak of inflated expectation and the same trough of delusion. My first reaction was horror.

The evolution curve on which mapping is built uses ubiquity versus certainty. If I can model from Gartner’s hype cycle to evolution then I can take the points on a hype cycle and measure precisely where something is on the certainty axis of evolution. For things that are uncertain then this should be impossible as the ability to precisely measure something which is uncertain is the stuff of magic folk. My first reaction was Gartner’s hype cycle proved evolution was wrong. I was a bit perplexed at that point especially since I had found mapping so useful. Fortunately, I met with a friend who pointed to a great big hole in my argument. I was assuming that Gartner’s hype cycle was based upon the measurement of some physical property. If it wasn’t, if it was just aggregated opinion (of consultants, analysts or industry) then there’s no measurement of the uncertain as it’s just opinion. It’s an opinion of where something is, not a measurement of where it actually is. As I subsequently found out, the hype cycle is subjective opinion.

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

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

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

Figure 233 — When is the war likely

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

Figure 234 — Cloud computing and 3D printing.

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

However, in the case of 3D printing then you do want to wait or be a fast follower. It has a long long way to go before it industrialises and you’ve got an entire product stage it has to evolve through. In fact 3D printing will reach the plateau of productivity and see relatively widespread adoption as a product long before it industrialises. At some future time (2025–2030), as it starts to industrialise then it’ll probably reappear in the technology trigger usually under a slightly different meme. When it comes to 3D printing then you could wait a bit and get involved in the product space or wait much longer until the “war” is upon that industry at which point you’d need to go “all in”.

Two points — cloud computing and 3D printing — on almost exactly the same position of the hype cycle required radically different approaches to investment and strategy. One was “all in”, the other was “wait and see”. Being aggregated opinion, I do find the hype cycle quite useful as long as I separate out what stage of evolution something is in first. I often talk to CIOs who tell me they invest when something is in the stage of enlightenment. That’s a fairly reasonable way of losing every major technological war in business.

For me in 2008, this hype cycle helped reinforce the message that we had to go all in, it was a land grab for this territory. I also took comfort that many of my competitors probably read exactly the same hype cycle and thought they had time. Let us emphasise that point, I was going “all in” when competitors thought they had time — it’s a help yourself to the future buffet with no-one saying you can’t have 7th helpings because everyone else got the date wrong. Thank you Gartner, you probably have no idea how much you’ve helped me. Better luck next time IBM, HP, Dell, RedHat … assuming they survive what is to come.

Anyway, the gameplay above was 2008 to early 2010. In mid 2010, after capturing pretty much the entire market (a space that has massively grown since with Ubuntu still the “top dog” in 2016), I then headed back into research. My work was done. Naturally, I left Mark and others with a variety of plays to use along with a specific focus on the platform space. I don’t necessarily agree with all the steps they’ve made but I respect their choices and they play a good game. I suppose, that’s the real point — they are playing the game not me but in some small way I helped them to improve. Before we dive into the strategy space, we should take a peek at another part of my journey into Government. Hence let us boldly go into the next chapter.

The book so far

Chapter 1 — On being lost
Chapter 2 — Finding a path
Chapter 3 — Exploring the map
Chapter 4 — Doctrine
Chapter 5 — The play and a decision to act
Chapter 6 — Getting started yourself
Chapter 7 — Finding a new purpose
Chapter 8 — Keeping the wolves at bay
Chapter 9 — Charting the future
Chapter 10 — I wasn’t expecting that!
Chapter 11 — A smorgasbord of the slightly useful
Chapter 12 — The scenario
Chapter 13 — Something wicked this way comes
Chapter 14 — To thine own self be true
Chapter 15 — On the practice of scenario planning
Chapter 16 — Super Looper
Chapter 17 — To infinity and beyond
Chapter 18 — Better for Less
Chapter 19 — On Playing Chess

This post is provided as Creative commons Attribution-ShareAlike 4.0 International by the original author, Simon Wardley.

Simon’s site and other writings https://www.swardleymaps.com/
EPUB and PDF versions https://www.swardleymaps.com/writings-books#wardley-maps

To infinity and beyond was originally published in wardleymaps on Medium, where people are continuing the conversation by highlighting and responding to this story.

The LFP example is based upon a real-world event. I say “based” because I usually take time to disguise the actual event to protect any guilty parties. In this case, the haphazard and stumbling CEO was … me. I’m very wary that my long experience with mapping means that I tend to gloss over parts through assumption. In much the same way, I spent six years assuming everyone already knew how to map and it wasn’t until 2011 that I started to realise they didn’t. With that in mind, I’m going to go into excessive detail in the hope that I don’t miss anything useful to you. To keep it relevant and not just a history lesson, I’m going to go through the steps of how you would tackle the LFP scenario as if it was happening today.

To begin

I always start with the strategy cycle. To me, it doesn’t matter whether I’m looking at nation states, industry, corporates, systems or even individuals — the strategy cycle applies. For completeness, I have repeated this cycle in figure 198.

Figure 198 — the strategy cycle

Our initial purpose for this LFP system is to help create leads for our client. That is what they need and it is also how we will be measured and paid. We don’t have to agree to the proposal but if we choose to accept it then our focus must start here. Of course, we have our own needs — to survive, to make a profit, to have fun — which we could choose to map. In this case, I’ve chosen not to because this is a teaching aid and I want to keep it simple.

We know we also have a “why of movement” question in the scenario — do we build the entire system “in-house” or do we use elements of a “public” platform? Do we go here or there? Why? Before we can answer this, we need to understand the landscape a bit more. Fortunately, a map has been kindly provided by engineering along with the more common financial models. I do love a good spreadsheet, I’ve spent years of my life immersed in cashflows, GAAP, chart of accounts, options analysis, business models and all manner of delightful things. However, a word to the wise, put these to the back of your mind for the moment. The financials can often be skewed by a bias to the present. So, as tempting as it is to dive straight into the financials, start with the landscape.

With the map provided, one immediate thing I’m going to note is that we have inertia against using the public platform space via both security and the systems group. I’m going to mark that onto the map in figure 199 and cut out the superfluous “in-house”, “public” terms as it should be obvious by now.

Figure 199 — adding inertia.

Now let us focus on that platform change, the shift from product to a more industrialised form which in this case means utility. As noted many times before we have a common economic pattern of co-evolution i.e. as an act evolves we often see a corresponding co-evolution of practice. Let us concentrate here, remove all the other bits of the map and add in co-evolution. I’ve done this in figure 200

Figure 200 — co-evolution

By applying that basic pattern to our map, we can anticipate that as the world shifts towards more utility platforms, some new-fangled practice (a sort of DevOps 2.0) will emerge. We don’t know what those practices will be as they will emerge in the uncharted space. But we do know they will emerge shortly after the formation of utility platforms and that we will have inertia to this change. We also know that such changes tend to be rapid (the punctuated equilibrium) and we can also go a bit further in our “prognostications” or as I prefer to call them, cowardly custard pronouncement of self evident trends.

The nodes on the maps represent stocks of capital. The lines represent flows of capital between stocks. With evolution from product to a more industrialised form then we normally expect to see flows of capital away from the past industry into the more industrialised providers and / or new higher order systems and / or new practices. I’ve marked on these flows of capital and were to invest and what will become legacy onto figure 201.

Figure 201 — flows of capital

We describe these industrialised components along with the new higher order systems that they enable as the “new industry”. There will also be new practices (i.e. co-evolved) that will replace those past practices. The new higher order systems will themselves enable new needs (technically, they expand the adjacent possible, the realm of new things we can do) which means new customers. The past ways stuck behind inertia barriers, increasingly devoid of capital will die off.

If this sounds familiar, then it should. This is what Joseph Schumpeter termed “Creative Destruction”. The question is when will this happen? For that I turn to weak signals and examine those four conditions — does the concept of utility platform exist, is the technology there, is it suitable and do we have the right attitude? See figure 202.

Figure 202— do the factors exist?

In this case, someone is providing such a platform hence the concept and technology exist. We have services like AWS Lambda. In the scenario, there’s obviously some sort of dissatisfaction with the current models otherwise the client wouldn’t be looking for a new way of doing things. The attitude seems to be there, maybe this platform space will help? But is it really suitable? I tend to use weak signals to help determine that but you can also use the cheat sheet. When you examine an activity, it often has characteristics from more than one stage of evolution e.g. it might be strongly product and a little bit commodity or vice versa. You can use this to help you refine your understanding of where something is by simply going through each characteristic and counting “is it more this or that?”

When discussing something about to evolve from one stage to another then I’m looking for more of the evolved characteristics. In this LFP case I’m looking for whether platform has more “commodity” characteristics. I’ve published a more advanced cheat sheet in figure 203, with each stage (I to IV), the terms used for different types of components (activities, practices, data and knowledge) plus the general characteristics.

Figure 203 — The Cheat Sheet

So, let us examine the platform space today in 2017. What we’re focused on is a code execution environment which in the product world is normally described as some form of platform stack (e.g. LAMP or .NET) or in the utility space where we have the emergence of systems such as Lambda. It’s importance to focus on the “code execution environment” as unfortunately platform is one of those hand wavy terms which gets used to mean any old tripe — see also ecosystem, innovation, disruption and almost anything in management that is popular. Don’t get me started on this one as I’m not a fan of the field I work in. I’m sure along with strategy consultants talking about “earlobes for leadership” (HBR, Nov, 2011) then I suspect it wouldn’t take me long to find a cacophony (the collective noun for a group of strategy consultants) of them talking about how a “cup of tea is a innovative platform” or some other load of dingo’s kidneys.

From the cheat sheet, comparing stage III (product) and IV (commodity), I’ll score up how many commodity characteristics exist for platform: -

• Ubiquity? Is the platform space rapidly increasing OR widespread in the applicable market? I think it’s fair to say that this is very widespread. It’s not a case that you normally have to suggest to a developer that they consider using a platform to build something, they often have their favourite stack whether it’s LAMP or something else. We can give a tick for commodity here. [1/1]
• Certainty? Are we seeing a rapid increase in use (i.e. rapid diffusion in all companies) with platforms that are increasingly fit for purpose OR are they already commonly understood, just an expected norm? I think we can say most developers would be surprised to walk into a company that was excited about its platform roll-out. They’d expect some sort of platform to exist. Strike two for commodity. [2/2]
• Publication types? Are trade journals dominated by articles covering maintenance, operations, installation and comparison between competing forms of platforms with feature analysis e.g. merits of one model over another? OR are trade journals mainly focused on use, with platforms becoming increasingly an accepted almost invisible thing. If we go back to 2004 then journals were dominated by discussion on this platform or that platform — LAMP vs .NET and the best way to install. Today, this is much less and most of the discussion is about use. Strike three for commodity. [3/3]
• Market? When we examine the platform market are we talking about a growing market with consolidation to a few competing but more accepted norms? OR are we talking about a mature, stabilised market with an accepted form? From my perspective then the platform market seems mature and stable with an accepted form — .NET, Java, NodeJS, LAMP etc. Commodity wins. [4/4]
• Knowledge management? Are we mainly learning about how to operate a platform, starting to develop and verify metrics for performance OR is this field established, well known, understood and defined? In this case, platform probably wobbles on the side of product rather than commodity. Hence, product wins and it’s now [4/5] for commodity.
• Market Perception? Do we have increasing expectation of use of some form of platform and is the field considered to be a domain of “professionals” OR are platforms now considered trivial, almost linear in operation and a formula to be applied? Though we are getting there, product still wins and hence it’s now four to commodity out of six. [4/6].
• User perception? When it comes to platforms are they increasingly common and a developer would be disappointed if it was not used or available? Would there be a sense of feeling left behind if your company was not using a platform OR are they standard, expected and there would be a feeling of shock if you went to a company that didn’t use some form of standard platform (whether .Net, LAMP or other). I think I can probably say that commodity wins this one, it would be shocking to find a company that didn’t use some form of platform approach and it’s that “shock” which tells you this is in the commodity space. [5/7].
• Perception in Industry? Advantage in platform is now mainly seen through implementation and features (i.e. this platform is better than that platform) OR platform is now considered a “cost of doing business”, it’s accepted and there are specific defined models. It would be difficult to imagine a software house today that didn’t view a platform as a “cost of doing business”, so whilst there’s some wobble, I’d argue that commodity edges this. [6/8].
• Focus of value? Are platforms considered to be areas of high profitability per unit and a valuable model? Do we feel that we increasingly understand platforms and vendors are focused on exploiting them? OR are platforms more in the high-volume space, considered “known”, often mass produced with reducing margin. Are platforms essentially an important but increasingly invisible component of something more complex? In this case, especially with provision of utility like services then commodity wins again. [7/9].
• Understanding? In the platform space are we focused on education with a rapidly growing range of books and training combined with constant refinement of needs and measures? OR do we believe platforms and the concepts around them to be well defined, almost stable, with established metrics and even respected certification programs. This is a tough one, I steer to the side of commodity but can easily see a case for it being still in product. [8/10].
• Comparison? Do we have competing models for platforms with feature difference? Are authors publishing some form of evidence based support for comparison i.e. why this platform is better than that because of this feature and why you should use them over not use them? OR are platforms just considered essential, an accepted norm and any advantage is discussed in terms of operations — this is cheaper or faster than that? This is a tough one but in this case, I’d edge towards product. We’re not quite at the pure operational comparison. Product wins. [8/11].
• Failure modes? When it comes to a platform is failure not tolerated? By this, I don’t mean there is no failure — a distributed environment based upon principles of design for failure copes with failure all the time. But do we have an expectation that the entire platform system won’t fail? Are we focused on constant improvement? Do we assume that the use of such a platform is the right model and there exists some resistance to changing it? OR have we gone beyond this, are we now genuinely surprised if the platform itself fails? Is our focus on operational efficiency and not stopping the fires? Whilst there will be many companies with the home-grown platform effort and inevitable out of control fires, as an industry we’ve moved into the commodity space. [9/12].
• Market action? Is the platform space entrenched in market analysis and listening to customers? What shade of blue do you want that wheel to be? OR has it become more metric driven and building what is needed? Commodity wins here, just. [10/13].
• Efficiency? When it comes to platforms are we focused on reducing the cost of waste and learning what a platform is OR are we focused on mass production, volume operations and elimination of deviation? Again, especially since utility services such as Amazon Lambda now exist then I’d argue commodity edges this. [11/14].
• Decision Drivers? When making a choice over what platform to use, do we undertake a significant analysis and synthesis stage, gathering information from vendors and analysts on its suitability OR do we just pick the platform based upon previous experience? Tough one, but again I view that commodity just edges this in the market overall though some companies love their requests for tender. [12/15].

Overall, we can safely say that the platform space is firmly in stage IV (commodity + utility) in 2017. It’s also fair to say that platform isn’t quite yet the industrialised commodity that electricity and there’s a bit further to go.

Hence, what do I know from my map and the basic patterns so far? Platform is moving into stage IV (an industrialised component) with provision of utility services. This will happen rapidly (a punctuated equilibrium) with such a shift (known as the “war”) normally taking 10–15 years. There will be a co-evolution of practice associated with this. Many companies will have inertia. Capital will flow into the more industrialised platform space and those higher order systems built upon it — there is going to be lots of future opportunity here. Capital will also flow out of those spaces stuck behind inertia barriers, not exactly where you want to be. Or is it?

At this point, we need to think about our purpose. My goals as a “retiring” CEO might be very different from the “upstart warrior” CEO. Let us assume I’m more Queen Boudica than Victor Meldrew and I want to fight for a bold future for my “people” rather than just giving up on the battle and exploiting where we are for my comfortable “retirement”. My cultural heritage is therefore more inclined to investing in the new space rather than just exploiting the legacy. This assumes I have a choice in the matter and fortunately in 2017, I’m not yet in a position where I’m forced to exploit the legacy as the change is only just starting in earnest. I’m a little late but not that late. Whoot!

But, hang on, aren’t I deciding here? I haven’t gone through doctrine yet and I’m already talking about how to play the game and where to attack. The strategy cycle is a cycle which you will loop around many times in coming to your decision. Each time you loop around, new information and biases form that will change your purpose, your view of the landscape and ultimately your choice. This is all normal. It’s not a rigid linear path. It’s a guide. At this point, let us peek at those financial models.

Getting messy with numbers

The first thing to note is that numbers are not reality. Just because it’s written in a spreadsheet doesn’t mean it is going to happen any more than a Gantt chart tells you what the future really holds. In this case, the CFO has had the good sense to examine a range of outcomes for two variants (the build “in-house” and the use a “public” platform) and then complain about the lack of probability provided. I like this CFO.

Let us assume that after some badgering we have managed to tease out some probability figures for the outcomes from marketing and sales — outcome 1 (10%), outcome 2(10%), outcome 3 (15%) and outcome 4 (65%). I happen to agree with the CFO that sales are marketing may well have bias here. Later in this chapter, I’ll explain mechanism for how you might more accurately determine those probabilities. Obviously our choice of building “in-house” or using a “public” platform doesn’t impact those probabilities. They are independent. In figure 204, I’ve added probability onto the financial models for each of the variants.

Figure 204 — Options analysis

Let us go through the terms.

• Probability: the likelihood of this outcome occurring according to sales and marketing.
• Total investment: the total amount of capital we’re putting into this effort.
• Total return: the amount of capital being returned (after repayment of investment). This is the annual net cash flow including any disposals.
• Opportunity loss: the return I would have expected had I spent the capital on other projects. In the LFP scenario our standard return on investment (ROI) is 40%
• Net Benefit / Loss: How did this investment do compare to my standard expected return? i.e. total return — opportunity loss.
• Expected return: the net benefit / loss * the probability of this occurring.

By summing the expected returns for each outcome, we can determine the value of each variant. The best expected return comes from building “in-house”. But wait, didn’t we say this building in-house was the future legacy? Well, as I did point out, most financial models have a bias to the present and hence they discount the future. The problem is that by following this path we’re are building up the legacy practice (and related inertia) and not positioning ourselves to build a future market. We might maximise our short term position but we end up in a dreadful long term one.

Can we somehow financially account for inertia and future position? Yes. The essential question between the variants is the following — are we prepared to gamble $435k of expected return to explore and potentially secure a more lucrative but undefined future position? To analyse this is very complex. So, what do we do? Well, at this point we depart paths. I will build monstrous complexities for navigation and do things to spreadsheets that shouldn’t be done. You can SWOT it.

SWOT? But isn’t SWOT the curse of simplistic management? Yes, but it also has its uses particularly if we understand the landscape. The problem with SWOT isn’t that it is useless but instead we apply it to landscapes we don’t understand.

We have two variants — build in-house and public platform. The strength of build in-house is we’re familiar with this approach within our teams and it provides the greater expected return. Its weakness is we build up our legacy position which comes with the threat of increased inertia and future inability to change. On the other hand, using a public platform play has different characteristics. Its strength is we build up experience in the future space and though it has a less expected return it provides an opportunity to develop skills and explore new opportunity. The weakness is we’re unfamiliar with this and the threat is that it fails we lose face with the customer but also potentially political capital with the board. The path you decide really depends upon who you are. The “retiring” CEO will tend to plummet for in-house and the short term expected return whilst the “warrior” CEO is more likely to go for the public platform and a long term future.

At this point questions such as “But what if those probabilities are wrong?” and “What if the options I’m looking at aren’t right?” should be racing through your mind. So, let us tackle that bit.

Getting probability probably sort of right

As with most things in life, there exists huge amounts of uncertainty over which outcome will occur. This is only exceeded by a willingness of people to tell you that they would have chosen a different outcome if in fact you pick the wrong one. Fortunately, you can exploit this. First up is to use the Marquis De Condorcet’s work and get everyone familiar with the business to assign probabilities and take the average of the lot. A more refined version is to use an information market.

Information markets are fairly simple concepts that are fiendishly difficult in practice because of unintended consequences. A basic example of one is as follows. Let us assume we want to know from the company whether a project called “X” will fail to deliver or succeed? We create a bond (called project X) which will pay a certain principal (e.g. $200) if the project is successful at a specified date but will return $0 if it is not. We give everyone in the company one bond and $200 as a bonus. We then let them trade the bond in our own internal market.

Along with the nice “thank you” for a $200 gift (which has its own secondary benefits), the bond itself maybe worth upto $200 or might be nothing at all. So, people will tend to trade it with others. If I expect the bond is 90% likely to fail then I’ll be over the moon to sell it to someone else for $40 (the strike price) and a bit gutted if it subsequently succeeds as they cash in an additional $160 bounty ($200 the bond’s principal — the $40 strike price). The price on the internal market will reflect the likelihood or not of the bond i.e. the question asked. The use of such information markets is well over a decade old but there can be lots of political complications in practice particularly if you get an individual starting to make a small fortune on this. There’s nothing wrong with that, they’re somehow providing you accurate information on the future but it can cause “difficulties”.

I mention information markets more to point out that there are lots of ways of skinning Schrodinger’s cat and finding probability. I’m certain there must be a good few books out there on this topic, so I’ll leave that to the reader to go explore. The question on probability is always how much is that information worth to you? The cheapest way is to guess yourself, the slightly more expensive way is to aggregate other peoples guesses and the far more expensive (but also far more accurate) tends to be the use of an information market. But let us assume our probabilities are “right” despite my reservations and those of the CFO. This doesn’t mean one outcome will happen, it’s just a probability. We must still roll the dice.

Hence, what we know so far is that we have this opportunity to build an LFP system, there are two variants (in-house, public platform) and whilst the in-house variant gives a greater expected short term return, the platform play prepares us for the future and the co-evolution of practice that will happen. Let us get back to our strategy loop and start looking at doctrine especially the issue of “managing inertia”.

Managing inertia

We have the map, we can anticipate certain change and we can already see there is inertia. The question now becomes, what sort of inertia do we have? Back in 2008, I use to categorise inertia into four basic types with numerous subtypes. I’ve tidied this up since then. The basic forms of inertia are provided in figure 205 including tactics to counter and counter points.

Figure 205 — inertia

All forms of inertia relate to some loss of capital whether physical, social, financial or political. We know that two groups (security and systems) are exhibiting inertia, however such visible signs are usually not the problem as we’re aware of it and hence it can be managed. The danger is always the group that haven’t quite made themselves clear.

In the case of security, the inertia is probably related to two types. First, we have uncertainty over the use of a platform play and any co-evolved practices that might emerge. This will require “Investment in knowledge capital”. We can overcome this with either training or providing time and resources to develop the necessary skills. We can certainly provide an argument that if we fail to do this then the future cost of acquiring these skills will be higher and we will also miss out on shorter-term motivation for staff. The second type of inertia is “Changes to governance, management and practices”. Co-evolution is always difficult for people to get to grips with as it means that their existing and perfectly valid best practice for a product world become no longer relevant. We can only overcome this by explaining co-evolution usually by pointing to past examples. Both types of inertia are relatively simple to manage.

Slightly trickier is the systems groups. Along with the two types of inertia mentioned above, we’re likely to have two additional types especially since the group builds and controls the underlying infrastructure behind any home-grown platform efforts. These additional types are “loss of political capital” and “change of business relationship (loss of social capital)”

The “loss of political capital” includes fear over becoming irrelevant in the future, loss of status and loss of past empire. Don’t underestimate or dismiss this as it’s very uncomfortable for those who face it. You counter by giving people are path to the future and relevance in it. Start by acknowledging what has been achieved and move onto modernisation. You need to emphasise the importance of future agility, efficiency, importance to the business and how we must build for the future. You also must include them in this future. At this stage, with utility platforms just in the early stages of industrialisation then such action is relatively trivial. The co-evolved practices haven’t been developed and so there’s plenty of time for training, re-skilling and the re-application of essential system concepts from configuration management to versioning in a more utility platform world. In all likelihood the biggest danger is that by helping your systems team develop into this world at this stage, they’ll become super valuable in the not so distant future. It is however, far better to have a small army of super valuable people that everyone else is trying to poach than to be left with a bunch of legacy skills and trying to desperately poach from others.

The co-evolved practice will be different from the past but someone has to develop that capability, no-one yet has those skills and why shouldn’t it be your systems team? Unfortunately, what normally often happens is companies don’t anticipate obvious changes and leave it late. This creates an added complication which I’ll discuss in a moment.

The “change of business relationship (loss of social capital)” is the second additional type of inertia you must contend with. Within a company, there’s often a pre-existing relationship with vendors who might be supplying products or services. This relationship creates inertia to change i.e. we have our familiar and favourite vendor. In normal circumstances, you can deal with this inertia through normal vendor management approaches. You can emphasise that the time is right for a change, that the past has evolved and we need to re-evaluate the vendor’s offering. However, there’s the complication mentioned above.

If you’ve left it late then the vendor of a product may well be spreading huge amounts of fear, uncertainty and doubt over the more utility form to your own team. They will probably have tried to convince your own team (e.g. in this case, our systems team) that they have no future in this “future world”. If they’re canny, they would have encouraged articles in related trade press spreading the same message. This is all designed to get your own people buying the vendor’s product rather than adopting to the new world. If you haven’t had that conversation about the future and painted that path, this can make it much harder for you to overcome any “loss of political capital”.

You can try and say, “don’t worry but will invest in retraining” but this is also where any past Machiavellian efforts or brutal corporate action will bite you in the bottom. If there exist doubt in your trustworthiness then they won’t follow but will resist. Whatever you do, as annoying as it is to be confronted by this — remember one thing. They are behaving perfectly rationally. You are the wally who left it late to deal with a highly anticipatable change and therefore caused the mess. If you want someone to blame, buy a mirror.

Unfortunately, we all make mistakes. This is also why you must always consider not only our action today but the future consequences of such action. Having that trust can bail you out of your own face palm. However, we’re not in that position with the LFP scenario yet. We shall assume we have a team who can have an open and honest conversation. We can anticipate where the future is heading with the map and we’re going to share this. We’re going to have that discussion and invest time and money in bringing our systems and security teams into this new world with new skills and new capabilities. We leave no-one behind and we certainly don’t turn up five years late to the battle in a blind panic.

Alas, we might still have a problem. There’s potentially another source of inertia and it’s a powerful one. The board. We know they have a concern but aren’t going to raise an objection … yet. Now that can either be just a general question on the change or could be hiding something else. We need to explore that. It could be as simple as “Data for past success counteracts” i.e. they’re used to us operating in one way and we’ve not been down this path. It could be concerns over “Loss of existing financial or physical capital” because we’ve invested in data centres. It could be a question of political capital or that one board member has looked at the model and wants to focus on short term expected return rather than building a future.

Whatever the cause, you need to find it and to fix it. That’s one of your many jobs as the CEO. There are also many other forms of inertia and so for completeness, though not necessarily relevant in the LFP scenario, we will quickly run through the other types of inertia: -

• “Threat to barriers to entry”, the fear that a change will enable new competitors. Whilst that fear may be justified it is often an unavoidable change that is already happening in the market and outside of your control. You cannot ignore it.
• “Cost of acquiring new skill-sets” is one of the more bizarre sources of inertia because not only do you not have a choice but the cost of acquiring skills will often increase over time. This is a common consequence of a punctuated equilibrium where huge numbers of companies that are very late to the party, simultaneously declare this change as the future and promptly cause a shortage of skills. There are many ways to counter this and mitigate the cost — assuming this is done in a timely fashion — from developing in-house, use of conferences to creating centres of gravity to attract talent.
• “Suitability”, one reasonably common form of inertia comes in the form of questions over whether it’s ready e.g. ready for production, is the market ready for this, are customers ready? The best way to counter is through weak signals and examination of the components (e.g. using the cheat sheet).
• “Lack of second sourcing options” is often a valid concern but can be used to disguise other forms of inertia. Back in 2008, it was not uncommon to hear a company say without irony something of the form — “We’re an Oracle shop. We’ve thought about using public cloud but were worried about the potential for getting locked in with Amazon. We want to see more choice”. If you can overcome the irrational side of the debate and any tendency to point out the ridiculous flaw in the argument, then this is all about supply chain management, trade-offs and use of standards where appropriate. There are a wide range of techniques to mitigate it.
• “Lack of pricing competition” is another reasonable concern which really points to how well functioning the market is. Do we have single or multiple vendors? What are the switching costs?
• “Loss of strategic control” is usually wrapped up with fears of letting go and in the cloud space led to the idea of “server huggers”. However, there are some valid aspects to the concern around buyer vs supplier power relationship. Most of this can be overcome with strategic planning and examination of different scenarios i.e. what should we do if the supplier rapidly increases price etc.
• “Declining unit value” is usually a business concern related to a desire to maintain the past. The only way to counter is through awareness of evolution and how markets aren’t static. You need to look at alternatives opportunities, think Charles Handy’s 2nd curve and try to avoid the spiral of death.
• “Data for past success counteracts”, an extremely common form of inertia particularly if the company has been successful. Most companies build up a significant stock of data that informs them how successful the past was. This will often be used to argue that the future will be more of the same. You need to take a leaf out of portfolio management and realise that your portfolio will change over time. Options analysis and risk management approaches can be useful here to avoid having all your eggs in one “past” basket.
• “Resistance from rewards and culture”, hugely problematic for most companies and easily exploitable by competitors. Performance bonuses linked to selling an existing product set can be a significant source of inertia and weakness. You can manage this through HR by using higher rewards for adaptation, education, longer term thinking and promoting greater situational awareness.
• “External financial markets reinforce existing models”, another common but tricky form of inertia to deal with. As discussed in the previous chapter, it’s important to understand your context and the role being played by others such as fund managers. There are certain techniques that can be deployed here to overcome market inertia including spinning a future story.

Where are we?

We have a map of the landscape, we’ve applied basic economic patterns to anticipate change, we can see opportunity in co-evolved practice and obstacles in inertia to the change, we have financial models and understand how we can trade off higher short term expected returns for building a future position. Though we have inertia, we also have an idea of the types and how to deal with it. Our awareness of the situation is expanding. This is good. This is how it should be.

In the above, I specifically state “anticipate change” because we cannot predict evolution over time (see chapter 7, section “the trouble with maps”). We must use characteristics or weak signals or information markets to give us a probability of when the change will happen or even if it’s occurring today. Mapping is all about probability rather than time; the uncharted space is uncertain and the industrialised space is more known. To predict over time would mean we could say “in 453 days this [activity or practice or business model] will change from A to B”. As far as I’m concerned that is straying into the realm of charlatans, crystal ball fanatics and soothsayers.

I often hear people counter with vague notions of time e.g. “at some point in the future”. That is not predicting over time as time requires a “when”. I cannot, nor have I ever been able to predict evolution over time. Of course, I’m fully aware that I have my own inertia caused by my own past success with mapping and that the subject itself will evolve (see chapter 7, a map of mapping). Someone else may well find a way to map over time. I will no doubt dismiss it and be proved wrong. I do hope I have the wit to use my own tool on myself at that time. “When” will this happen? As I said, I can’t predict over time and the weak signals aren’t even strong enough for me to guess.

In terms of the strategy cycle, we’ve observed the environment and moved onto orientating around it with doctrine such as “manage inertia”. However, let us explore the cycle a bit further.

Getting Primitive

In this section, I’m going to look at how we organise around the LFP scenario and put down a few markers for strategic play that we might consider. Once I have a general outline, I’ll often loop around this several times with others to refine, to create alternative scenarios, to alter course before finally deciding upon a choice of action. When it comes to organisation then I use not only use a self-contained cell based structure (i.e. small teams) with the right aptitudes (finance, engineering, marketing) but also for the last decade I’ve been using attitude (pioneers, settlers and town planners).

I note recently that Kent Beck has been discussing a model called 3X — eXplore, eXpand and eXploit. This is excellent as there’s nothing like independent discovery to give a bit more substance to a topic. Pioneers eXplore, Settlers eXpand our understanding and Town Planners eXploit by industrialising with each group operating and maintaining its own space. This all deserves a good hat tip to Robert Cringely and his marvellous book “Accidental Empires”. Anyway, back to our map. Since we’ve previously built our own systems then I’ll assume we know how to do this and it would be superfluous to cover the build in-house variant. Instead I will focus on the platform change and how to organise around this. In figure 206, I’ve outlined the two obvious cells that we need to consider when using the public platform.

Figure 206, The structure

One cell refers to town planning around the platform. Obviously, someone else is providing the platform as a utility service to us but we still need to make sure we create highly industrialised process around monitoring the platform, access control and how much we’re getting billed. This is not something new and chances are that provider will be offering tools to make it easy. However, there are a new set of practices that will develop around the financial cost of a function, re-use of functions, the type of events and how we monitor the code itself. This is not so much related to the platform itself but how we use it. In much the same way, the practices that changed industry were not so much about whether we paid the right electricity bill but how we used it to do other things. What those new practices will be is uncertain. I can guess based upon experience of running a code execution platform (i.e. serverless environment) with Zimki in 2005. But it’s no more than a guess.

We can also at this point start adding some primitive gameplay. For example, we could — if we have decided to play a legacy game and not build for the future market — spread fear, uncertainty and doubt over the utility platform. Alternatively, we might play an open play around the co-evolved practices to help them evolve more quickly. We might do this to create a name for ourselves in this space, to build a “centre of gravity” around the skill-sets needed in anticipation that this will become a lucrative market for us. I’ve outlined these two very simple plays in figure 207.

Figure 207 — Two basic plays

So, complying with my natural bias, I’m going to focus on creating a future position and market rather than exploiting a legacy position and waiting for the future to catch up and do horrible things to me. I can do this because I haven’t yet left it too late to make that choice. I’m going to try and own those future co-evolved practice, build a centre of gravity and use open source to achieve this. I’ll accept the lower expected return in exchange for a stronger future position and not building up my legacy. I’ll add my structure and gameplay around the platform space onto my LFP map. See figure 208.

Figure 208 — Future orientated LFP map

The first thing to note is the map is a bit messy and things seem to be in the wrong position i.e. somehow my emerging architectural practice is above my microsite in terms of user needs despite the client not mentioning anything about this changing world. This is fine. All maps are imperfect representations and with a bit of fiddling around and moving pieces then I can create something which appears to represent the situation more clearly. See Figure 209.

Figure 209 — A clearer map.

This fiddling around with maps is all part of exploring a space. It allows us to challenge assumptions with others, to collaborate across multiple aptitudes (finance, engineering etc) and even attitudes (pioneers, settlers etc), to apply past lessons learned and come up with a common understanding. We can now flesh out the space a bit more and being mindful of our current capabilities (that’s assuming you know how many pioneers, settlers and town planners you have — most don’t) create the structure we’re going to use — figure 210.

Figure 210 — the structure.

Looping around and common problems

We now understand the landscape, the trade-off between short term expected return and future position, the structure needed, the main sources of inertia and some basics on the gameplay. Our situational awareness is constantly improving. The next thing we do is loop around the strategy cycle again and refine it. But isn’t that time consuming? Yes.

With experience, for a business that has a map then a single loop (what we’re covering in this chapter) could take anywhere up to 30 mins. Add a couple of loops, discussions between people and you could have easily blown an hour or two before you commit to the choice. Add to that the additional hour or so it might take to create that first map and the financial models and yes, you could be looking at half a day. That is of course an incredibly long time to go from concept to decision to act.

To be honest, I can’t think of many examples where it has taken anywhere near that long. There are a few M&A activities (covering hundreds of millions) where I have taken a day or so but that is the exception and only occurs in fields that I’m not familiar with. Being locked in a room or given people to interview and asked the question “should we buy this company” often involves extracting information from others. Most of the time was spent developing an understanding of the landscape because very little existed. However, we should acknowledge that mapping does take some time and I don’t know how to make it faster. It’s one of the obvious weaknesses of mapping versus gut feel which can just be instant.

Another problem is complexity. First, mapping exposes the complexity of what exists. In the example of Themistocles SWOT (chapter 1, the importance of maps in military history), it’s usually obvious to everyone that you should use a map not a SWOT to run a battle. We understand this because we’re familiar and comfortable with geographical maps. However, there is a downside which is a map is inherently more complex than a 2x2 such as a SWOT and this makes management more challenging and requires more thought. But what if you’re not familiar with maps.

Let us consider how Vikings used stories for navigation. Put yourself in the role of a Viking navigator having spent 20 years learning epic tales and being trusted with steering the boat. Imagine someone says to you that you don’t need a story but you could use a map. The first time someone shows you a map or you will see is diagram with dots on it. You will have difficulty in understanding how can such a thing can replace your twenty years of learning epic tales. You’ll tend to react negatively because of experience i.e. you know the stories work. You’ll have a natural human bias to that which is comfortable and previously experienced. The map will be unfamiliar even alien and its complexity will overwhelm you. It will take many points of exposure and realisation that a map would have been better than a story before most will put in the effort and thought necessary to use it.

Go back to the Themistocles SWOT. Imagine if battles had been run with SWOTs and someone came up and said, I’ve got a map thing which might help. The reaction would be overwhelmingly negative to begin with because it’s unfamiliar (not a SWOT) and complex. It can also threaten those who have spent 20 years learning how to “Battle with SWOTs” or “Navigate with stories” because at its heart, it is basically saying that they’ve been meme copying all this time without understanding the landscape. Into this mix you can throw in the issue that exposing the complexity also exposes assumptions made and opens decisions to more challenge — another thing people don’t tend to like. You’ve got quite a mountain to climb with mapping. Which is probably why those with a military experience (and some familiarity with situational awareness) have an easier path to mapping. The worst cases are normally those who have no military background, 20 years or so of “strategy” experience and an MBA.

However, let us assume you persevere, you create a map, you loop around the strategy cycle and over time (and hour or two, possibly more) through the application of thought then a context specific path becomes clear. What now? I tend to double check it as a final step. I find that using a business model canvas is brilliant for this as by that stage you should have everything you need to fill it in. Let us assume you decide to build the LFP system using the public platform. What now? Well, let us roll the dice and see what happens.

Opportunities multiply as they are seized.

You’ve decided to build the LFP system using it as a springboard to develop a future position around the co-evolved practice that will emerge in the platform space. You’ve overcome your internal inertia through discussion, formed the teams and explained this to the board. You’ll sacrifice some short term expected return for a future position with an eye to repackaging the solution and selling it to others along whilst developing a new practice in the co-evolved space. You roll the dice and it comes up … outcome 2. Oh, damn.

The LFP system isn’t going quite as well as we might hope. Fortunately for us, we didn’t build in the in-house variant otherwise we’d be losing money right now and our discussions with the board might be getting more tasty. The problem with our options analysis is we didn’t price in any variability and risk appetite. The in-house variant was riskier because it not only had the highest expected return but the lowest — there was a wide spread. In this case outcome 2 is a net loss. We can chalk that up as a future learning lesson (or in my case — past painful lesson). However, let us compare what happens with outcome 2 in both variants. Let us say that despite things not going so well both marketing and engineering have dived in and come up with proposals. There are two options on the table. So, which, if any, do we choose?

• Engineering says they could improve code efficiency by 75% for $350K
• Marketing say they could add 400k extra microsite visitors for $150K each month

Let us go through each variant. In figure 211, I’ve added the financial impact for the proposals on the in-house variant.

Figure 211 — Financial Impact on in-house variant

Since outcome 2 is happening, we will use this as the base case and add the impacts from the proposals. The first thing to notice is that the development proposal doesn’t make the case better but instead it makes the finances worse. Why? Because the cost is already sunk and spending money on refactoring doesn’t improve the financial case as there is nothing to be recovered through code efficiency. The only possible saving grace would be through releasing some hardware to get a quicker sale of it and less depreciated value. That’s in the realm of wishful thinking in most cases. Sadly, it’s often difficult to justify spending more money on a refactoring effort in such circumstances. The marketing proposal however gives us some uplift. At least it recovers some of the pain. Our final expected return is still below our normal of 40% but we’re saving a bit of face. The combination of both development and marketing gives us the benefits of marketing combined with the loss of development. It’s far better to just do the marketing proposal.

Ok, so let us repeat this exercise but now look at the public platform variant which is the one we actually chose. I’ve created the model in figure 212.

Figure 212 — Financial Impact on public platform variant

The first thing to note is we’re in much better shape with outcome 2 because we didn’t have that initial sunk cost of investment. But then something odd happens. If you look at the development option, by spending money on refactoring then we make a much better return. In fact, it’s a huge return! Hang on, how’s that possible? Well simply put, we’re paying for consumption of the utility platform (such as AWS Lambda) based upon our actual use. If you make the code more efficient then you pay less. There is suddenly a financial reason for refactoring code. There are many other benefits with such platforms from consuming services to code re-use but the changes to the way we write, refactor and monitor code are significant. This is what co-evolution is all about and in this case, it’s the collision between development and finance.

The second thing to note is that marketing is a net loss. How is that possible when in the in-house variant it’s positive? On a consumption basis, the cost to acquire and cost of operation for each new user significantly exceeds the additional revenue they create and so it’s a loss at this acquisition price. The marketing proposal doesn’t make sense in the public platform variant because there’s direct linkage of actual cost against revenue. But in the in-house variant, then most of the costs of operation have already been spent in the initial upfront investment. It’s a sunk cost. In which case given we’ve already spent most of the money and we’re actually comparing the acquisition cost versus the additional revenue. The marketing proposal makes sense in the in-house variant precisely because you’ve already blown most of the cost.

But hang on, the third option of both marketing and development looks better than all of them. How can that be? In this case, the reduced cost of each user on the service (because of refactoring i.e. the development effort) means that the total cost per new user (i.e. marketing acquisition plus operational) is now less than the additional revenue they create. The sum of the whole is greater than the sum of the individual parts. Hence the last option gives us the best choice and that’s where we invest. The shift towards utility platforms and billing at the functional level fundamentally changes your entire investment approach in projects. From no more nonsense about additional IT users having a marginal cost of zero (i.e. we’ve sunk a lot of cost and can’t actually allocate them) to refactoring suddenly becoming a financial consideration. The true costs (not just of acquiring but operating) of marketing are hence exposed.

We’re already starting to experience some of those co-evolved practices and this looks like a big change. This is why I created that first platform back in 2005 but as you’ll come to learn, these opportunities jump at you when you embrace the future. But, why didn’t I continue and rebuild the platform after the parent company decided it wanted to go elsewhere? Well, I spent a bit of time working on printed electronics and then met an astronaut but that’s the next chapter.

Something to remember

The one thing I want you to remember from this discussion is that spreadsheets are wonderful but they’re not a substitution for situational awareness. Loop through the cycle, understand your landscape, anticipate change, manage inertia, structure around it and then apply tools, choices and biases to help you decide where to act. Maps however aren’t a substitution for thought, they’re an enabler of it. By now you should be thinking of how you can use maps to communicate across finance, engineering, operations, purchasing and strategy from anticipation of change to organisational structure. As you’ll discover soon enough, this is only the beginning,

Oh and in terms of the original questions, then my answer would be :-

• Do you sign the contract or not?
  Sign it
• If you do sign which variant do you go for (in-house or public)?
  Public platform, variant 2
• Are there any other changes that you would make?
  I would use this as an opportunity to explore a future business

So, did I tell you the story about how I met a real life spaceman? That’s next.

The book so far

Chapter 1 — On being lost
Chapter 2 — Finding a path
Chapter 3 — Exploring the map
Chapter 4 — Doctrine
Chapter 5 — The play and a decision to act
Chapter 6 — Getting started yourself
Chapter 7 — Finding a new purpose
Chapter 8 — Keeping the wolves at bay
Chapter 9 — Charting the future
Chapter 10 — I wasn’t expecting that!
Chapter 11 — A smorgasbord of the slightly useful
Chapter 12 — The scenario
Chapter 13 — Something wicked this way comes
Chapter 14 — To thine own self be true
Chapter 15 — On the practice of scenario planning
Chapter 16 — Super Looper
Chapter 17 — To infinity and beyond
Chapter 18 — Better for Less

This post is provided as Creative commons Attribution-ShareAlike 4.0 International by the original author, Simon Wardley.

Simon’s site and other writings https://www.swardleymaps.com/
EPUB and PDF versions https://www.swardleymaps.com/writings-books#wardley-maps

Super Looper was originally published in wardleymaps on Medium, where people are continuing the conversation by highlighting and responding to this story.

One difficulty that people face with the Phoenix scenario outlined in the previous chapters is the question of role. It’s not unusual to look at the scenario and its corresponding plays such as “pig in a poke” and ask what happens to the people? A common retort is “leadership is all about people and the leader should sacrifice themselves for their people”. It’s a noble idea.

As difficult as it is, you have to remember that in the scenario you are an executive of the conglomerate and your focus is on maximising its advantage. The game is somewhat different if you’re the CEO of the subsidiary. That which brings maximum advantage for one perspective is not necessarily that which brings the maximum benefit for another. There are often many competing interest and many maxima in a single landscape. Whilst the game itself is rarely zero sum (i.e. if I win then you lose or vice versa) as both competitors can often benefit through collaboration, your focus should be on maximising your advantage. The pursuit of such will result in conflict whether it’s with your competitors or the conflict between the shareholders desire for profit versus the consumers desire for lower product cost. There is always some other trade off if you look hard enough.

When you examine a map, you need to go beyond just the landscape, the why of movement (i.e. this choice over that), the why of purpose (to be this or that) and to consider your role and that of others. There are many actors in a map and they have different perspectives. Even the consumer’s view of the landscape can be different from that of the producer. Mapping simply shows you a landscape, you have to apply thought, you have to balance conflicts and you have to strive for your maximum advantage. But isn’t this cold hearted? Aren’t you treating people and that means real lives as dots on a canvas? Yes, it can be dispassionate. But remember, you also have to lead and that requires trust from others. There is a cost associated with brutal corporate action through loss of trust. Which brings us to another trade off as you have to balance present action versus future. Become known as being too Machiavellian, too brutal and your reward will be that too few will follow you. Seeking the path with least conflict, to win the war without fighting and to demonstrate how all can benefit is the pinnacle of the craft of war.

Balancing these conflicts, focusing on your role, removing your own bias and understanding the different maxima that exist is one of the hardest challenges that I know for leadership. Without maps it’s almost impossible to make sense of this in an unseen landscape. Hence we just fall back to gut feel and notions of “it seems the right thing to do”. The practices of mapping are the trivial entry point into this world as the simply expose it rather than solve. The complexity of playing the game is vastly more than just seeing the board, knowing the rules and a few opening plays. I often suspect this is why we relish story-telling, magic frameworks such as 2x2s and secrets of success in management. We paper over a complex world with simple to understand “truths” regardless of how incorrect they are because it makes management easier and gives us a sense of control.

To tease out the concept of role, I’m going to use a generalised scenario that has two variants — one which covers product to product substitution and the other which covers product to utility. I’ll use a single map to describe both and I’m going to focus on the pattern of change from product to utility rather than user needs. You should be familiar enough with mapping by now that such shortcuts are permissible.

The “generalised” scenario

You are the founder / CEO of a company that produces a product. You’ve developed a successful business. You are proud of what you have accomplished and the team you have built. In one variant, your product (point A1) is being substituted by another product (A1 to A2) e.g. Blackberry vs Android. In the other variant your product is being substituted by a utility (A1 to A3) e.g. traditional hosting versus cloud computing. I’ve drawn these variants on a single map in figure 188.

Figure 188 — a changing space

In any business relationship, there are more than just products involved. There is the practice of how the product is used, data about the product, data consumed by the product and even knowledge about the construction of the product. I’ve marked examples of this onto figure 189 for our product. How do I know I’ve put the dots in the right place? I don’t. Maps can be tools for explaining general concepts and in this case, I will just assume that the practice around how to use our product is well developed along with the data that underpins it.

Figure 189 — adding practice and data

Now, let us consider the first variant where our product is undergoing substitution from A1 to A2. We are RIM, our flagship Blackberry product is under assault from a range of new Android phones that have appeared on the market. With such substitutions then the existing data, practice and knowledge of the market tends to be maintained i.e. an Android phone might substitute the Blackberry but the practice of using smartphones, the data around the market and even knowledge about construction & use will tend to incrementally improve rather than be substituted itself. I’ve marked this change onto figure 190.

Figure 190 — a substituting product

Unsurprisingly, we are going to have inertia to this change. A significant source of this will be our own past success often represented by our own sales data, our own marketing collateral and our own reward systems. These systems will encourage us to believe that the change won’t happen and with good reason. Such product to product substitutions are highly unpredictable. Whilst it is easy to look back in hindsight and describe the success of the iPhone, there was no guarantee that the iPhone would succeed disrupt the existing market. In fact, the guru of disruption Clayton Christensen stated that the iPhone would fail.

But, let us assume we’ve often experienced such substitutions and we suspect this is happening now to our product. We might have inertia but we understand its source and how to overcome it. For consumers of our product, there will also be some inertia to the change but as long as the practice remains equivalent then this is often mild. Changing a type of phone used within a company (i.e. from Blackberry to Android) is a far easier problem than introducing the concept of a mobile phone for the first time. The latter requires a fundamental shift in any established practices of communication, the former is simply a refinement. I’ve marked the main source of inertia onto our map in figure 191

Figure 191 — inertia to change

As the CEO of a company facing a potential substitution then my understanding of this change provides me with options. The most common of which is known as Charles Handy’s 2nd Curve or in other words, the exploitation of an existing position in order to create a future position. This second curve works because substitution doesn’t happen overnight. We don’t wake up one morning and discover that the entire world has changed. There is still value to be extracted from the “legacy” position before any crisis point is reached. I can use this time and any revenue created from the legacy to invest in and leapfrog our competitors by building a better or adjacent product that exploits the change in the market. I could even employ a more radical shift or some combination of any of the above with concepts of differentiation.

Since the practice around the activity is unlikely to change then I also have the skills, experience, knowledge, brand (another form of capital), process and data within my company to play this game. I might not however have the culture and there is still any internal inertia to overcome, so it’s not a trivial problem. As a founder CEO, my tendency will often be towards the fight. Words such as “I’ve built this company, I want to succeed and I want to create a glorious future for my people” are not uncommon. In this context then I can create a vision that builds upon our past practice and experience, I can sell a purpose of creating a new future and explain why we need to make this change. There’s never any guarantee to success but as long as I’ve seen the change and react quickly enough then I can often overcome it. This does require a strong will, fast action and a willingness to gamble because product substitutions are unpredictable and you can’t plan for this uncertain change in advance. I’ve given an idealised example of this in figure 192 using the concept of leapfrogging a competitor.

Figure 192 — leapfrogging a competitor

Let us now change our role into that of a hedge fund manager. In this case, I’m left with a bit of quandary. We’ve seen the appearance of a product that might substitute the company’s but there is no guarantee that it will. This means that I don’t know which company to invest in for the future, it’s a gamble. Also, if the CEO of the company being substituted is switched on then they might play a comeback with a second curve and a new product. Apple is one of those companies that has successfully played a second curve several times bringing us new products from the iPod to the iPhone to the iPad. A lot depends upon my confidence with the CEO and whether they have done this before. My tendency would be to hedge my bets here and closely monitor.

Here we have two distinct roles, that of CEO (and the options you might play) and that of the hedge fund manager. However, the desire of the founder CEO to create a future for their company can be easily aligned with the desires of the hedge fund manager. There might be tension but there’s no real conflict between the roles. Whether the two views are aligned is often more a question of confidence and whether the right culture exists.

Play it again

Let us now play this scenario again and consider the second variant and the substitution of the company’s product by a utility (e.g. A1 to A3). Along with inertia, there are a number of complications caused by common economic patterns. The first complication is caused by co-evolution of practice. As with more recent examples (e.g. cloud computing and the rise of DevOps) then the changing characteristics of the activity as it evolves from product to utility will result in co-evolved practices. This will also apply to any data and knowledge of the space. I’ve marked this change in figure 193 focusing in on practice.

Figure 193 — co-evolution of practice

It’s not enough to simply react to the change of activity, we have to understand that the entire practice and associated components will also change. The second complication is that changes from product to utility tends to exhibit a punctuated equilibrium (a rapid period of change), so we have to deal with not only legacy in product but legacy in skill-sets and cope with this in double quick time.

The third complication is the “legacy” practices, data and knowledge will significantly reinforce inertia to the change at a time when change is rapid. This doesn’t help me to adapt nor give me much time to exploit the legacy but alas it’s far worse than that. My ability to perceive the crisis point will be diminished by the statements of confidence in the current way despite the simple fact that in this case, the shift from product to utility is anticipatable in advance. As the CEO you will be told from all directions why this change won’t happen, your sales team will tell you this, your own engineers are likely to say this and even your customers. Despite the inevitability of the change, you are given every reason to believe that it won’t happen. The same happened in cloud and it has happened many times before.

In a short period of time, we will have a change of activity, a change of practice and three major sources of inertia to contend with. Our past sales data, the change of practice itself (which will be resisted by our own people) and the impact of a change of practice on our customers (they will also tend to resist) will try to dull our senses and demand we stay put. I’ve marked these sources of inertia onto figure 194.

Figure 194 — three points of inertia.

But, it’s even worse than this. Not only do you have to overcome multiple sources of inertia but the fourth complication is your choice of direction is far more limited in scope. Beyond niche specialisation, there is no product option in a utility world. You can try to substitute the competitor’s utility with your own but this is a very difficult game especially if you don’t have the skill-sets and the capability to do this. If you’re dominated by legacy practice, data and knowledge then it is highly unlikely that you will have that capability. Any alternative path you wish to introduce will need to be far more radical. You might think that companies can play a second curve in this position and build a future whilst exploiting the past but the mechanics are so different, the practices so alien and situational awareness often so poor that the crisis point is usually upon them when most are still debating if there even might be a future crisis point. To compound this, they have none of what they need — none of the practice, none of the data and none of the knowledge.

However, let us assume that you’re a canny CEO and you know these problems. Your desire is still to build that glorious future. You want to play the second curve game and understand there is limited opportunity in the utility space as you’re late to the party. Instead, you’re going to create a radical new future. You’ll have to completely reinvent a “successful” company with not only a new set of uncertain activities but also a new set of uncertain practices. This is about as radical as it gets, it’s an enormous gamble even as a startup but you’ll be trying to do this with an existing company with a legacy business that not only wants to fight you every step of the way but few will understand why you are embarking on this route. Talk about the Augean stables, this is not going to be an easy or pleasant task.

This doesn’t mean it cannot be done but the level of situational awareness and gameplay required are off the charts. There’s a long history of CEOs trying to implement radical and poorly understood changes being ousted by boards. I’ve seen numerous successful examples of the second curve played out in product to product substitution but by the same measure I’ve seen as many second curve failures played out in a product to a utility world. All the past giants of computing infrastructure that tried to play a second curve game against the new cloud entrants have failed with the possible exception of Microsoft. But then, Microsoft wasn’t a hardware company under direct assault and it had more space to play the game in.

Of course, it doesn’t have to be this way. This form of change, the substitution from product to utility, can be anticipated well in advance and there is no reason a company should find itself in that position. Naturally, almost all companies fail anticipate it because they lack any form of situational awareness or mechanism of systemic learning. Most don’t understand basic economic patterns and hence fail to anticipate and prepare for them. Whether this is fortunate or unfortunate is a question of your perspective.

However, let us assume that your company faces this dreadful position of being substituted by a utility but you are Queen Boudica, the warrior leader, the stuff that legends are made of and you won’t give up the fight. Well, it’s not only your company, your staff and your customers who are going to fight you in your pursuit of a better future — it’s also the financial markets. To explain why, let us one again switch to the role of the hedge fund manager.

The Hedge Fund Manager

To begin, let us focus for a moment on cloud computing. It represents a timely expression of this form of product to utility substitution with a rapid period of change and co-evolved practices that were all highly anticipatable. At the same time this is occurring, there is also a significant legacy of activities and practice. So, ask yourself the question of where do you invest? The immediate response tends to be — “in the cloud space” — because that’s now seen as the future. But this wasn’t the case in 2008. There was still lots of uncertainty in the market due to poor situational awareness despite the change being highly anticipatable. Let us assume that you are that rare beast, a hedge fund manager with a good helping of situational awareness. You don’t tend to be caught unawares by highly anticipatable changes. You’re not the sort of person who lets go of the glass of wine and complains in surprise that it fell to the ground rather than levitated through the magic of thought leadership. You know that there are precise and meaningful patterns in life and incantations of “ecosystem, innovation, platform, abracadabra” don’t actually work.

In this case, you will understand that for you then longer term capital gains will be made by investing in that future focused space i.e. those utility providers. However, you’re a canny sort and know this is only part of the story. There is also the potential for shorter term benefits as companies provide services to those with legacy activities and practice. As the hedge fund manager you should be aware that the legacy will eventually diminish but there exists money now. Any short term benefit depends upon those companies operating in the legacy space focusing on returning capital to shareholders.

To maximise my advantage, I’d be looking to invest in the long term capital gains from those developing the future industry but at the same time reap short term benefits (in terms of dividends) from those extracting value from legacy. However, I’m assuming that the CEOs playing in the legacy space know their role. The ideal situation is a CEO that is sweating legacy business models to return value to shareholders often combined with acquisition of equivalent business (again for synergies i.e. more sweating). As a hedge fund then I’m after a “rent extraction” machine — “up those license fees, squeeze those costs, return that capital” is the motto! Of course, eventually those companies will run out of runway i.e. there’s no-one else left in the legacy space to acquire or there’s no more cost cutting to be done and the business model will continue to decline. From a hedge fund perspective, this is also fine because you’re also already invested in the future. Shortly before the cracks start to appear in the legacy space then I’d be moving capital out and starting to short. Trebles all round.

This play of “sweating” an existing business is very different from the second curve. There are many variations of the play from sweat and dump (i.e. disposal of the legacy) to sweat and acquire (i.e. buying up similar assets to gain greater opportunity for cost cutting & efficiency). They sound brutal but they have a number of discrete benefits. For the hedge fund it means high short term dividends. For the executive, it maintains and can even grow share price for a time. This sort of play can often sustain a legacy space for a decade or more. However, it’s important to understand your role. If you’re an executive in such a space then your role is to sweat and return dividends. You have to maximise this local opportunity until it is overwhelmed by the debt of the past. But, as a founder CEO of a company in that legacy position then you are likely to ask “what’s the plan for the future?”

Tricky. The honest answer is probably none. I’ll come to that “probably” in a moment. Your role is to sweat, return capital and disappear over the horizon — well, that’s the investment view. Let us just say that most founders don’t react well to this. However, as the CEO, you need to realise that you’ve not only got your sales team, employees (with the exception of a few rebels) and customers fighting against your attempts to make a future but if you’re really unlucky then you’ve probably also got savvy hedge fund managers trying to dissuade you of the notion. Your future is one of rent extraction and the cliff, hardly the glorious image that most hope to create.

As the CEO, you can try and push back against the hedge fund but they will tend to fight you. As the fund manager then I would have already invested in those new entrants that are building the more certain future with their utility services. Anything you spend is capital that you should be returning to me not gambling on some uncertainty. I’m investing in you to maximise the local conditions and it’s returning dividends that is keeping your share price and your rewards up. Get this wrong and you’ll find the financial markets can themselves be a significant source of inertia to changing direction. From a point of view of the market, this is actually fairly optimal. The legacy is removed whilst the future flourishes. Your role in such a position is one of legacy removal and the market will not reward you for not playing that role.

In the first variant (product to product substitution) then as the CEO you’re playing a second curve because it’s the right context specific play. You’re trying to build a new future given a possible substitution of your core product set and an impending future crisis point. You can often achieve this because you have the skills (i.e. capability), process and data to support such efforts. In the second variant (product to utility substitution) then as the CEO you should be playing some form of “sweating” game because it’s the right context specific play. You’re not trying to build a future, not trying to run a second curve but trying to extract as much value as possible before the system collapses. The nature of what you do, your role in the game, changes with context.

“What if I want to build a future?”, “I refuse to go quietly!”, “What about the people!” are often phrases I hear especially with founders when we discuss this. Well, you can’t tell employees that the company has no future and so you probably need to play a bit of theatre and paint a picture of one.

“That’s dishonest! I want to build an actual future!” are often common replies.

Well, there is an upside to playing the game. “Probably none” doesn’t mean none and there is a path though it’s not an easy one. The odds of you achieving a future position without exceptional situational awareness and a culture to match are not great but they are something. Leadership is neither easy nor is it necessarily comfortable. The first advantage of playing along with the role is that you’re buying time. This gives your employees more of a future (which I’m sure they would thank you for) and so as unpalatable as it is (the waves of cost cutting) then consider it a more graceful withdraw for the company from the market. With skill this can easily last a decade a more. However, we can go one step further and create a future assuming we don’t make the grand mistake.

The grand mistake

This is known as the spiral of death and it is one of the most commonly repeated mistakes in business. It’s also a company killer. Let us assume that the shift from product to utility (what I describe as the “war”) is upon us and we’re in the position of “rent extraction” from a legacy. Capital is already flowing from our industry into new industries whether more evolved utilities or higher order systems that have been created on top of this. We’re watching this marvellous new world forming but we are on the sidelines. The good news is we’re maintaining our position for now through some form of sweating play. You’re going through the fairly difficult time of constantly cutting costs in order to restore profitability and return dividends even though revenue is declining. You may be acquiring and performing more of the same. It’s a tough spot especially when you look at spectacular growth elsewhere. Your problem is the revenue will continue to erode due to evolution in the value chain. You need to somehow respond by adapting and possibly moving up the value chain despite the resistance and any inertia created by your legacy customers, your sales data and often your own people. But the financial markets are demanding more and you know you’re going to have to cut deeper. It’s a bit miserable but there is a path to the future.

The grand mistake is that we tend to cut away exactly the things we need to create that future. In any layoffs for example, it is very easy to use metrics based upon performance in the “past” world and therefore remove those seen as less successful in that previous era. That doesn’t sound too bad but the result is you end up with a higher density of people successful in the past models (which are now in decline due to evolution) and hence you’ll tend to reinforce your cultural inertia to change. Whoops.

Unfortunately, we also tend to remove the radicals, the trouble makers and the pioneers. Again, that doesn’t sound to bad because we’ve got to become more “efficient”. Unfortunately, those often annoying people are also the ones most likely to stick a soldering iron into a pot of ink, create inkjet printers and save the company. Whoops again. To compound this even more, we often cut far deeper than we need because we reward those with past success in order to retain them. In our effort to keep the past going we’ve cut away those very things which might give us a future. Our revenue then declines further and the spiral continues.

Much of this spiral of death played out in RIM as it attempted to cut costs, return to profitability, reinvent the past and found itself lacking in the capability it needed to create a future. In the most ironic examples, you often hear companies that have undergone aggressive cost cutting talk about their need for talent (often as “the war for talent”) in order to create a future and how they want to transform e.g. “be more like Netflix”. The irony is, if they actually asked Netflix where they got their talent from, they will often point back at the very same companies with the line “we got it from you”.

I have sat in that room listening to an executive talking about building a future team like this or that “Silicon Valley” group whilst knowing that the very same team that the executive proclaims as the future was made redundant by the company eighteen months previously. In the worst cases, the very team that was carelessly disposed of cannot now be literally afforded. In one case, I was even asked how much it would cost to rebuild Fotango. With the original team? Today, given that many are millionaires and some run Unicorns? An eye watering sum.

So let us assume, that as a canny CEO that you’re not only playing the game to buy time but you’re being careful not to invoke the spiral of death by reinforcing your own inertia and removing the radicals that might save you. What are you playing for? The lucky break.

Phew, that was close

The “sweating” game buys you one thing — time — but don’t waste it. As much as investment companies might want you to return capital, you need to resist this to some extent. A bit of experimentation added with time can sometimes find you the radical route into a brave new world often in an unrelated area. Take IBM today, after 19 consecutive quarters of declining revenue and no let up to the woe then you’d probably conclude they are in a tough spot. They’re betting on Watson (and other initiatives) but at the same time other larger players — Amazon, Google, Microsoft — are circling in that space. It’s tough, it can’t be easy and lots of job cuts have already happened. But cutting costs buys IBM time, it gives it more chance to keep rolling the dice for that lucky break assuming that they’re not cutting away the radicals, the pioneers and the very people who might save them.

What might that lucky break be? Who knows, the uncharted space is uncertain which is why you have to experiment. Maybe they’ll turn Watson internally and create the first artificial intelligence CEO — that would probably terrify the strategy consultancy industry. Maybe their future is being acquired and getting squeezed in some grander game to buy time. Oracle? Who knows, the actions of other actors are difficult to determine. All you can hope to do is play for time.

If you get your lucky break, you will of course be able to claim that you played the second curve as you build a glorious new future. I’d ask you not to forget that you got lucky but chances are that survivorship bias will overwhelm you and you’ll craft some epic tale to rationalise it all. There’s nothing wrong with being lucky but for whatever reason it doesn’t normally fit the CEO narrative. The desire for magic secrets is fairly compelling and whilst more likely to be honest, the story of success through “pure blind luck” doesn’t fit the bill. That said, using a “sweating” play to buy time in order to maximise your chances to find a lucky path out of trouble is a perfectly reasonable rearguard action. Your goal however is the experimentation and to pray to the fates. Hence the importance of not going around removing the very capabilities that you need to come up with that lucky break. You have to be very careful with where you cut. It’s hardly the more forward thinking, purposeful and deliberate play of a second curve or preparing for the inevitable industrialisation of a space in advance but it gives you a chance.

The scenario above concerns substitution, one variant is product to product, one is product to utility. The way you play the game, your role in the game and how you’ll be treated by others are very different. Obviously I’ve simplified the “generalised” scenario because most companies have a diversified set of offerings, so the actual play depends upon your context. It’s also why position and movement are critical i.e. finding yourself in a position of having an entire legacy product set being substituted by a utility is entirely preventable as it can be anticipated. Equally, you should be playing the second curve game when you’re riding high on the product wave and not when things are starting to go south.

Unfortunately, you can find yourself at the helm of a company where the decisions that should have been made long ago weren’t and the position is woeful. Your range of options is often curtailed by past bad choices. One of the other saving graces is that situational awareness is not only poor in companies, it also turns out to be poor in investment houses. This might not solve your problem in the product to utility case by creating a future but it can provide a route to selling a bigger story and creating a perception of one. This can buy you even more time as you try to work your way out of the problem.

Will the maps help me?

Maps unfortunately don’t tell you what to do. They are a means of communication, collaboration and learning patterns. You have to apply thought and find the most probable path to survival and success but there is always the lucky break and its nemesis the Black Swan. That process of decision and the application of thought to a map is wrapped up in your understanding of the landscape, the climatic patterns impacting it, your understanding of gameplay, your role (as perceived by yourself and others) and ultimately choice. There is always an analytical and emotional element to that choice which is why it is so draining. The analytical side will tell you what is likely to happen, where not to invest and where you might invest. However, parts of the map are uncharted (“Ere be Dragons”), parts are uncertain (product to product substitution) and the gameplay of competitors is often unknown. Whilst we know that the industrialisation of one thing (such as electricity) opens up adjacent possibilities of novel higher order systems (e.g. radio, TV, refrigeration blankets) it is not possible to say which one of those will succeed. In the end there is always an element of gut feel and leading the charge. This cannot be removed but neither should it dominate everything.

Leading the charge is also important because we have to act. It’s movement which is the key to learning. Without movement, we do not discover, we do not explore, we do not learn and in most cases, we simply die. Maps simply provide a systematic way of learning, of not repeating old mistakes, of applying patterns from one context to another and not blindly marching to your doom along a well trodden path with signs saying “doom, doom, ‘ere be doom”. Of course, you might still decide that this is the best path for you. Maps don’t tell you what to do, they help explain the landscape.

Common failures of sensible executives

With that in mind, I buried several common failures of sensible executives within the Phoenix scenario in the previous chapter. It’s worth going through those now. Do remember, that people aren’t daft. Executives don’t make these mistakes because of a lack of wit. The problem is blindness. If you cannot see the board whether visually or through some mental model then you cannot learn patterns and you are moving in the dark, stumbling from one step to another as though it’s the first step you or anyone else has ever taken down that well trodden path. It may be well sign posted with “doom, doom, ‘ere be doom” and a hundred other companies may have walked along that path and met “doom” but without a map, you’re going to feel it’s an undiscovered path to future success. This is especially true if you’re unfortunate enough to attend that one conference with a CEO talking about how they built a successful company by travelling down that path and it wasn’t “blind luck”. One person’s survivorship bias can be a killer to others.

We often bemoan CEOs over their pay or lack of performance and whilst in some cases it is justified, many are caught in a world not of their making, trying to navigate without any understanding of the landscape whilst bombarded by inertia & magic solutions. This is also why leadership requires fortitude. Being in a position of having to make the hard choices and the physical and mental exhaustion of playing the games is one of the reasons why I don’t seek leadership positions. I’ve often found myself in that position out of necessity but why anyone would seek to be in that position is beyond me. Anyway, assuming you’re unlucky enough to find yourself in the role then, a few common mistakes:-

Expand into an overseas market
When our existing market is undergoing a shift from product to more commodity (or utility) then there is often the temptation to avoid the problem by selling into a less developed market. This can buy some time but at the cost of increasing inertia to the change that’s needed. You’re actively avoiding the problem and the competitor will not only chow down on your existing market but the one you’re busy helping to create for them.

We need to innovate more
The problem with trying to innovate your way out of a war (i.e. substitution from product to utility) is that the creation of the novel and new is highly uncertain by nature. It’s a gamble. However, this is not what most people actually mean when they talk of innovation. What they’re really saying is we need to “innovate” around our product i.e. “We need to differentiate”.

Well, in this case it’s far too easy for the competitor to play a tower and moat game by copying any successful innovation you create for a product. To explain tower and moat, let us switch roles for a moment and become the company that has launched a utility service into a market that is surrounded by products. You occupy the future position and know full well that your competitors will have inertia to the change. They will often react by not only spreading fear, uncertainty and doubt but by trying to differentiate their product offerings with some form of “innovation”. What you do, is copy and add these to your utility service. Your focus is to build up a tower of revenue (your utility service) surrounded by a huge moat devoid of any differential value.

The competitors efforts to innovate in a product world end up just enhancing this by helping you to copy and grow the moat. When the competitors finally wake up and make the plunge into our future market then they’re likely to have been delayed because of efforts to differentiate their products with new fangled things (not a good move in a punctuated equilibrium i.e. rapidly changing market) and they will actually have nothing different to offer. This is pretty much a disaster. So, now let us switch back to our role as product player. If our response to a utility provider entering into our market is “innovate” then as long as it’s truly radical and entering a different market and assuming we’re aware that this is a huge gamble then it’s a reasonable move. If it’s “innovation” around a product then I hope you can see by now what’s going to happen. Bad move. “Doom, doom, ‘ere be doom”.

Beyond the whole “tower and moat” play then attempts to differentiate a product in a game of utility substitution brings two other dangers. First there is the existing consumers inertia to change which is often represented by a desire to maintain the existing model rather than to adapt. They will encourage you in this differentiation play and it becomes very easy to be seduced by it. The problem is that as their competitors adapt, the pressure on them mounts to adapt (the Red Queen) and though they tell you they want the past, they often end up buying the future. There’s no point in complaining that “this is what the customers said they wanted” as it should be obvious by now that what a customer says they want and what they actually need are often not the same. This is also why mapping doesn’t use an anchor of customer want but uses need instead.

The second problem depends upon whether your competitor is using some form of ecosystem model. If they’re using an ILC (innovate — leverage — commoditise, see chapter 5) model then their rate of apparent innovation, efficiency and customer focus will all increase with the size of their ecosystem. This means as much as we try to out innovate, we can easily be overwhelmed by their ecosystem. For example, look at Amazon Web Services. When you consider AWS, don’t think of it as going up against a company with a rapidly growing $12bn in revenue and thousands of developers instead you’re taking on the entire AWS ecosystem. You should think of the ecosystem as Amazon’s entire R&D effort and ask, do you really have what it takes?

We need to cut costs to return profitability
Whilst cost cutting can be useful to prolong the past and buy time, be careful to avoid the spiral of death caused by self-reinforcing inertia. The past is going, you need to accept this. If you’ve been caught in such a legacy position then understand your role. Either you’re heading for the cliff and aiming for a well padded retirement or using this in the hope of a “lucky break” hence you’re buying more time and encouraging experimentation.

We need to price cut
Price cuts are a perfectly useful form of gameplay but again be careful. Unless you understand the competitor’s value chain then you’re unlikely to know if they have constraints which limit their own price reductions. It’s very easy to get into a game of last man standing with a competitor that has significantly more potential for price reductions than you do.

We need to focus on core
In a time when those core parts of your value chain are evolving to a more industrialised form, then this can often become simply reinforcement of inertia combined with wishful thinking. Core is a transient concept and as such, it changes.

All of the above can equally be useful, if applied in the right context. But what has this got to do with the practice of scenario planning? This entire chapter has been all about introducing you to the concept of variants, of different possible scenarios, of different roles, of different contexts and the interplay between them. With this in mind, let us plunge into another scenario.

The “LFP” Scenario

Who are you?

You are the CEO of a small software company with 100 employees. You have been approached by a global conglomerate that is interested in commissioning your company to build them a new service.

The service

The service should be designed to help sell large format printers (LFP), one of their main products. Each LFP sells for in excess of $2,000. The service must consist of: -

• a microsite for potential customers interested in finding out more about large format printers. The site should provide a link to an online testing application.
• an online testing application for potential customers to upload an image and have printed on the LFP of their choice. The visitors to the testing application can either be direct (i.e. through marketing) or indirect (i.e. via the microsite).
• a back-end system to distribute the printed image to the potential customer including a brochure on the LFP used and a follow on sales call.
• each delivered print will be considered a lead.

Because of past bad experiences, the client has moved towards more value based contracts (known as worth based development). They would like you to invest in, build and operate the service and they will pay you $40 for each customer lead delivered. You will retain ownership of any IP related to the service, though there is a clause for exclusive provision to the client for the length of term of the contract which is one year.

Sales and Marketing

Sales and marketing feel this is a good project because of the brand name. They’ve examined the LFP market which has a CAGR (compound annual growth rate) of 4.5% with over 310,000 units shipped. Currently the client represents around 15% market share. Though it is considered to have the best LFP products in the space, it has also seen as losing ground due to weak marketing. Sales highlight that if successful then this project could be sold elsewhere, the potential market is significant and it provides a valuable in-road into the client for other projects.

Project Management

Your project management team are keen to try working on an outcome basis. They argue that this is a potential future model which might solve many of the client conflicts they’ve experienced in the past. Gaining experience in such a space seems worthwhile. They’ve looked at the client figures and developed a financial model with systems, development, marketing and finance.

Finance & Legal

Your CFO is cautious and points out that there are some significant downsides if things go wrong. For example, one possible outcome is we end up with a net cash outflow of almost $800k before disposal of any assets. There is unfortunately a complication which the CFO highlights. There are two competing proposals for building our solution. One is to build using in-house infrastructure (a build “in-house” variant), the other is to build using a public code execution environment that provides charging at the functional level based upon consumption of resource (a build “public” variant).

The net effect of this is the build “public” option has higher but more variable costs whereas the build “in-house” variant has significant stepwise increases in investment once the service exceeds 100,000 users per month. These stepwise increase are due to additional development (requires a more distributed architecture), the infrastructure itself and hosting. Legal points out that once we sign up to the contract, we’re responsible for providing and funding the service for one year and hence if we get this wrong, we have to fund the investment regardless of whether we see a corresponding revenue increase. Given the uncertainties, the CFO has modelled both the “in-house” and “public” variants of the scenario with each examining four possible outcomes. The outcomes vary according to:

• the number of direct visitors to the testing application
• the number of microsite visitors
• the rate of conversion of microsite visitors to use the testing application (indirect visitors)

The CFO is unconvinced by marketing’s conversion rate from total visitors (i.e. both direct and indirect) of the testing application to leads. Given we’re being paid by the lead, the CFO views this as critical. The CFO agrees that marketing has put together a compelling case of how the service will be a roaring success but highlights that no-one seems willing to provide a probability for each of the outcomes. There is a lot of uncertainty over which of the four will be more likely.

In terms of operational cost such as print and distribution, the CFO is more satisfied that we have a good handle on this. The CFO also notes that the in-house solution does return hardware assets that have value after depreciation is considered. These could be disposed of or repurposed but we have a somewhat less than perfect record here. The normal ROI (return on investment) the company expects to make on any project is around 40%.

The two variant models (in-house, public) of the scenario, each covering four possible outcomes are provided in figures 195 and 196. The figures are provided as a “best guess” estimate of the four outcomes. What the actual outcome will be is uncertain. In the “in-house” variant, some disposal figures have been provided for the in-house assets assuming these are not repurposed.

Figure 195 — The “in-house” variant modelled on four outcomes

Figure 196 — the “public” platform variant modelled on four outcomes

Engineering

Development has also provided a map of the space which covers both the “in-house” and “public” variants. The difference is simply explained as a shift from a more product style of platform (requiring us to build, maintain and operate our own product stack) to a more utility environment. One significant change with this shift is function based billing through which greater transparency, clarity and variability on IT expenditure can be achieved.

These environments are relatively new but development believe that building skills in this “serverless” space (the common term used in the market for public code execution platforms despite the obvious existence of servers under the hood) is essential for future competitiveness. The map is provided in figure 197 with point 1 being the in-house solution and point 2 being the public platform solution. The CFO has marked on various metrics used in the above models.

Figure 197 — A map of the landscape

Systems and security both have concerns. Whilst security is concerned over the lack of experience in this space, it also recognises a necessity to develop appropriate skills. Systems highlights that it has ample skills in developing such environments and it can build the environment more effectively than a generalised public provider. There’s a bit of derision about the “serverless” term. The head of systems also says that by embarking on a route of using an untested public service for such a visible and important project then we’re sending a worrying message to the systems team.

The board

The board are uncomfortable with this project preferring the more tested routes of contract negotiation that the company has established. However, though not comfortable there is no objection to it.

Your choice

You have the map, the background and the financial models. You need to consider the landscape, the roles involved, your role and what’s the best way to play this game. Once you’ve signed the contract then the company will be taking the risk and paying for an early stage investment. That early stage investment may significantly rise depending upon which outcome starts to emerge.

Given everything you’ve been told, you now need to decide: -

• Do you sign the contract or not?
• If you do sign which variant do you go for (in-house or public)?
• Are there any other changes that you would make?

The book so far

Chapter 1 — On being lost
Chapter 2 — Finding a path
Chapter 3 — Exploring the map
Chapter 4 — Doctrine
Chapter 5 — The play and a decision to act
Chapter 6 — Getting started yourself
Chapter 7 — Finding a new purpose
Chapter 8 — Keeping the wolves at bay
Chapter 9 — Charting the future
Chapter 10 — I wasn’t expecting that!
Chapter 11 — A smorgasbord of the slightly useful
Chapter 12 — The scenario
Chapter 13 — Something wicked this way comes
Chapter 14 — To thine own self be true
Chapter 15 — On the practice of scenario planning
Chapter 16 — Super Looper
Chapter 17 — To infinity and beyond
Chapter 18 — Better for Less

This post is provided as Creative commons Attribution-ShareAlike 4.0 International by the original author, Simon Wardley.

Simon’s site and other writings https://www.swardleymaps.com/
EPUB and PDF versions https://www.swardleymaps.com/writings-books#wardley-maps

On the practice of scenario planning was originally published in wardleymaps on Medium, where people are continuing the conversation by highlighting and responding to this story.

The hardest thing about mapping is coming to terms with a simple fact that there is no right answer. Mapping enables you to observe the environment, the constant flow of evolution and moves of other players but it won’t tell you what to do. There are alas no simple steps for you to follow to success. There are no plans that guarantee to bring you a fortune. I face this obstacle regularly when companies ask “how will mapping benefit me” to which the answer that “it depends upon what you observe and then what you do” is seldom welcome. They often want the concrete, the definite and a world of levers you can pull or buttons you can press. I long to say “By turning this mapping dial you will save 12% of costs” or “press the mapping button to increase your rates of successful innovation by 34%” but it just isn’t true. The benefits are context specific and they depend upon you.

The journey of mapping is one of abandoning the simple mechanistic world and embracing an iterative path of learning. Yes, there are patterns we can learn. Yes, there are universal principles we can apply. Yes, there exists context specific gameplay. Despite this and in spite of our ability to observe the environment, it is still awash with uncertainty. The uncharted is uncertain, the timing of various patterns are uncertain and the actions of others are uncertain. Even the future value of something is inversely proportional to the certainty we have over it. The more uncertain, the more risky and also the more potential value. Evolution itself, the very heart of these Wardley maps, can’t be measured over time and instead we have to measure over certainty. This use of uncertainty is an intrinsic part of learning to map but as any map shows, not everything is uncertain and even the uncertain can be exploited.

Fortunately nature has provided us the ability to cope with this, to be resilient and to learn from a constantly changing world. This ability is known as cognitive reasoning or in layman’s terms the application of thought. We can use the patterns and our understanding of the landscape to try and create a more favourable result. Sometimes we will get this right but more importantly, sometimes we will get this wrong. Every failed attempt is an opportunity to learn, assuming we use a systematic method of learning. Every mistake learned can be taught to others, assuming we use a common method of communication. There is a lot of future value in error. By learning these patterns, it helps us constrain the bewildering number of possible moves to the adjacent probable. Hence we learn that the industrialisation of artificial intelligence to commodity components and utility services will enable a rapid growth of new things built on top of it. We just can’t say what those new things will be but we can prepare for this change.

Sometimes the lessons learned from mapping are nothing more than “Ere be dragons”. This is true of the uncharted space which contains highly risky and uncertain sources of future value that require us to experiment, discover and gamble. Other times the lessons are more concrete such as the the shift from product to utility will result in co-evolution of practice. Embracing this spectrum from the uncertain to the certain, from the unknown to the known, from the uncharted to the industrialised is for many the most uncomfortable bit of the journey.

So to the exercise at hand. I will explain with maps my reasoning to the choices that I would make in this scenario. My reasoning is not the “right” answer but instead it is simply “my” answer. It maybe the case that you read this and say “I wish I’d thought of that” or maybe you have a better answer in which case I’d be delighted to learn from you. Challenge, communication, learning and embracing uncertainty are the very core of mapping.

My play

Back in 2008, when I was faced with the situation that our scenario is very vaguely derived from, it had taken me about 45 minutes to scribble out a map on pen a paper and work through to an “answer”. In case you need a map for the scenario, I provided their chosen strategy (figure 181) and a map for on which I’ve outlined the strategy (figure 182)

Figure 181 — The Phoenix Strategy

Figure 182 — Map with strategy

As discussed in chapter 13 — Something wicked this ways comes — then I view that the strategy is about as poor as you can get. To cap it all off, the company itself has serious flaws in its makeup and composition. The CEO supported by a group of well trained executives is boldly charging the army over a cliff whilst trying to get rid of the one person who might possibly save them — the former CIO.

To work through this problem to final a possible answer then we need to first distinguish where we could attack. Even on a simple map like this then there’s lots of points we could focus on. It’s much the same with a game of chess, there’s usually a huge number of potential moves you could make. The trick is sorting out which ones are of interest and that takes experience and practice of the game. In figure 183 I’ve listed the obvious wheres on our map ignoring the more wishful thinking such as “buy up the Chinese sensor manufacturer”.

Figure 183 — the wheres

1. focus on marketing towards our users.
2. develop new and uncertain capabilities.
3. exploit the Brazil market
4. sell the company
5. exploit inertia in customers to the change
6. build a cloud service
7. build something with the new emerging practice
8. dispose of the legacy
9. industrialise the data space
10. exploit inertia in the industry around the China sensors.

In such an map, there are always many paths. One path describes how the company thought of its future and the strategic choices it was making. It’s quite clear that the company could not see the threat of the sensors and co-evolution of practice or how dangerous the US company was or even how it had inertia to change. In all likelihood, such a company wouldn’t even understand how things evolve. In their mind, they might have an unwritten map but it’ll look more like figure 184. To this company, their strategy makes sense because they don’t understand how the landscape is changing. The commodity sensors are just a disconnected component which they believe they have choice over or the cloud is just an optional choice. They have none of the anticipation that is brought on by an understanding of climatic patterns

Figure 184 — the Phoenix map

That said, they were motivated. It’s a judgement call here as to whether an organisation can be altered in a time frame that enables you to exploit an environment. In this case, given the principles (i.e. doctrine) exhibited then I’d say not. There isn’t enough time to alter the company and go head to head with the US competitor, this is a battle better withdrawn from for now.

However, I have several secret weapons. First, the US competitor is using the same expensive sensor and they probably have their own internal inertia to change given their success in the US which means their code base will become legacy. Secondly, just because I can anticipate the future situation then that doesn’t mean the market can. From the analyst reports and interest in acquisition we know that Phoenix is seen as a bit of a star in the market. Lastly, we also have that CIO who shows some promise, some insight, despite the company’s attempt to get rid of her.

Applying a bit of thought to the map, another path now becomes available or in this case two paths as it’s a combination of simultaneous plays. I’ve marked these in orange and grey on the map in figure 185.

Figure 185 — my play

The grey play — Pig in a Poke
I’m going to sell this company (grey point 1). I’m going to want to maximise my return which means I’ll put effort into marketing (point 2) and promoting Phoenix as the future in this market, reinforcing those analyst messages. I’m also going to encourage the marketing team to heavily play on concerns over any cloud effort (point 3). Hence a bit of fear, uncertainty and doubt (FUD) is useful.

I’m not going to give up on our cloud effort, I’m just going to recommend the cloud project is cut down to less than a million and run as a prototype / experiment. I’ll also pull back on the expansion into Brazil. I want to make sure the company costs are kept down and the company is seen as attractive as possible. I’d also agree that we need to use the data product in the market and look to downsize the team in IT responsible for that. In fact, I have another purpose for them. Whilst, my fellow board members would be aware of this play, I wouldn’t explain it in this way to the executives of the subsidiary. They’d probably disagree, they have oodles of inertia and I don’t want to dampen their enthusiasm. To them, I’d explain one story which is :-

“I agree on the marketing push in our existing market and focusing on our product development. I share your concerns over the security issues of cloud and the competitor being forced to eat their own ecosystem. I wouldn’t like for us to be in that position. I’d like us to scale back on our cloud project for the time being and run a few small scale experiments. I do like the idea of entering the Brazil market but right now I think we need to concentrate on the European market, I wouldn’t want us to lose ground to the US player because we’re focused elsewhere. However, I completely agree with the efficiency drive and removing the in-house capability regarding the dataset. I also agree we should watch the Chinese sensors but our focus needs to be on building up profitability within Europe and making Phoenix soar.”

I’d also have a quiet chat with the CEO about the problem CIO and offer to move her to another group in the conglomerate in order that the CEO can focus on the task at hand. I’d suggest we have another project which could possibly do with some of those un-needed IT people as well.

My real goal here is pig in a poke, I want to maximise the capital returned through the disposal of the subsidiary. Before you state that no-one in the market would buy Phoenix then print out the the scenario (chapter 12) and try it out on a group of executives. To make your life easier, I’ve provided a link to a pdf of the scenario. If those executives don’t know how to map, they’ll probably choose the cloud, Brazil and efficiency efforts around data. If you talk to them about whether they think Phoenix has potential, then most will say yes. These are the people you’d want to be selling Phoenix to.

The orange play — the Future

Whilst the grey play is all about making significant capital through a disposal of Phoenix, the orange play in the map above is all about building the future.

I do want to build that cloud service (orange point 1) but I want the technology based upon the emerging practice that will develop around the commodity sensors (point 2). I’m going to create a secret project, a separate subsidiary to do this and I’m likely to put the CIO I’ve just nabbed in charge. I also want to consider looking at driving these emerging practices to become more standard through an open approach (point 3).

I won’t be building the service in Europe but in Brazil (point 4). Firstly this is an untapped market but secondly, I want to keep out of the fight between Phoenix and the US player in Europe. Once the new service is established in Brazil and after my disposal of the Phoenix subsidiary then I’m going to look at expanding from Brazil into Europe and the US by exploiting the weakness of those competitors (i.e. their legacy code base based upon expensive sensors). For good measure, I’m going to look for another ILC type ecosystem play around data (point 5) by using an open data approach.

I’m going to be spending some time on this new subsidiary, making sure it’s setup right and we don’t get a repeat of Phoenix. I’d be looking for cell based structure, use of attitudes, FIRE, willingness to challenge and all that good stuff outlined in doctrine. To begin with, I need four basic teams (see figure 186) which I’m going to have to flesh out pretty quickly but I’d be hoping that the CIO will help me nab a few of the right people from the data group that Phoenix wants to remove.

Figure 186 — Team structure

This is how I would play the game in order to maximise the benefit for the conglomerate. The return from the disposal will vastly exceed any investment needed. I could probably use it to fund a dozen new startups whilst returning a generous reward to the conglomerate. However, this play took me 45 minutes. I’m sure with a bit of effort then a better play can be found. Maybe you have it? I am willing to learn.

Feeling guilty and the executives

The above play feels a bit “sneaky”. Remember, your focus is on what is of benefit to the conglomerate and you never know, Phoenix could have a glorious future. In cases like this, you need to put away concerns over the subsidiary and be true to yourself. Give them a chance to explore their own future in the comfort of someone else’s purse. Don’t lie to people, even the words I’ve put down for the CEO contain no lies. I’ve just omitted my own concerns which he wouldn’t share anyway. If I thought those executives might then maybe I would take a different path. Remember, the above play could be wrong, you may be selling the golden goose which is why you’d need the rest of your executive board to challenge it.

Also, it’s not “sneaky” to sell of something that you believe will head over the cliff to another. They may be able to see something you can’t and you’re not responsible for them — caveat emptor. It’s also not “sneaky” to emphasise Phoenix as the future, those analyst have been making positive noise in the scenario and maybe they’re right?

I said above that many executives would go for the cloud, Brazil and efficiency options and wouldn’t look to sell Phoenix. They would see Phoenix as having potential. How do I know this? Well, I’ve run the scenario with over 200 executives from different companies and I’ve tested their response before they could map and after. The result is shown in figure 187

Figure 187 — Response to the scenario

Before they could map, the response was always towards building the cloud service. After learning to map, the response shifted to selling the company (“other”). The interesting thing to note is the scenario has many common tools used in business — a P&L to an overview of the market — but the addition of mapping changed the response significantly. The real question to ask is how many past decisions made on those common tools would have been different had they used maps?

The book so far

Chapter 1 — On being lost
Chapter 2 — Finding a path
Chapter 3 — Exploring the map
Chapter 4 — Doctrine
Chapter 5 — The play and a decision to act
Chapter 6 — Getting started yourself
Chapter 7 — Finding a new purpose
Chapter 8 — Keeping the wolves at bay
Chapter 9 — Charting the future
Chapter 10 — I wasn’t expecting that!
Chapter 11 — A smorgasbord of the slightly useful
Chapter 12 — The scenario
Chapter 13 — Something wicked this way comes
Chapter 14 — To thine own self be true
Chapter 15 — On the practice of scenario planning
Chapter 16 — Super Looper
Chapter 17 — To infinity and beyond
Chapter 18 — Better for Less

This post is provided as Creative commons Attribution-ShareAlike 4.0 International by the original author, Simon Wardley.

Simon’s site and other writings https://www.swardleymaps.com/
EPUB and PDF versions https://www.swardleymaps.com/writings-books#wardley-maps

To thine own self be true was originally published in wardleymaps on Medium, where people are continuing the conversation by highlighting and responding to this story.

It maybe unlucky for some but I’m going to start this chapter 13 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. This is usually one those hard things to accept because we get comfortable with the illusion of a perceived slow change from one product to another product (see Chapter 10 — I wasn’t expecting that). It can take 20 to 30 years, sometimes more for the product industry to develop and then 10 to 15 years for it all to be dismantled. For Phoenix, this war has been going on regardless of whether the company is aware or not.

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) dropping the line between the co-evolved practice and our product as that is fairly redundant. Of course, someone is bound to suggest we do that at some point in the future, however I’d rather focus on where the future is going i.e. utility rather than futility. We will use this map to examine the company strategy.

Now, you might argue with the position of pieces on 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.

Point 6 : Keep an eye on the sensors from China. Though not explicitly stated or highlighted as a strategy, it’s worth calling out that the approach is to keep a watchful eye on the sensors. Given the fairly predictable impact these will have, this is less than encouraging.

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

Amber warning

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.

Red Alert!

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.

The Task

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.

A note to the reader

Do try the exercise and spend that forty-five minutes on it. If you get flummoxed then give yourself a bit more but set a time limit, no more than an hour and half. Force yourself to make a choice.

Though I’ve provided some analysis, there’s still a lot to think about. What is right for the company? What is right for the conglomerate that you’re a board member of? What options are open to you? How do you message this to both the company and the board? If you’re struggling then realise that’s good. This is a learning exercise and you don’t learn unless you challenge yourself and embrace difficult problems.

In the next chapter, I’ll give you my solution. Now, this doesn’t mean that my solution is the right one. There could be a myriad of better ways of dealing with this case. Maybe you’ve found one? Maybe you have a different analysis? All I can tell you is how I would solve it and through the medium of maps explain my reasoning and my choices. Being a map, you’re free to challenge any and all assumptions I’ve made. In fact, that’s the point of a map and I welcome the challenge because it gives me the opportunity to learn.

The book so far

Chapter 1 — On being lost
Chapter 2 — Finding a path
Chapter 3 — Exploring the map
Chapter 4 — Doctrine
Chapter 5 — The play and a decision to act
Chapter 6 — Getting started yourself
Chapter 7 — Finding a new purpose
Chapter 8 — Keeping the wolves at bay
Chapter 9 — Charting the future
Chapter 10 — I wasn’t expecting that!
Chapter 11 — A smorgasbord of the slightly useful
Chapter 12 — The scenario
Chapter 13 — Something wicked this way comes
Chapter 14 — To thine own self be true
Chapter 15 — On the practice of scenario planning
Chapter 16 — Super Looper
Chapter 17 — To infinity and beyond
Chapter 18 — Better for Less

This post is provided as Creative commons Attribution-ShareAlike 4.0 International by the original author, Simon Wardley.

Simon’s site and other writings https://www.swardleymaps.com/
EPUB and PDF versions https://www.swardleymaps.com/writings-books#wardley-maps

Something wicked this way comes was originally published in wardleymaps on Medium, where people are continuing the conversation by highlighting and responding to this story.

You are a member of the executive board of a huge conglomerate focused on facilities management. You’re attending a meeting of a wholly owned subsidiary company with their executives. You’re 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 in which currently no company is providing a well developed product 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”.

Sales

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 year with £123 million in revenue and 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 tools 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 a 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 and the company will promote this hybrid model of public or private alternatives. 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 (figure 163) outlining the new service.

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 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 on this topic which has apparently 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.

Strategy

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”, the team developed 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”. These options were then 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 priorities of the company are :-

1. Creation of a digital “cloud based” service for provision of the software.
2. Investigating the use of the data conversion product that is available in order to improve efficiencies and reduce cost.
3. Expansion of existing product into overseas markets such as Brazil.
4. Increasing the development effort on our existing product line including more advanced reporting and other innovative features.
5. Undertake a significant marketing campaign to promote our solution in the existing market.

Finance

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”.

Task

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. If you decide to invoke “other” then scribble down what that other is.

Figure 166 — 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.

A note to the reader

Do try the exercise and spend that forty-five minutes on it. The temptation is always to skip to the next chapter and find the “answer” — if there is such a thing. However, that misses the whole point. This scenario is about you learning to play the game and to do so you need to put yourself in an uncomfortable position of getting things maybe wrong or maybe right. Try not to guess, try and work out why you feel this is the right or maybe the wrong thing to do. If you get flummoxed then give yourself a bit more time, maybe an hour and half at max but force yourself to make the choice.

You’re playing with the future of a subsidiary and all the lives that it effects. There are people whose dreams and livelihoods will change by what you say and what you choose along with a fortune to be won or squandered. You need to feel that pressure, the discomfort of not having long to decide and imperfect information to decide upon. You also need a way to communicate your findings to the rest of the executive board. This challenge isn’t supposed to be easy or comfortable.

If you’re feeling lost or out of your depth, remember we started this journey with “Being lost”. Every executive feels this whether they care to admit it or not. You’re being plunged into the water because eventually you have to play the game and there’s only so much you can do with reading. Don’t get disheartened, this is all part of learning.

The book so far

Chapter 1 — On being lost
Chapter 2 — Finding a path
Chapter 3 — Exploring the map
Chapter 4 — Doctrine
Chapter 5 — The play and a decision to act
Chapter 6 — Getting started yourself
Chapter 7 — Finding a new purpose
Chapter 8 — Keeping the wolves at bay
Chapter 9 — Charting the future
Chapter 10 — I wasn’t expecting that!
Chapter 11 — A smorgasbord of the slightly useful
Chapter 12 — The scenario
Chapter 13 — Something wicked this way comes
Chapter 14 — To thine own self be true
Chapter 15 — On the practice of scenario planning
Chapter 16 — Super Looper
Chapter 17 — To infinity and beyond
Chapter 18 — Better for Less

This post is provided as Creative commons Attribution-ShareAlike 4.0 International by the original author, Simon Wardley.

Simon’s site and other writings https://www.swardleymaps.com/
EPUB and PDF versions https://www.swardleymaps.com/writings-books#wardley-maps

The scenario was originally published in wardleymaps on Medium, where people are continuing the conversation by highlighting and responding to this story.

“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 .

However, to make the exercise still challenging then I’ve taking the liberty of hiding the clues throughout this chapter which is interspersed with 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 cycle is in the change (point 1 in figure 133) between the two states of peace and war and it’s here we will focus.

Whilst the act (e.g. computing) may be well understood, this transition (e.g. computing shifting from products such as servers to utility services such as cloud) causes a great deal of confusion because the nature of the act is changing — we’re moving from a world of constant feature differentiation to a world of volume operations of good enough. This change is compounded by co-evolved practices (such as DevOps), our inertia to it, the surprising speed at which it occurs 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 suite of tools that we had used to provide on demand virtual machines within my own company . I was confident we could easily 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 managed to arrange 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 beyond palpable, it was dismissive. Amazon was not considered a threat but a minnow and only a “madman” would think otherwise. 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. In all but actual words the message was clearly “go away little boy and let the grown ups deal with this in a responsible manner”. The air was always thick with endless prognostications of their own future greatness along with the old trope of “how will your stuff sell more servers?”

The truth be told, I did feel like the naughty boy pointing at the Emperor and going “he’s got no clothes on”. 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 gentle pat on the head or a pinch on the cheeks with the kindly guffaw of “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 this change and in a somewhat tragic act of desperation this was seized upon. Past giants had found their Kodak moment.

The Kodak moment of cloud

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. They would bring fulfilment of photo printing into this digital world! It tanked because users just started sharing images and bypassed the whole point of the traditional photo. In the cloud world, this same tragic mistake has been created with the private cloud. We will bring you all the benefits of volume operations with commodity components through a public provider but using enterprise like hardware customised to your needs and running in your own data centre! In other words, they planned to bring “selling servers” into this utility world.

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 and 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. For many, this is more than adequate. When you need to go that extra mile and 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 of transition.

To reduce this cost then either you want multiple public providers with are interoperable or management tools which cover 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 then switching incurs an additional cost beyond the movement of data through either transition costs or some loss of useful functionality. But switching is still desirable in terms of bargaining power and ensuring competitive pricing in a market. These are the trade offs that 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 we 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 build a consumer ecosystem around our platform as a service i.e. we hoped many others would consume our component enabling us to run that “innovate-leverage-commoditise” 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. To achieve this we had announced the open sourcing of Zimki along with testing services to enable others to become Zimki providers.

However, in our value chain, we also consumed components of infrastructure from others and hence it was advantageous to us (for reasons of pricing competition) that our ecosystem of suppliers consisted of a competitive marketplace with interoperability and easy switching between them. We intended to achieve this by open sourcing Borg (our infrastructure play) which would co-opt the APIs of any major utility provider if it appeared. Hence my early phone calls to those executives offering to provide them with an Amazon competitor.

Open sourcing a technology not only enables that component 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, whilst this was my plan in 2005, the entire project had been killed off in 2007 for not being “the future”. 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 and far too late. They failed to co-opt (arguing for differentiation) and failed to prevent a collective prisoner dilemma forming.

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. Instead, we’ve seen not only industrialisation of computing infrastructure to utilities but also centralisation towards Amazon. This is another point to highlight in this sorry tale. Industrialisation 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 failed 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 of the war have emerged. The time to change the players and to play the game well is in the overlap between the states of peace and war during the change 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. It is unlikely that those who so spectacularly lost this battle will have the skill to win such a war of attrition.

For infrastructure, this shift from peace to war has long passed and the victors have emerged. For the “serverless” platform world, we’re in the midst of this change 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 will be.

Opportunity on a map can be found in several places. From the genesis of the novel or the provision of unmet needs or differentiation of 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 they don’t have a use, they do in terms of setting expectations. Unfortunately, for some reason that I have yet to fathom, people tend to invoke mystical properties around contracts. They tend to believe that the contract or plan represents a reality that is foretold — “If it’s in the contract then it must happen as it is written”. This is quickly followed by disappointment and disputes when it doesn’t. But surely, that’s the point of the contract — “we want to know what is being delivered!”

To explain why that principle is the 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. This organisation 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 down into what it considered to be sensible contracts based broadly upon financial value and other characteristics. However, when I overlaid those contract “lots” onto the map then there was an obvious problem. One lot known as “C” 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 contract to Lot “C” for delivery against some specification. Obviously we want to know what’s being delivered hence we put effort into writing the specification. We have some form of competitive tender process which many potential suppliers bid for.

We hope the suppliers will naturally try to be competitive in their bids. However, in order to do so then the suppliers need to manage their own risks. One of the risks is the change of specification. For example, if you asked me to bid for providing 10 tons of gold and I won the lot with a competitive price, then it would be for delivering 10 tons of gold and not 10 tons of platinum or 10 tons of diamonds. If you change the specification then I’m going to charge you.

In any system governed by such contracts and specification then there will be a change control process as it’s only reasonable that if we change our mind then we incur the cost of this. These change control processes tend to be burdensome and expensive because they’re designed for minimising change and for delivering against the specification. Even a simple change can incur rewrites of the specification, analysis of impacts and many other steps that add up to considerable costs.

But look again at the map above and in particular Lot “C”. Some of the components are industrialised which means they are unlikely to change and are suited to this contract approach. 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, no-one does. These components will change and we will incur that change control cost. The problem is we’re applying a principle of “we want to know what is being delivered” to components that we cannot possibly know what is going to be delivered. The one thing we can guarantee with those custom built activities are they will change. We are doomed to invoke the expensive change control cost process at the point the contract is signed. The cost will spiral and dispute will happen.

Let me be crystal 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 to this problem for future projects is “better specification”. This will not only increase the costs in trying to describe the unknown but repeats the same mistake of change control costs by trying to define the unknown. 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 for sensible contracting.

In 2008, I would commonly see this problem. Outsourcing had already got a bad name but in truth 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.

FIRE

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?”

Fast + Inexpensive + Restrained + Elegant = FIRE

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 avoiding any broad systems i.e. no mixing of industrialised with the uncharted. Each of these areas 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 arrangements under detailed specification or even utility providers such as cloud services. 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. There are alternatives. You could outsource them under a time and material basis to a group that specialises in the experimentation required but this is a different type of arrangement from outsourcing under a specification or volume operations. You might even outsource the novel to the market i.e. just let the market get on with discovering what is there and take a back seat until the component becomes more evolved. Procrastination can be a useful tool if consciously used as such and with a good understanding of the landscape.

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.

It’s all too difficult

Despite all the horrors caused and the endless stream of disasters, there is one commonly cited advantage of the all encompassing contract that seems to trump everything. The advantage is that it makes it simple to manage. The unpleasant old phrase of “one throat to choke” comes to mind. In practice, 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 exists. We fool ourselves (despite all the evidence) into believing that we can outsource this risk through massive, one size fits all contracts using detailed specification. 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 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. Let us focus on those points. In an attempt to avoid managing what we should manage then under a banner of reducing risk we put the existence of entire companies at stake in 1 out of 6 cases and go disastrously wrong in 4 out 6. If this is management then to quote Inigo Montoya from The Princess Bride — “You keep using that word, I do not think it means what you think it means”.

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. 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 :-

disposing of liability

The first and most obvious approach is to simply recognise that a change is occurring, that you have inertia caused by past systems and you need 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 then 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 such change is best done in a piecemeal fashion using small components over time. You dispose of the liability bit by bit, often using techniques such as the strangler pattern. 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 and fail to continually invest in refactoring. They leave the liability to grow 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 done the same. This creates an inevitable shortage of skills which piles on the misery and cost. So, start early and dispose of it bit by bit.

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 preparing a new environment with components that you have built or use from third parties. 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 future 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 above, you might convince another company that enterprise application stores are the future. If you have a pre-existing home grown application store then you can sell it to them including some of the underlying environment (from infrastructure to staff) as a “future business” whilst ensuring you have access ideally on a utility basis 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 use of the legacy store. 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, we can outsource our own risk, management can be made simple, 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 but you can still manage this.

These maps help you to 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 such as the nut and bolt or the plug. They also contain chaotic components that are uncertain and we do not yet 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 commonplace in the world of cloud computing mainly due to the confusion that existed. I thought I’d use a few “simple truths” that turn out not to be either simple or true 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 then we will spend less on IT. Sounds simple, sounds obvious and yet it is so wrong.

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 the reducing cost of providing 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 it also enables user innovation through provision of standardised components (the componentisation effect). Building a house is faster with bricks than a clay pit. This in turn 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. As these industries evolved they drove further 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 and 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 is finally becoming more industrialised e.g. a commodity or a utility. This will allow for more efficient provision of the act through volume operations.

However, the more industrialised component can enable greater use of the component as previously uneconomical acts become viable (point 2). There can be a long tail of things we’d like to do and unmet needs which are enabled by the efficiency of provision. The final aspect (point 3) is consumption of the component will increase as new industries that it enabled start to evolve.

Figure 143 — Jevons paradox

But can’t I just ignore this? We’re talking market effects here? 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 or to build that long tail of desired things or to use that new fangled industry. 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.

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. Don’t confuse efficiency with reduced IT spend.

Cloud will be green

Another common talking point 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 an argument could be made for Cloud being green. However, there’s something more long term to be thought about 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.

Whenever we see a shift from products to more industrialised forms such as utilities, then most large companies (with the exception of the enlightened) will tend to ignore the change. This is 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 financial 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 the new activities built upon it.

If I take figure 143 from above and overlay onto it this flow of capital along with the peace, war and wonder cycle then we can get a sense of what is happening. At the same time that 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 financial capital is flowing away from past product vendors towards the new vendors and new companies serving those new markets. Now 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 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 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 disadvantaged or eliminated 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 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 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 areas but removed any concept of position and the anchor. I’ve just placed the fields in order of what type they are — fruit, livestock and crop. I’ve also 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. Explorers can’t explore by just sitting still, something has to move (whether it’s them, a drone or a satellite is immaterial). Action is a necessity for exploration.

Movement matters with maps because space itself has meaning. That’s quite a complex and esoteric concept to understand, so to make it simple I’m going to use one of those system “maps” which aren’t actually maps. Take figure 147a below and compare to figure 147b. I’ve highlighted a box called CRM (customer relationship management) and moved it. Does the meaning of the “map” change as a result of moving the box?

Figure 147a — A systems map

Figure 147b — A systems map with the CRM box “moved”

The CRM boxes have the same connections to other components. There’s no obvious change of meaning. Now, consider an Atlas. Let me shift Australia and put it next to the UK. Does that change the meaning of the Atlas? Well, of course it does. In a map, the space has meaning. For our systems diagram to be a map then all the space (see figure 147c) would have to mean something and you couldn’t just shift a box without changing the meaning.

Figure 147c — Space has meaning.

Anchor, position and movement are essential qualities of a map and they create meaning for the space being explored. These navigational qualities enable us to learn about the environment whether through a visual form or a equivalent internalised mental model.

However, there are ways to create a different form of map by in effect anchoring the “space” to the lines of the map. Take for example the tube 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

It’s important to understand what anchoring the space means in this case — there are no alternatives but to travel along the path of the tube network. You cannot use the tube map to dig your own tunnel from Cannon Street to Holborn. Naturally, Transport for London does of course have geographically accurate tube maps where the map is bound to the actual geographic landscape and hence anchored with a compass — this is north of that or east of there.

The tube map doesn’t have to look like the above. You could also build your own variety of tube map by simply travelling on the trains and recording the stations but as long as you can consistently describe movement then it is a map (anchored to the tube network) that you can share with others. But, I hear some argue “if the tube map is a map then can’t I declare my systems diagram a map as there is no alternative?”

Well, by such a declaration you are saying that the only way this system can be is the way you’ve drawn it. You are declaring that there is no alternative and the components cannot themselves change i.e. CRM will always be this CRM and no-other solution will exist. You are stating (as with the tube map) that “this is just the way it is”. Obviously, a modicum of experience in business or IT will tell you that change happens. Unless you’re dealing with something which is as semi-permanent as the tube network where you can afford to assume that the tube network isn’t going to start rapidly changing with new tunnels appearing this week or stations going for a wander then I’d stick with mapping to the landscape itself. In business, that means mapping against the competitive landscape e.g. the user (anchor), the value chain (position) and evolution (movement).

Now, I’ve made quite a detour into tube maps because they are currently a vogue in the business world with various companies creating them to describe complex environments. 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. If we assume that the “tube network” is the anchor then according to the “map”, if I wish 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’m afraid this is not a map, it’s a diagram of loosely connected concepts and questionable relationships. It’s about as un-map like as you can make it, with only two redeeming qualities of being visual and having components.

Figure 149 — A tube “map” of the digital world

So, why does this matter and what has this got to do with execution? Without maps then situational awareness will be poor. 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 some companies might actually be 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, their pace and any inherent inertia 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 also had 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 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 in some cases near blindness to their environment. Quite a few not only didn’t understand evolution, they didn’t know their value chains or even what their users needed.

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. Out of curiosity, I decided to examine market cap changes of those companies over the last 7 years. The results are shown in figure 151.

Figure 151 — Market Capitalisation impact

I can’t repeat what my first response was but let us just say that I was very surprised. 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 than those who don’t. 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 more 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 do actually 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?

How common is corporate blindness?

In 2014, I was messing around with modelling agents in a competitive market and looking at various impacts on 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 of the top 400 in the simulation. 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 evolution (due to industrialisation of the 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 i.e. automatons in a variation of Conway’s Game of Life.

Why is that interesting? Well, the agents are automatons that are blind to the environment. 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 and the problem with my simulation is I just had the wrong principles. To challenge this, I’ll use a bit of WoW.

I’ve often found World of Warcraft (a massive multiplayer online role playing game known as WoW) to be a useful vehicle for explaining and exploring 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 commences. The winner is the team that captures the opponent’s flag three times. Let us assume 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 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 :

• Perform your role the best you can (Develop mastery).
• Act as a single unit (a cell) i.e. fight 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 the 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 the opponents graveyard — see map (figure 153) — killing off their players as they are resurrected and before they create any form of group. Taunting Alliance 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’s graveyard killing all players that resurrect. Once opposing players are contained in the graveyard the cell will reform and our fighter 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 quickly 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 combined with 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 “apply the principles and follow Morgana the Wizard. Just do what she does” in the hope the new player will build up some mental map.

Principles aren’t going to save you against vastly higher levels of situational awareness. 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” and “following others” 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 and no magic secret to success.

Conway’s Game of Life consisted of 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 that was raised was the importance of core, having a goal and clearly defined purpose. At the same time that people were talking about the “goal”, Silicon Valley was raving about the “pivot”. In short, you should have a goal unless you pivot to another goal. Go figure!

The problem of course is that strategy is not a long linear path but a constantly 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 as 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 i.e. you needed a lawyer to write your will. 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 via reducing barriers to entry into your market. The newspaper industry has suffered a recent example of this with 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. The media industry had to adapt or in some cases fail.

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 on how to master strategy. You’ll need this for the scenario. I’ve italicised master because I don’t really have a clue how to do that. I’m still learning and I’ve been using maps for over a decade. For now, all I can say is that strategy seems to be a journey of constant learning and the more I learn, the more I realise how little I know. If anyone does actually become a master then I’d be pleased to read about how they did it. There maybe a faster way to master strategy than a seemingly endless journey of learning. There might even be a 2x2 that’ll explain everything but so far, I haven’t found it. Hence in the absence of some marvellous solution, I’ll give you some basic steps.

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 or grand proclamations that 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 look at 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 the 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.
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. The Red Queen has a secondary effect which is by adaptation then competitors limit the growth of a single company and prevent a run away process.

Commoditisation does not equal 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 components, 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, almost 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 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 gains from 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 return. 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 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 due to suspected 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 of 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
There will always be edge cases or a way to make something more perfect 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 in horror when it is “discovered” that they have hundreds or even “thousands”. People can get very defensive in this space and want to shut you down.

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. Have fortitude, you’ll often find you’re arguing against all these tribes at the same time.

Focus on the outcome not a contract
Try to focus on the outcome and what you’re trying to achieve. 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 avoid this or building abstraction 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.

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 this before you encounter it 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). Avoid known failure modes such as building large scale (death star) like efforts.

Think small
Know the details, use small teams and break large landscapes into small contracts. Don’t be chased away by fears of complexity of management.

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. Taking a gifted engineer and turning them into a mediocre project manager is not wise. 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 need 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. You can build powerful sensing engines (e.g. the ILC model) for future change, sources of co-operation with others, 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. with marketing by 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. Avoid this arrogance at all costs.

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)
• 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 deploy 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 started, some basic from of gameplay (often called stratagems) are :-

Gameplay

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

IPR
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 you’re going and why you’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

On biology

Terms like evolution, co-evolution, adaptation, red queen, competition, adaptive renewal systems, cell based structures, ecosystem, flow and awareness might make you think I’m talking about some form of biological system. That’s because I am. A business is a living thing not some physical machine. The more classical view of the machine has advantages in management thinking as it implies it’s simple and can be managed just by pulling the right levers or adding the right algorithm. This works fine if you’re in competition with others who think the same way but don’t assume everyone does.

Biological systems are highly resilient to change in total. Individual members or species might be taken out by some disease or some catastrophic event but the system of life itself adapts and evolves through mutations in the entire population or exaptation (re-use of components for another purpose). A classical machine has a far more limited scope of resilience, no matter how well designed or scenarios considered and it does not evolve with its environment in the same manner. CS Holling distinguished between these two types of resilience as engineering versus ecological. Whereas engineering resilience is primarily about the efficiency of function, ecological resilience is focused on the existence of function.

A fragile system is one with low engineering and ecological resilience. It has very limited constraints of physical operation and it cannot adapt or cope with change well. It breaks easily and ceases to function.

A robust system is one with high engineering but low ecological resilience. It has a broader range of physical constraints that it can cope with but again it cannot adapt to unexpected events. Many classical systems are designed to maintain the efficiency of function given a set of broad constraints or defined changes e.g. loss of a single engine in an aircraft.

A fluid system is one with low engineering resilience but high ecological resilience. Though elements of the system can be considered fragile (operating within limited constraints or occupying a niche), the system itself adapts rapidly to changing circumstances i.e. the efficiency of function might decline rapidly due to a change but the function continues to exist. Many biological ecosystems can be considered fluid and the process of change is known as evolution e.g. adaptation of a species to some new predator or environmental catastrophe.

A resilient system is one with high engineering and ecological resilience. Not only is the system capable of coping with a wide variety of physical extremes, the entire system rapidly adapts to a changing environment in order to exist. Nature in its entirety can be considered resilient and it has become so through the process of evolution. Nature consists of many biological ecosystems occupying niches and any change in physical conditions enables one biological ecosystem to invade the space of another. The efficiency and survival of life is preserved bar the most catastrophic of shocks.

This last point is critical. It is evolution through competition and a changing environment that has made Nature itself resilient. Evolution is driven by competition and far from the gradual and peaceful concept that abounds in literature, it involves the entire annihilation of species and individual biological ecosystems in a violent orgy of death throughout history. Species have evolved mechanisms to survive this orgy of death. Your body builds muscle because of constant exercise but burns that same muscle during starvation — it’s all part of our bodies energy management that has evolved to cope with change. Even death itself is a necessity to evolution and self replication with constrained resources.

However, a consequence of this orgy has been diversity and whether it is diversity between or within species, this is a critical element of ecological resilience. Lack of diversity is often a major weakness of classical engineering systems through systemic failure. If you want to create a system that is capable of adapting to constant change, is resilient to the unknown and has the best shot at longevity as a whole then nature is a past master at this. Learn from life itself.

On maps

Maps are about awareness. You should always 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. As there is no such thing as the “right” map, then feel free to alter the map in a way which makes it more useful to you.

4. If you’re feeling that this is a lot to take in, well it is. Strategy is not a simple topic despite our attempts to dress it up as such.

You are now ready. Well, you might have been ready long ago but I wanted to give myself the best chance, so it’s more I am now ready. Forward friends and let us now play the game with a scenario in the next chapter.

The book so far

Chapter 1 — On being lost
Chapter 2 — Finding a path
Chapter 3 — Exploring the map
Chapter 4 — Doctrine
Chapter 5 — The play and a decision to act
Chapter 6 — Getting started yourself
Chapter 7 — Finding a new purpose
Chapter 8 — Keeping the wolves at bay
Chapter 9 — Charting the future
Chapter 10 — I wasn’t expecting that!
Chapter 11 — A smorgasbord of the slightly useful
Chapter 12 — The scenario
Chapter 13 — Something wicked this way comes
Chapter 14 — To thine own self be true
Chapter 15 — On the practice of scenario planning
Chapter 16 — Super Looper
Chapter 17 — To infinity and beyond
Chapter 18 — Better for Less

This post is provided as Creative commons Attribution-ShareAlike 4.0 International by the original author, Simon Wardley.

Simon’s site and other writings https://www.swardleymaps.com/
EPUB and PDF versions https://www.swardleymaps.com/writings-books#wardley-maps

A smorgasbord of the slightly useful was originally published in wardleymaps on Medium, where people are continuing the conversation by highlighting and responding to this story.

I was in a quandary. Having described the three states of war, wonder and peace then I found myself in the unusual position of finding them everywhere. All activities seemed to show these three competitive states. However, I had no real way of testing the existence of these states and my ability to perceive them might be caused by some sort of bias? It’s bit like owning a Mini Cooper, once you have one then you suddenly notice how many other cars are Mini Coopers. I started to scout around for some means of testing these concepts. Did the states really exist? How could I test them? Do they just effect individual activities in industries or could they have a wider effect?

At the very least I had a set of predictions (from weak signals) for when a range of activities would start to industrialise and so I could just wait. Of course, this could just mean the weak signals were wrong or I was just lucky? There was also something strangely familiar about those three stages. I’m a geneticist by training, I hold a second masters in environmental management and I also have a background in economics, courtesy of a mother who as an economist ignited my interest in the subject. I knew I’d seen these three states elsewhere. It didn’t take me long to re-discover that first example — C.S. Holling’s Adaptive Renewal cycle.

The adaptive cycle describes the dynamics of a complex ecosystems in response to change. We start with the creation of some form of disturbance — the genesis of a new act, some form of wonder. This is followed by a rapid stage of exploitation and accumulation in a stage of conservation where the change has become more stabilised in the ecosystem — the equivalent to a time of products, a peaceful state of competition. Eventually, the change has been normalised which releases energy enabling re-organisation and the genesis of new acts and new disruptions — the time of war. The Holling’s cycle is measured over the potential of the system for change and the connectedness of the system. Whilst not an exact corollary, I’ve overlaid an approximation of the peace, war and wonder cycle onto the Holling’s cycle in figure 112.

Figure 112 — Adaptive renewal cycle

The importance for me of this was it gave rise to a number of concepts. First, when considering economic systems we would have to look at them as we do with biological systems and consider how an ecosystem reacts to a change and how competition will drive that change throughout the system. Secondly, the size of the ecosystem impacted should reflect the connectedness of the system that is changing i.e. industrialisation of legal will writing would only impact the legal industry whereas industrialisation of computing should have a much broader macro-economic effect. Lastly, there may well be an element of re-organisation involved. I was already aware of co-evolution but maybe this enabled broader organisational change?

With this in mind, I started to explore macro economic scale effects on an assumption that a suitably connected technology should not only have micro economic impacts to its industry but wider impacts. I was aware that the economy exhibited cycles known as Kondratiev waves (thanks to my interest in economics) and the largest waves we described as Ages. The first thing I noted was that these ages were not initiated by the genesis of some new activity but always by the industrialisation of a pre-existing activity that enabled higher order systems to develop. For example, the Age of Electricity was not caused by the introduction of electrical power which occurred with the Parthian Battery (sometime before 400 AD) but instead utility provision of A/C electricity with Westinghouse and Tesla, almost 1500 years later. Equally, the Mechanical Age was not caused by the introduction of the screw by Archimedes but by the industrialisation of standard mechanical components through systems such as Maudslay’s screw cutting lathe. The Age of the Internet did not involve the introduction of the first means of mass communication such as the Town Crier but instead industrialisation of the means of mass communication.

Whilst born out of industrialisation, each of these Ages were associated with a major cluster of “innovations” (i.e. genesis of new activities) that are built upon the industrialised components. Each age therefore had a “time of Wonder”. The ages were also associated with a change in organisations. I started collecting approximate dates for these different ages, trying to identify the point of technology that may have initiated it and also the type of organisation structure that was dominant. A later version of this is provided in figure 113.

Figure 113 — Waves of organisational change

I still had no narrative linking it all together, instead it was a lose collection of almost connected concepts. Then in mid 2008, I came across Carlotta Perez’s marvellous book — Technological Revolutions and Financial Capital. Perez has characterised these K-Waves around technological and economic paradigm shifts. For example the Industrial Revolution included factory production, mechanisation, transportation and development of local networks whereas the Age of Oil and Mass Production included standardisation of products, economies of scale, synthetic materials, centralisation and national power systems. Carlotta had talked about the eruption of change, the frenzy of exploitation and later stages involving synergy and maturity (a more peaceful time of competition, of exploitation and conservation). It reminded me of Holling’s Adaptive renewal cycle. It reminded me of peace, war and wonder.

• The wonder of eruption and frenzy of new ideas, the explosion of the new and the re-organisation of systems around it. A time of exploration and pioneers.
• The exploitation and growth of these concepts, the synergy and the maturity of products in a more peaceful state of change. A time of settlers.
• The eventual release of capital and tumultuous shift from one cycle to another, the lost of the old, the birth of the new, the time of war and creative destruction of the past. A time of industrialisation and town planners.

I’ve taken Carlota’s description of K-waves and added onto it the overlapping stages of peace, war and wonder in figure 114.

Figure 114 — Carlota Perez and Kondratiev waves

An unexpected discovery

In my pursuit of discovering a way to test the peace, war and wonder cycle then I had accidentally stumbled upon a narrative for describing a system wide organisational change. How widespread a change would be depended upon how well connected the components that were industrialising are. They could be specific to an ecosystem (e.g. legal will writing) and a small set of value chains or they could impact many industries (e.g. computing) and many value chains.

The narrative would start with the birth of a new concept A[1] which would undergo a process of evolution through competition from its first wonder and exploration to convergence around a set of products (point 1 in figure 115 below). These products, after x iterations crossing many chasms and following many diffusion curves would become more stabilised with well defined best practice for their use (point 2 in figure 115). Large vendors would have established, each with inertia to future change due to past success but the concept and the activity it represents will continue to evolve.

Eventually the component would be suitable for industrialisation and new entrants (not suffering from inertia) would make the transition across that inertia barrier introducing a more commodity form of A[x+1]. This would trigger a state of war, a shift to industrialised forms, a release of capability and capital (point 3) enabling an explosion of new activities due to componentisation effects and new practices (point 4) through co-evolution. The underlying activity would continue its evolution to ever more industrialised forms until some form of stability is achieved with A [1+n], a long an arduous journey of n iterations from the first wonder of its first introduction. The past ways, the past forms of the activity, the past practice would have died off (point 5) and they would have done so quickly.

Figure 115 — Understanding why

In 2008, this was exactly what was started to happen around me in cloud computing. But the vast majority of people seemed to be assuring me that the change would take many decades, it would be very slow. Why would this be a slow progression? Why wouldn’t the change happen quickly? To understand this, we need to introduce a climatic pattern known as the punctuated equilibrium.

Climatic Pattern : Punctuated Equilibrium

Throughout history there have been periods of rapid change. The question should be when is change a slow progression and when is it rapid? Part of this caused by an illusion, an application of our bias to the concept of change. Let us consider an evolving act — A. From figure 74 (Chapter 7), we know that the evolution of an act consists of the diffusion of many improving instances of that act. Let us assume that the activity quickly progress to a product — A[2] and evolves through a set of feature improvements — A[2] to A[x] as shown in figure 116 below. This will be the time a products, a constant jostle for improving features and though individual iterations will rapidly diffuse (e.g. the 586 processor replaced the 486 which replaced the 386 and the 286 in the x86 family), the characteristics of products (the x86) are broadly the same and the overall time of products appears to be long. This had happened with servers, a constant improvement and a long product run of 30 to 40 years.

Figure 116 — The illusion of speed

With the advent of more utility forms, you gain all the benefits of efficiency and agility, you’re under pressure to adopt due to the Red Queen but invariably people suffer from a bias towards a slow change because this is what they’ve experienced with products. They forget that we’ve had successive iterations (286 to 386 to 486 etc) and label this all as one thing. They expect the progression to more utility forms will take equally long but the transition is not multiple overlapping diffusion curves and the appearance of slow but steady progress but a single rapid shift (see figure above). Rather than 30 to 40 years, the change can happen in 10 to 15 years. We are caught out by the exponential growth and the speed at which it moves. This form of transition is known as a punctuated equilibrium and invariably shift from product to utility forms exhibit it.

It’s the exponential nature that really fools us. To explain this, I’ll use an analogy from a good friend of mine, Tony Fish. Consider a big hall that can contain a million marbles. If we start with one marble and double the number of marbles each second, then the entire hall will be filled in 20 seconds. At 19 seconds, the hall will be half full. At 15 seconds only 3% of the hall, a small corner will be full. Despite 15 seconds having passed, only a small corner of the hall is full and we could be forgiven for thinking we have plenty more time to go, certainly vastly more than the fifteen seconds it has taken to fill the small corner. We haven’t. We’ve got five seconds.

Alas, these punctuated equilibriums are often difficult to see because we not only have the illusion of slow progress but confusion over what speed actually is. Let us assume that today it takes on average 20 to 30 years for an act to develop from genesis to the point of industrialisation, the start of the “war” which changes so much in industry. Organisations consist of many components in their value chains all of which are evolving. We can often confuse the speed at which something evolves with the simultaneous entrance of many components into the “war” state. For example, in figure 117, I’ve provided the weak signal analysis (from chapter 9) of many points of change. We can see that each component takes roughly 20 to 30 years to evolve (point 1) to the point of industrialisation, followed by 10 to 15 years to industrialise (the “war”). However, if you examine point 2 then we have many components from robotics to immersive technology to IoT that are embroiled in such a war. This can give us the impression that change is happening vastly more rapidly as everything around us seems to be changing. It’s important to separate out the underlying pace of change from the overlapping coincidence of multiple points of change.

Figure 117 — The confusion of speed

Given this, it should be possible to test the punctuated equilibrium. By selecting a discrete activity we should be able to observe its rapid change along with the denial in the wider industry that such a change would be rapid. Cloud computing gave me a perfect example to test this. In 2010 (when I was at Canonical), I produced a forward revenue chart for Amazon. This estimated the forward revenue at the end of each year for AWS (Amazon web services) and was based upon what little data I could extract given that Amazon wasn’t breaking out the figures. I’ve provided this estimate in figure 118.

By the end of 2014, I had anticipated AWS would have a forward revenue rate of $7.5 billion p.a. which means every year after 2014 it would exceed this figure. In fact, AWS clocked over $7.8 billion in 2015. Now, what’s not important is the accuracy of the figures, that’s more luck given the assumptions that I needed to make. Instead what matters is the growth, it’s non linear nature and the general disbelief that it could happen. Back in 2010, telling people that AWS would clock over $7.5 billion in revenue some five years later was almost uniformly met by disbelief.

Figure 118 — The punctuated equilibrium

Finding the future organisation

In 2008, I had the narrative of how organisations change and though I still had to demonstrate aspects of this (by anticipating a punctuated equilibrium before it happened) it did provide me with a path to test the concepts. I knew that if the concept was right then over the next decade we would see a rapid change to more industrialised computing, co-evolution of practice and a new form of organisation appearing. In the case of the rise of DevOps then this process had already started. Beyond just simply observing the growth of new practices and new activities along with the death of the past (see figure 119), I wanted a more formal method to evaluate this change. What I wanted to know is could we catch this next wave? Would the shift of numerous IT based activities to more utility services create a new organisational form? Timing would be critical and unlike my earlier work in genetics where populations of new bacteria are grown rapidly, I had to wait. So wait, I did.

Figure 119 — the past and the future

By 2010, the signals were suggesting that this was happening and in early 2011, I had exactly the opportunity I needed. Being a geneticist, I was quite well versed in population characteristics and so as part of a Leading Edge Forum project (published in the same year) we decided to use such techniques to examine populations of companies, specifically a hundred companies in Silicon Valley. We were looking for whether a statistically different population of companies had emerged and their characteristics (phenotypes) were starting to diffuse. It was a hit or miss project, we’d either find a budding population or it was back to the drawing board.

We already knew two main categories of company existed in the wild — those that described themselves as traditional enterprise and those using the term “web 2.0”. The practices from the web 2.0 were already diffusing throughout the entire environment. Most companies used social media, they thought about network effects, used highly dynamic and interactive web based technology and associated technology practices. The two populations were hence blurring through adoption of practices (i.e. the traditional were becoming more web 2.0 like) but also partially because past companies had died. But was there now a next generation budding, a new Fordism?

I interviewed a dozen companies that I thought would be reasonable examples of traditional and web 2.0 and where I hoped a couple of highly tentative next generation companies might be hiding. I developed a survey from those companies, removed them from the sample population to be examined and then interviewed over 100 companies divided roughly equally among those that described themselves as web 2.0 and those who called themselves more traditional. The populations all contained a mix of medium and huge companies. I examined over 90 characteristics giving a reasonable volume of data. From the cycle of change and our earlier interviews, we had guessed that our next generation was likely to be found in the self describing “web 2.0” group and in terms of strategic play they would tend to be focused on disruption (the war phase) rather than profitability (the peace phase). From our earlier interviews I had developed a tentative method of separating out into candidate populations. So, I divided the population sample out into these categories and looked at population characteristics — means and standard deviations. Were there any significant differences? Were the differences so significant that we could describe them as a different population i.e. in a sample of mice and elephants then there exist significant characteristics that can be used to separate out the two populations.

I ran our analysis and waited. It was an edgy moment. Had we found something or as per many attempts before had we found nothing? I tend to assume nothing and when there is something, I tend to doubt it. Within our data set we found statistically significant population differences across a wide number of the characteristics but also significant similarities. I re-examined, looked through my work, tested, sought the advice of others and tested again — but the differences and similarities remained. For example, I examined each company’s view on open source and whether it was primarily something that means relatively little to them, a mechanism for cost reduction, something they relied upon, something they were engaged in or whether open source was viewed as a tactical weapon to be used against competitors. The result is provided in figure 120 with the subdivision by population type.

Figure 120 — Views on open source

Whilst the traditional companies mainly viewed open source as a means of cost reduction and something they relied upon, this next generation viewed it as a competitive weapon and something they were heavily engaged in. The web 2.0 group had a broader view from cost to weapon. This difference in population was repeated throughout many characteristics spanning strategy, tactics, practice, activities and form. The odds of achieving the same results due to random selection of a single population were exceptionally low. We had found our candidate next generation.

To describe this next generation, it is best to examine them against the more traditional. Some of the characteristics show overlap as would be expected. For example, in examining the highest priority focus for provision of technology by a company whether it’s profitability, enhancement of existing products and services, innovation of new products and services, enabling other companies to innovate on top of their products and services or creating an engaged ecosystem of consumers then overlaps exists. In other areas, the differences were starker. For example, in an examination of computing infrastructure then traditional favoured enterprise class servers whereas the next generation favoured more commodity. A good example of this similarity and yet difference was the attitude towards open source. When asked whether a company open sourced a source of differential advantage on a scale of strongly disagree to strongly agree then both traditional and next generation gave almost identical response (see figure 121).

Figure 121 — Finding similarity

However, when asked whether they would open source a technology to deliberately out manoeuvre a competitor then the answers were almost polar opposite (see figure 122).

Figure 122 — Finding difference

Using these populations, I then characterised the main differences between traditional and next generation. These are provided in figure 123 but we will go through each in turn. I’ve also added some broad categories for the areas of doctrine the changes impact.

Figure 123 — the phenotypic differences.

Development
Traditional companies tend to focus towards singular management techniques for development (e.g. Agile or Six Sigma) and often operate on a change control or regular process of updates. The next generation tends towards mixed methods depending upon what is being done and combine this with a continuous process of release.

Operations
Traditional organisations tend to use architectural practices such as scale –up (bigger machines) for capacity planning, N+1 (more reliable machines) for resilience and single, time critical disaster recovery tests for testing of failure modes. These architectural practices tend to determine a choice for enterprise class machinery. The next generation has entirely different architectural practices from scale-out (or distributed systems) for capacity planning, design for failure for resilience and use of chaos engines (i.e. the deliberate and continuous introduction of failure to test failure modes) rather than single, time critical disaster recovery test. These mechanisms enable highly capable systems to be built using low cost commodity components.

Structure
Traditional organisations used a departmental structure often by type of activity (IT, Finance, Marketing) or region with often a silo mentality and a culture that was considered to be inflexible. The next generation used smaller cell based structures (with teams typically of less than twelve) often with each cell providing services to others cells within the organisation. Each cell operated fairly autonomously covering a specific activity or set of activities. Interfaces were well defined between cells and the culture was viewed as more fluid, adaptable and dynamic.

Learning
Traditional organisations tend to use analysts to learn about their environment and changes that are occurring. They tend to also use big data systems which are focused primarily on providing and managing large sets of data. The next generation use ecosystems to more effectively manage, identify and exploit change. They also tend to not only use “big data” but to be run by it with extensive use of modelling and algorithms. The focus is not on the data per se but the models.

Leading
In traditional organisations, the use of open systems (whether source, data, APIs or other) is viewed primarily as a means of cost reduction. A major focus of the company tends to be towards profitability. In some cases technology or data is provided in an open means with an assumption that this will allow others to provide “free” resources and hence reduce costs. In next generation, open is viewed as a competitive weapon, a way of manipulating or changing the landscape through numerous tactical plays from reducing barriers to entry, standardisation, eliminating the opportunity to differentiate, building an ecosystem and even protecting an existing value chain. Next generation are primarily focused on disruption of pre-existing activities (a war phase mentality) and exhibit higher levels of strategic play.

The LEF published the work in Dec 2011 and since then we have observed the diffusion of many of these changes as the traditional become more next generation. In the parlance of “Boiling Frogs” (an outstanding open sourced document on management provided by GCHQ) then we’re seeing “less of” the traditional and “more of” the next generation over time. However, I very much don’t want you to read the above list and get the impression that — “this is how we create an advantage!” — instead be realistic. The above characteristics are already diffusing and evolving, tens if not hundreds of thousands of people and their companies are well aware of them today. You’ll need to adapt simply to survive. Any real advantage has already been taken and any remaining advantage will be over those who are slower to adapt.

I do however what to expand the above figure 123 and include some specific examples of doctrine (see figure 124 below). For example, the shift from single to multiple methods is just an refinement of the principle “to use appropriate methods”. There was a time when we thought that a single method was appropriate but as we’ve become more used to the concepts of evolution and change then we’ve learned that multiple techniques are needed. This doesn’t stop various attempts to create a tyranny of the one whether agile or six sigma or some purchasing method but for many of us the way we implement that principle has changed. In other words, the principle of doctrine has remained consistent but our implementation has refined and become more nuanced. Equally our principle of “manage failure” has simply refined from one time disaster recovery tests to constant introduction of failure through chaos engines. Now, certainly the implementation has to be mindful of the landscape and purpose, for example constant failure through chaos engines is not appropriate for the generation components of a nuclear power plant.

Figure 124 — The change from traditional to next generation

In other cases, the principle “Think small teams” is relatively young in management terms (i.e. less than forty years). The theory of management tends to move extremely slowly and its practices can take a considerable amount of time to evolve. The point that I want to emphasise is that when we talk about the evolution of organisation, this is normally reflected in terms of a change in doctrine and either evolution or addition of principles. However, not everything changes. There are many practices and concepts that are simply copied to the next generation. It should never be expected that there are no common characteristics or overlap but instead what you hope to find is significant difference in specific characteristics (i.e. Mice have two eyes, same as Elephants and hence there are some similarities along with huge differences). I’ve provided a small subset of the similarities in figure 125 but it should be remembered of the 90 odd characteristics I examined, only twelve showed significant change.

Figure 125 — Not everything changes

In 2008, I understood the cycle of change (peace, war and wonder) which had evolved from the concept of evolution and I had a hypothesis for the process of how organisations evolve. By 2011, we had not only anticipated this change but observed a budding next generation. I say “budding” because we had no real idea of whether they would be successful or not. It turns out that they are but that’s a story for a later chapter. For now, there are a couple of refinements that I’d like to make to these models.

Notes on Peace, War and Wonder

There are number of patterns which are worth highlighting.

Climatic Pattern : Evolution of a communication mechanism can increase the speed of evolution overall.

In figure 117 above, I discussed the confusion of speed and how we often mix concepts about the underlying rate of change with the circumstantial overlapping of multiple points of industrialisation. Does this however mean the underlying rate of change is constant? The answer is no. There is another pattern here which deals with communication mechanisms.

On the 1st May, 1840 a revolution in industry was started by the introduction of the Penny Black. This simple postage stamp caused a dramatic explosion in communication from 76 million letters sent in 1839 to 350 million by 1850. It wasn’t a case that postal services didn’t exist before but the Penny Black turned the act of posting a letter into a more standard, well defined and ultimately ubiquitous activity. The introduction caused a spate of copy cat services throughout the world, with the US introducing their first stamps in 1847. The 125 million pieces of post sent through their system in that year mushroomed to 4 billion by 1890. From stamps to street letter boxes (1858) to the pony express, railway deliveries (1862), money order and even international money orders by 1869.

The humble stamp changed communication forever. But it wasn’t alone. Telegraph lines which later enabled the telephone which later enabled the internet have all led to corresponding explosions of communication. In all cases it wasn’t the invention of the system (the first stamp for example being created by William Dockwra in 1680) but instead the system becoming more standard, well defined and more of a commodity which created the explosion. Each time, we’ve experienced one of these communication changes we’ve also experienced significant industrial change. The growth in postal services and telegraph lines coincides with the Railway and Steam Engine era where diffusion of new machine concepts became rampant.

Of course, the origin of industrial steam engines started in the earlier first industrial revolution which itself arguably started with Maudslay’s screw cutting lathe and the introduction of interchangeable mechanical components. By providing mechanical components as more of a commodity, we saw a growth in new machine industries and new manufacturing processes. From the Plymouth system for manufacturing which later became the Armory system in the US, an entirely new method of manufacturing was started by the humble nut and bolt.

Whilst this might appear to be nothing more than the peace, war and wonder cycle in action, there is something quite unique here. When we examine how things have evolved over time then nuts and bolts took over 2,000 years to industrialise, electricity took 1,400 years, the telephone merely 60 to 80 years and computing some 60 to 70 years. What has changed during that time is industrialisation of communication mechanisms. As we move up the value chain (see figure 126) then the speed at which things evolve across the landscape is impacted by industrialisation of communication mechanisms. The printing press, the postage stage, the telephone and the internet did more than just industrialise a discrete components in a value chain, they accelerated the evolution of all components.

Figure 126 — The speed of evolution

Do not however confuse this with how innovative we are as a species. Rather realise that the speed at which something evolves has accelerated. My best guess is the speed of change today now corresponds to about 20 to 30 years on average from genesis to the point of industrialisation and then around 10 to 15 years for the “war” to work through the system and the change to become the dominant form. The jury is out at the moment (i.e. I’m collecting more data) as to whether it really is that fast and not all industrial ecosystems work at the same speed. Obviously, as per figure 117 the confusion of speed then during your lifetime it is likely you will experience multiple overlapping waves or points of industrialisation. However, an increase in the underlying speed means we should experience more of these and life going forward will probably feel a lot more disruptive.

Climatic Pattern : Inertia increases with past success.

One of the subjects I’ve mentioned is inertia and our resistance to change. With any established value chain, there are existing interfaces to components along with accompanying practices. There is a significant cost associated with changing these interfaces and practices due to the upheaval caused to all the higher order systems that are built upon it e.g. changing standards in electrical supply impacts all the devices which use it. This cost creates resistance to the change. You also find similar effects with data or more specifically our models for understanding data. As Bernard Barber once noted even scientists exhibit varying degrees of resistance to scientific discovery. For example, the cost associated with changing the latest hypothesis on some high level scientific concept is relatively small and often within the community we see vibrant debate on such hypotheses. However changing a fundamental scientific law that is commonplace, well understood and used as a basis for higher level concepts will impact all those things built upon it and hence the level of resistance is accordingly greater. Such monumental changes in science often require new forms of data creating a crisis point in the community through unresolved paradoxes including things that just don’t fit our current models of understanding. In some cases, the change is so profound and the higher order impact is so significant that we even coin the phrase “a scientific revolution” to describe it.

The costs of change are always resisted and past paradigms are rarely surrendered easily — regardless of whether it is a model of understanding, a profitable activity provided as a product or a best practice of business. As Wilfred Totter said “the mind delights in a static environment”. Alas, this is not the world we live in. Life’s motto is “situation normal, everything must change” and the only time things stop changing is when they’re dead.

The degree of resistance to change will increase depending upon how well established and connected the past model is. In figure 127, I’ve shown this as inertia barriers which increase in size the more evolved the component becomes.

Figure 127 — inertia increases with success

There are also many forms of inertia. In the example of co-evolution (provided in chapter 9) there were two forms of inertia. The first is due to the success of past architectural practice. The second is caused by the co-evolving practice being relatively novel and hence there existing high degrees of uncertainty over it. Both sources will create resistance due to adopting the change which in this case is the shift from product to utility of computing (see figure 128).

Figure 128 — Practices and inertia

So what makes up inertia and this resistance to change exist in business? That depends upon the perspective of the individual and whether they are a consumer or supplier.

The Consumer
From a consumer of an evolving activity, a practice or a model of understanding then inertia tends to manifest itself in three basic forms — disruption to past norms, transition to the new and the agency of new. I’ll explain each using the example of cloud computing.

The typical concerns regarding the disruption to past norms include: -

• Changing business relationships from old suppliers to potentially new suppliers.
• A loss of in financial or physical capital through prior purchasing of a product e.g. the previous investment needs to be written off.
• A loss in political capital through making a prior decision to purchase a product e.g. “what do you mean I can now rent the billion dollar ERP system I advised the board to buy on a credit card?”
• A loss in human capital as existing skill-sets and practices change e.g. server huggers.
• A threat that barriers to entry will be reduced resulting in increased competition in an industry e.g. even a small business can afford a farm of super computers.

The typical concerns regarding the transition to the new include: -

• Confusion over the new methods of providing the activity e.g. isn’t this just hosting?
• Concerns over the new suppliers as relationships are reformed including transparency, trust and security of supply.
• Cost of acquiring new skill-sets as practices co-evolve e.g. designing for failure and distributed architecture.
• Cost of re-architecting existing estates which consume the activity. For example, the legacy application estates built on past best practices (such as N+1, Scale-Up) and assume past methods of provision (i.e. better hardware) and will now require re-architecting.
• Concerns over changes to governance and management.

The typical concerns regarding the agency of the new include: -

• Suitability of the activity for provision in this new form i.e. is the act really suitable for utility provision and volume operations?
• The lack of second sourcing options. For example, do we have choice and options? Are there multiple providers?
• The existence of pricing competition and switching between alternatives suppliers. For example, are we shifting from a competitive market of products to an environment where we are financially bound to a single supplier?
• The loss of strategic control through increased dependency on a supplier.

These risks or concerns were typical of the inertia to change I saw with cloud computing in 2008, however it wasn’t just consumers that had inertia but also suppliers of past norms.

Suppliers of past norms.
The inertia to change of suppliers inevitably derives from past financial success. For example, the shift from product to utility services is a shift from high value model to one of volume operations and over time declining unit value. There is a transitional effect here which cause a high volume, high margin business for a period of time but we will cover that later. In general, existing suppliers need to adapt their existing successful business models to this new world. Such a change is problematic for several reasons: -

• All the data the company has demonstrates the past success of current business models and concerns would be raised over cannibalisation of the existing business.
• The rewards and culture of the company are likely to be built on the current business model hence reinforcing internal resistance to change.
• External expectations of the financial markets are likely to reinforce continual improvement of the existing model i.e. it’s difficult to persuade shareholders and financial investors to replace a high margin and successful business with a more utility approach when that market has not yet been established.

For the reasons above, the existing business model tends to resist the change and the more successful and established it is then the greater the resistance. This is why the change is usually initiated by those not encumbered by past success. The existing suppliers, not only have to contend with their own inertia to change but also the inertia their customers will have. Unfortunately, the previous peaceful model of competition (e.g. one product vs another) will lull these suppliers into a false sense of gradual change, in much the same way that our existing experience of climate change lulls us into a belief that climate change is always gradual. This is despite ample evidence that abrupt climate change has occurred repeatedly in the past, for example at the end of the Younger Dryas period, the climate of Greenland exhibited a sudden warming of +10°C within a few years. We are as much a prisoner of past expectations of change as past norms of operating.

Hence suppliers, with pre-existing business models, will tend to view change as gradual and have resistance to the change which in turn is reinforced by existing customers. This resistance of existing suppliers will continue until it is abundantly clear that the past model is going to decline. However, this has been compounded by the punctuated equilibrium which combines exponential change with denial. Hence by the time it has become abundantly clear and a decision is made, it is often too late for those past incumbents to survive. For a hardware manufacturer who has sold computer products and experienced gradual change for thirty years, it is understandable how they might consider this change to utility services would also happen slowly. They will have huge inertia to the change because of past success, they may view it as just an economic blip due to a recession and their customers will often try to reinforce the past asking for more “enterprise” like services. Worst of all, they will believe they have time to transition, to help customers gradually change, to spend the years building and planning new services and to migrate the organisation over to the new models. The cold hard reality was that many existing suppliers didn’t comprehend that the battle would be over in three to four years and for many the time to act was already passing. In 2008, they were in the last chance saloon and the tick was clocking towards last orders though they claimed this event was far in the future and they had plenty of time. Like the rapid change in climate temperature in Greenland, our past experience of change does not necessarily represent the future.

In figure 129, I’ve classified various forms of inertia included tactics to be used to counter and various forms of messaging you might wish to consider in your struggle against it. When looking at a map, it’s extremely helpful to identify the forms of inertia you will face and how to counter them before charging straight on into the battle. There’s little worse than leading the charge into battle only to discover the rest of organisation is still getting dressed for a party and is convinced the war is sometime next decade.

Figure 129 — Classifying inertia

One of the more dangerous forms of inertia are financial markets. Despite the illusion of the future thinking world of finance, in most cases stability is prized. There is an expectation set by the market on past results and often significant discounting of the future. If anything, 2008 was a very visible reminder of this as the economy crumbled around us. The problem for a CEO of a hardware company at that time was the market comes to expect a certain level of profit, revenue, growth and return. There is only so much you can do to blame a change on general economic factors (e.g. a downturn) as the market expects you to return to norm and most executives are rewarded on short term measures based upon this. The result is one of the most peculiar aspects of the “war” stage of competition — the death spiral.

Climatic Pattern : Inertia kills

I mentioned previously in chapter 5 how Kodak had inertia which it finally overcame in order to invest in exactly the wrong part of the industry. We often think that companies die due to lack of innovation but this appears to be rarely the case. Kodak out innovated most (with digital still cameras, with online photo services and with photo printers) but it was inertia caused by past success in fulfilment and blindness to the environment that caused it to collapse. Equally Blockbuster out innovated most competitors with its early entrance into the web space, being first with ordering videos online and the first experiments with video streaming. Alas, it was wedded to a business model based upon late fees. There are many different examples of how inertia usually amplified by blindness to a change can cause a company to crumble but none is as common as the death spiral and the cause of it is something which at another time is perfectly sensible — cutting costs.

If your industry (i.e. the parts of value chain which you sell) are in a peace era then cutting costs through efficiency to increase profitability can be a good play, assuming you don’t reduce barriers to entry into the space. There are many reasons why you would do this and often you can clear out a lot of waste in the organisation. However, if your industry has moved into the war then then cutting costs through staff to restore profitability due to declining revenue is often a terrible move. The problem is your revenue is eroding due to a change in the value chain and the industrialisation of the activity to more commodity forms. You need to respond by adapting and possibly moving up the value chain. However, by layoffs you’re likely to get rid of those people who were seen to be less successful in the previous era. That doesn’t sound too bad but the result is you end up with a higher density of people successful in the past models (which are now in decline due to evolution) and hence you’ll tend to increase your cultural inertia to change. In all likelihood, you’ve just removed the very people who might have saved you.

Revenue will continue to drop and you’ll start a death spiral. You’ll start scrambling around looking for “emerging markets” i.e. less developed economies for you to sell your currently being industrialised product into. The only result of this however is you’re laying the ground work for those economies to be later industrialised once your competitors have finished chewing up your existing market. What you of course should be doing is adapting and realising that the tactics you play in one era are not the same as another (peace vs war etc). Now any large organisations has multiple different values chains in different evolutionary phases and you have to see this and know how to switch context between them in order to choose the right tactics. Naturally, most people don’t manage to achieve this, nor do they effectively anticipate change or cope with industrialisation in the right way. This is why big companies often die but at least that keeps things interesting.

Of course, if you do embark on the death spiral then whilst it’s appalling for those employed by the company, the executives are often rewarded. Why? Well, it comes back to the financial markets. If a market knows this transition is occurring then one tactic is to invest in the future industry (e.g. Amazon) whilst extracting as much short term value as possible from the past (e.g. existing hardware players). This requires a high expectation of share buy-backs, dividends and mergers in those past giants. It’s not that you’re expecting a long term gain from such investments but instead highly profitable short term wins which are balanced with your long term investment in the future. From a financial point of view then the death spiral is exactly what you want to see as you don’t care about the long term survivability of the company (your investment will be gone by then) but you do want maximum extraction of value. If you’re a canny executive then running a death spiral can bring big personal financial rewards as long as you’re comfortable with the destruction you’ll cause to people and companies alike. However, not all executives are canny. Often people find themselves in this position by accident. Which leads me to my next topic on the different forms of disruption.

The different forms of disruption

One of the more interesting discussions in recent times has been Professor Jill Lepore’s arguments against Clayton Christensen’s concept of disruptive innovation. In her now famous New Yorker 2014 article on “the disruption machine”, Lepore argued that disruptive innovation doesn’t really explain change, but is instead mostly an artefact of history, a way of looking at the past and is unpredictable. Christensen naturally countered. For me, this really was a non-argument. What I had determined back in 2008 was there are many forms of disruption — some of which are predictable and some of which aren’t. When the argument started then from my perspective, both Christensen and Lepore were right and wrong. The problem stems from the issue that they’re not arguing over the same thing.

The three main forms of potential disruption that we will discuss are genesis, product to product substitution and product to utility business model substitution. The genesis of new acts are inherently unpredictable. If some novel activity appears that genuinely alters pre-existing value chains then there’s little you can do to predict this, you have to simply adapt.

When product to product substitution occurs due to some new capability or feature then the predictability of when and what is low. The when depends upon individual actors actions and this is unknown. Equally, the addition of some new capability is also inherently unpredictable. Note, we know that things will evolve and the pathway for evolution (from genesis to commodity) but we don’t know nor can we predict the individual steps such as this product will beat that product. This means a new entrant can at any time create a disruptive product that will substitute an existing market but a company will have no way of ascertaining when that will occur or what it will be. Though this does happen, in the time of peace, the time of product giants then such changes are less frequent than the rampage of sustaining changes. There are exceptions and Apple’s iPhone disrupting the Blackberry is a good example of this type of disruption. I’ll note that Christensen quite famously dismissed the iPhone and has subsequently gone on to claim it’s not an example of it, in any case this sort of substitution is unpredictable. Equally hydraulic vs cable excavators would fall into this category. They are easy to analyse post event but next to impossible to determine pre-event. In these instances, Lepore seems to be on firm footing.

With product to utility substitution the what and when can be anticipated. We know we’re going to enter a state of war, an explosion of higher order systems, co-evolution of practice, disruption of past vendors stuck behind inertia barriers and so forth. Weak signals and the four condition (suitability, technology, concept and attitude) can give us an idea of when it will happen. In any case, even without the weak signals, the transition to more industrialised forms is inevitable if competition exists. So, we can be prepared. A new entrant can more effectively target this change to disrupt others. However, it also means an existing player can effectively mount a defence having prior knowledge of the change and time to prepare. Fortunately for the new entrants, the incredibly low levels of situational awareness that exists in most industry combined with the inertia faced by incumbents in terms of existing business models, developed practices, technological debt, behavioural norms, financial incentives, Wall Street expectations and self interest are often insurmountable and hence the start-ups often wins when they shouldn’t. Whilst the change is entirely defendable against (with often many decades of prior warning) companies fail to do so. This form of disruption is entirely predictable and it is here where Christensen’s theory excels. The more industrialised forms are considered lower quality, not meeting the performance requirements and usually dismissed by the incumbents.

Hence let us follow the evolution of an act. We start (in figure 130) with the appearance of some new activity A[1]. It is found useful and starts to diffuse with custom built examples. As it evolves early products start to appear and we jump across one inertia barrier from custom built to products (point 1). Obviously those companies that have invested in their own custom solution argue that their solution is better but eventually pressure mounts and they adopt a product. The act continues to evolve with a constant stream of more “feature” complete products as we understand the space. Sometimes the progression is sustaining but sometimes a product appears that substitutes the previous examples. There’s inertia to the change (point 2) from customers and vendors invested in the existing product line. The thing is, we don’t really know if this new product line is going to be successful, any more than Apple new it could beat Blackberry or others. This form of disruption is unpredictable. Someone wins. The product giants continue to grow until eventually the act become suitable for industrialised provision. New entrants jump the barrier first (point 3) and this barrier is significant. That act has become established in many value chains and it is highly connected with its own practices. There’s a lot of dismissal of the industrialised version, claims it will take a long time but the punctuated equilibrium bites, the past vendors are struggling, practices have co-evolved and the old way is now legacy. Many past vendors start the death spiral in the hope of recapturing their glory days, their demise accelerates. This form of disruption was predictable but for most it wasn’t. Of course, the world has moved onto to inventing novel and new things built upon these industrialised components (point 4), new forms of organisation appear based upon those co-evolved practices. A next generation of future giants has arisen. Whether we notice them depends upon whether the cycle is localised at a micro economic scale to a specific industry or in other cases the component is so vastly connected it appears at a macro economic scale. In any case, the cycle continues. Ba da boom. Ba da bing.

Figure 130 — Different types of disruption

Dealing with disruption

The problem is there isn’t one form of disruption and hence there isn’t one way to deal with it. The techniques and methods you need to use vary. Unfortunately, if you don’t have a map of your landscape and you don’t understand the basic climatic patterns then you don’t have a great deal of chance in separating this. For most people, it’s all the same thing and they end up facing off against highly predictable disruption without any preparation or planning. In 2008, this was common in the computing industry. I’d end up with many arguments in boards pointing out the cloud computing (the shift from product to utility) was inevitable and not a question of “if” but “when” and that “when” was starting now. I’d explain the impacts and how they were going to be disrupted and people would retort with product examples, they’d start discussing the current situation with Apple vs Blackberry and how Blackberry could counter. These weren’t even remotely the same thing. Don’t mix the unpredictable world of product vs product substitution with the predictable world of product to utility substitution. In figure 131, I’ve provided three main types of disruption and the characteristics associated with each.

Figure 131 — Dealing with disruption

From the above :-

The genesis of powered flight was with Félix du Temple de la Croix in 1857. What! No Wright Brothers? Well, this came later but since my American cousins get very sensitive on this topic, we will skip ahead to the much later. I’ll just note Eliot Sivowitch’s law of First — “whenever you discover who was first, the harder you look you’ll find someone who was more first” — and hence the first electric lightbulb was Joseph Wilson Swan, the person who actually flew a kite into the night which was hit by lightning was Thomas-François Dalibard and when it comes to the telephone, bar shenanigans with patent clerks then we owe a debt to Elisha Gray. Cue endless arguments and gnashing off teeth.

Let us however stick with the Wright Brothers who invented powered flight to end all wars. The first planes sold to the US Army in 1909 were observation planes and the common idea of the time was “With the perfect development of the airplane, wars will be only an incident of past ages.” There was no existing practice associated with aircraft, there was some inertia to their adoption (similar to British concerns over the machine gun prior to World War I) and it was notoriously difficult to predict what would happen. Rather than airplanes ending all wars because no army could gain an advantage over another (all movements could be observed from the air), a rather different path of development occurred and bombs and machine guns were soon attached. With the genesis of such an act like powered flight, it’s difficult to anticipate what might change and your only defence is to adapt quickly. In such circumstances a cultural bias towards action i.e. quickly responding to the change is essential. With the example of Apple vs RIM (i.e. Blackberry) then similar characteristics exist. There are existing practices but a different type of smart phone product does not significantly change this. Again, the main way to react is to spot the change quickly (through horizon scanning) and have developed a culture with a bias towards action. These sorts of change are notoriously difficult to defend against. In the case of cloud computing then there was high levels of inertia and co-evolution of practice to tackle. However, the change was highly predictable and trivial to defend against. Despite this, most failed to react.

Some final thoughts

We’ve covered a lot in this section from refinement of the peace, war and wonder cycle to the introduction of different climatic patterns, to the manner in which organisations evolve and the different forms of disruption. There are a couple of things I want to call out in particular.

Do the states of peace, war and wonder really exist?
No, it’s just a model and all models are wrong. The model appears to predict secondary effects such as organisational change, it is developed from first principles of competition and there seems to be historical precedent. However, it’s no more than appearance at the moment until such time as I can confirm future points of industrialisation and even then I still have the question of whether that was just luck.

Do the states just effect individual activities in industries or could they have a wider effect?
The cycle’s effect depends upon how connected the components are. If they’re involved in many value chains then this can have a pronounced macro economic effect. When considering economic systems we have to look at them as we do with biological systems and consider how an ecosystem reacts to a change and how competition will drive that change throughout the system.

Can we anticipate organisational change?
We know roughly when such changes should occur (from weak signals) though we cannot detail what the impact will be, as in whether new doctrine will appear or what doctrine will refine? Population dynamics on companies is a non trivial exercise due to inherent bias in questions and responses. However, we can at least say something reasonable about the process of change and its likelihood.

Is life getting faster?
Certainly the evolution of acts appears to have accelerated but don’t confuse that with a higher rate of innovation. It’s highly questionable whether we have become more innovative as a species though we certainly can’t rely on novel things to create a differential for long. Furthermore be careful to avoid confusing multiple and coincidental points of industrialisation with a general change of speed.

There are also a number of climatic patterns which I’ve mentioned that are worth noting.

• Evolution of a communication mechanism can increase the speed of evolution overall. Not only can evolution not be measured over time but the speed of evolution is not constant over time.
• Inertia increases with past success. Be careful with inertia, it will grow and tempt to you away from change even when you must.
• Inertia kills. It’s rarely lack of innovation that gets you but past success.
• Change is not always linear. Not all change is smooth and progressive, some is very rapid and be wary of being caught out by a slow moving past.
• Shifts from product to utility tend to exhibit a punctuated equilibrium. Probably one of the most dangerous times or the biggest opportunity depending upon whether you’re an incumbent or new entrant.
• There are many different forms of disruption (two broad classes are predictable vs non predictable). Don’t get caught into the trap of thinking that all disruption is the same.
• A point of “war” is associated with organisational change. It’s not just things that evolve but entire organisations.

I’ve marked off all the patterns we’ve covered so far in orange in figure 132

Figure 132 — Climatic patterns

An exercise for the reader

The first thing I’d like you to do is to look at figure 124 — the change from traditional to next generation — and determine what type your organisation is? Are you adopting those principles or is there some context specific reason why you cannot? Have you challenged this?

The second thing I’d like you to do is looking at your maps, start to consider what sort of inertia you might face in changing the landscape. Use figure 129 — classifying inertia — as a guide.

Lastly, I want you to try and discover components in your value chains that are on the cusp of becoming industrialised and shifting from product forms. Ask yourself are you prepared for such a rapid change? What planning have you in place? How will you deal with the inertia?

The book so far

Chapter 1 — On being lost
Chapter 2 — Finding a path
Chapter 3 — Exploring the map
Chapter 4 — Doctrine
Chapter 5 — The play and a decision to act
Chapter 6 — Getting started yourself
Chapter 7 — Finding a new purpose
Chapter 8 — Keeping the wolves at bay
Chapter 9 — Charting the future
Chapter 10 — I wasn’t expecting that!
Chapter 11 — A smorgasbord of the slightly useful
Chapter 12 — The scenario
Chapter 13 — Something wicked this way comes
Chapter 14 — To thine own self be true
Chapter 15 — On the practice of scenario planning
Chapter 16 — Super Looper
Chapter 17 — To infinity and beyond
Chapter 18 — Better for Less

This post is provided as Creative commons Attribution-ShareAlike 4.0 International by the original author, Simon Wardley.

Simon’s site and other writings https://www.swardleymaps.com/
EPUB and PDF versions https://www.swardleymaps.com/writings-books#wardley-maps

I wasn’t expecting that was originally published in wardleymaps on Medium, where people are continuing the conversation by highlighting and responding to this story.