Friday, May 12, 2017

Is my diagram a map?

Let us take a systems map


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


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

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


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

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

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

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

Friday, April 21, 2017

The book so far

Writing is not something I find comfortable. Lately I've been consumed with putting together a book on mapping. It's getting there. Slowly.

Chapter 1 — On being lost
An introduction into the concept of situational awareness and the strategy cycle.

Chapter 2 — Finding a path
How I built my first map of business.

Chapter 3 — Exploring the map
The shock of discovering common economic patterns.

Chapter 4 — Doctrine
The even bigger shock of discovering that some patterns are universal whilst others are context specific.

Chapter 5 — The play and a decision to act
Using maps to make a choice including some basic strategic play such as ecosystem models.

Chapter 6 — Getting started yourself
How to start mapping and some useful books to read.

Chapter 7Finding a new purpose
Using mapping on itself and discovering a new purpose. The underlying work on evolution.

Chapter 8Keeping the wolves at bay
The dangers of simplicity and the concept of flow.

Chapter 9 —Charting the future
The use of weak signals and economic cycles.

Chapter 10 — I wasn’t expecting that!
The evolution of organisations and different forms of disruption

Chapter 11 — A smorgasbord of the slightly useful
A collection of useful mapping topics that by pure coincidence might be needed for the following scenario.

Chapter 12 — The scenario
Something for you to get your teeth into.

Chapter 13 —Something wicked this way comes
Analysis of that something from chapter 12.

Chapter 14 —To thine own self be true
The path you probably should have taken in chapter 12.

Chapter 15 — On the practice of scenario planning
On scenario planning and the concept of roles. Diving a little more deeply into financial modelling.

Chapter 16 — Super Looper
A walk through of severals loops of the strategy cycle.

I've around 4-5 more chapters to go and then this first pass, this introduction into mapping, should finally be finished. Except of course for the rewriting, editing, rejigging, frustration, burying in soft peat for 6 months in triplicate, tearing up, cursing etc etc.

Thursday, April 20, 2017

Round, round, get around, I loop around

Chapter 16

(draft)

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. The variations to the real world include it was I, not the client, that proposed this concept of worth based development and I put in the effort to build those numerous financial models. True to form however is I also fought plenty of internal battles over inertia to make this project happen. In this case, I’m going to use that LFP scenario to examine mapping in practice. 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 provided 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. 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’ll elect not to.

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, in the LFP scenario a map has been kindly provided by engineering along with the more common financial models. As tempting as it is to dive straight into the financials, start with the landscape. 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. 

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.

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 like code execution platforms, some new-fangled practice (a sort of DevOps 2.0) will emerge. We don’t know what those practices will be as they emerge in the uncharted space. We don’t know when precisely this will occur. But we know that we will have inertia to this change. We also know that such changes tend to be rapid (another common economic pattern known as the punctuated equilibrium). We can also go a bit further. 

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

Figure 201 – flows of capital


Capital flows to the more industrialised components along with the new higher order systems that these enable - collectively we can this 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 news 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 should 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 201 – 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. In this case, I’m looking for product characteristics with the emergence of commodity.

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 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 it wouldn’t take me long to find a bunch of them talking about how a “cup of tea is a innovative platform” such is the gibberish which has invaded management.

From the cheat sheet, comparing stage III (product) and IV (commodity), then: -

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 exit. 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. We, if we go back to 2004 then journals were dominated by 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? Well, 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 wobbled 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 the field is considered to be a domain of “professionals” OR are platforms now considered trivial, almost linear in operation and a formula to be applied? Again, with this though we’re getting there, product still wins and hence it’s now 4/6.

User perception? When it comes to platforms are they increasingly common, a developer would be disappointed if it was not used or available, there is a sense of feeling left behind if your company is not using it 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 it’s 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) rather than an actual difference in creates 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 understand platforms and vendors are focused on exploiting them? OR are platforms more in the high-volume space, mass produced with reducing margin. Are platforms important but increasingly invisible and an essential 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 increasing our education of them 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 and with established metrics. This is a tough one, I steer to the side of commodity but can easily see a case for it being still in product. However, I’m going to give this to commodity 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 this all the time. But do we have an expectation that the entire platform system won’t fail? Are we focused on constant improvement, 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 kind of blue do you want that fire 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 to commodity out of 14 – 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 (as in code execution) 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 is but it’s jumped from one stage (product) to the next. 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 commodity (stage IV) 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. 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 exploit and surrender to the past. My cultural heritage is more inclined to investing in the new space rather than just exploiting the legacy. 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.

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. 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 provide a range of outcomes for two variants (the build in-house, 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. I’ll explain a little more on how to do this later. In figure 204, I’ve added probability onto the financial models for each of the variants – variant 1 (build in-house) and variant 2 (use the public platform play). 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.

Figure 204 – Options analysis

Given this probability profile then the best expected return comes from variant 1 i.e. 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. Can we somehow financially account for inertia and future position? Yes. The essential question between variant 1 and variant 2 is the following – are we prepared to gamble $435k of expected return to explore and potentially secure a more lucrative but undefined future? To analyse this is very complex. So, what do we do? Well, I will build monstrous complexities for navigation but 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 (1) and public platform (2). 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 (2) 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 you. The “retiring CEO” will plummet for variant 1, the “warrior CEO” will go for variant 2. 

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 nearly right-ish.
As with most things in life, there exists huge amounts of uncertainty over which outcome will occur 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 simple concepts but 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 X will fail to deliver or succeed? We create a bond (called project X) which will pay a certain return (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 and a bit gutted if it succeeds. 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 this more to point out that there are lots of ways of skinning Schrodinger’s cat and finding probability. The question is always how much that information is worth to you? The cheapest way is to guess yourself, the slightly more expense is to aggregate other people’s 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”. This doesn’t mean one outcome will happen, it’s just a probability. We still must roll the dice. However, what we know so far is that we have this opportunity to build an LFP system, there are two variants (one in-house, one using a platform play) 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 topic 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, those are usually however 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 skills necessary. 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 existing and perfectly valid best practice (for a product world) becomes 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 are “Loss of political capital” and “Change of business relationship (loss of social capital)”

The “Loss of political capital” includes fear over being relevant 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 it. At this stage, such action is relatively trivial. The practices haven’t been developed and so there’s plenty of time for training, reskilling and the recreation of essential system concepts in a more utility platform world from configuration to management to operation to monitoring. It’ll be different from the past but someone should develop that capability, no-one yet has those skills and why shouldn’t it be your Systems team? Unfortunately, what 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. There’s often a pre-existing relationship with vendors who might be supplying products or services. In normal circumstances, you can deal with this 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 Systems) 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. It’ll make it much harder for you to overcome any “loss of political capital” if you’re late to the conversation. 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 facepalms.

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

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 unavoidable Change, that is already happening in the market and outside of your control. You cannot ignore it.

“Cost of acquiring new skillsets” is one of the more bizarre sources of inertia because the cost will often increase especially in a punctuated equilibrium where a shortage of skills is a common consequence. 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 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 is the market. 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 relationship, assuming you have a market that is industrialising to a commodity. Most of this can be overcome with strategic planning and examination of different scenario 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 through endless cost cutting to recreate the past.

"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 go for a higher short term expected return or trade some of this for building a future position. Though we have inertia, we 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 to give us an idea (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. In over a decade of using mapping to explore economic systems then as far as I’m aware you can only anticipate the change and refine the “when” of evolution using characteristics (as above), weak signals and probability (including information markets). Of course, I’m fully aware that I have my own inertia caused by my past success with mapping and that the subject itself will evolve. 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 – 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 the map and we will focus on the platform change as we’ve been previously building our own systems and I’ll assume that we know how to do this. In figure 206, I’ve outlined the two obvious cells that we need to consider.

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 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 somewhat 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 gameplays. 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 skillsets 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. 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. Now going to add my structure around the platform space onto my LFP map. See figure 208.

Figure 208 – Future orientated LFP map


The first thing 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 but to be honest the client hasn’t mentioned 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, 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 in much the same way that people in business are comfortable with SWOTs. 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 use 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 replace your twenty years of 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 the effort and thought necessary into using 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 will 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. 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 play the future game and roll the dice.

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 complex. 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? 


1) Engineering says they could improve code efficiency by 75% for $350K

2) 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


I’ve started with outcome 2 (what is happening) as the base case and simply added the change. The first thing to notice is that the development proposal doesn’t make the case better, 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. As said as it is to say, it’s often difficult to justify spending more money on a refactoring effort in such circumstances. The marketing proposal gives us some uplift. At least it recovers some of the pain. Our final return is still below our normal expected return 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.

Ok, so let us repeat this exercise but now look at variant 2 – the public platform play. 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 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 better return! A huge return! Hang on, how’s that possible? Well simply put, we’re paying for consumption of our utility code execution environment (such as AWS Lambda) based upon use. 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 around consuming services and 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 its positive? On a consumption basis, the cost (including not only marketing but operation) for each new user marketing acquires significantly exceeds the revenue they create and so it’s a loss at this price. But in the first variant, then most of the costs have already been spent in the initial upfront investment. In which case given we’ve already spent most of the money, we may as well spend a little bit more to get the revenue. Hence the divergence here. The marketing proposal makes sense in the in-house variant because you’ve already blown most of the cost but it doesn’t in the second because there’s direct linkage of actual cost against revenue.

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 user (i.e. marketing plus operational) is now less than the revenue they create. Hence the last option gives us the best choice and that’s where we invest. This shift towards this utility platforms and billing at the functional level fundamentally changes your entire investment approach in projects. Refactoring suddenly becomes a financial consideration. The true costs (not just acquiring but operating) of marketing are exposed. Where you invest changes. Hence, we’re already starting to experience some of those co-evolved practices and this looks a big change. In fact, I know it’s going to be enormous which 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. 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 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, 

Tuesday, April 11, 2017

On the practice of scenario planning

Chapter 15
(draft)

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. I win, you lose or vice versa) as both can often benefit, your focus should be on maximising your advantage. It is almost inevitable that the pursuit of such will result in conflict whether it’s the shareholders desire for profit versus the consumers desire for lower product cost or some other trade off. 

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 perspective. 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? 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 and you have to balance another conflict, present action versus future. Become too Machiavellian, too brutal and 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. The practices of mapping are the trivial entry point into this world. 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 like story-telling, magic frameworks such as 2x2s and secrets of success - we paper over a complex world with simple to understand “truths” regardless of how incorrect they are. It makes management easier.

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 a pattern of change 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 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 products construction. I’ve marked examples of this onto figure 189 for our product, A1. 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 is still maintained i.e. 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. 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 and describe the success of the iPhone, there was no guarantee that the iPhone would succeed or help 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 and the exploitation of an existing position to create a future position. Substitution doesn’t happen overnight and there is still value to be extracted from the “legacy” position before any crisis point is reached. I can use this time to leapfrog the competitors by building a better or adjacent product that exploits the change in the market or even employ a more radical shift or some combination of the above with concepts of differentiation. I have the skills, experience, knowledge, brand (another form of capital), process and data within my company to do this. I might not have the culture though and there is still the inertia to overcome, so it’s not a trivial problem. As a founder CEO, my tendency will often be towards the fight - I’ve built this company, I want to succeed and I want to create a glorious future for my people. I can create a vision, I can sell a purpose 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 through constant market monitoring and react quickly enough then I can often overcome it. This requires 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 for a moment into that of the hedge fund manager. 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 CEO / Founder 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. 

However, 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’s a number of contributory 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 act (a move from product to utility) will result in co-evolved practices. This will also apply to data and our knowledge of the space. I’ve marked this change in figure 193.

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 and when combined with a rapid speed of change then this doesn’t help me to adapt. 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 so are 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.

Hence, we now have three major sources of inertia to contend with - our past sales data, the change of practice (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). I’ve marked these sources of inertia onto figure 194.

Figure 194 - three points of inertia.


But, it’s 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.

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 a new set of uncertain activities. This is 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 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.

Of course, it didn’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. Unfortunately - or fortunately, depending upon your perspective - almost all companies fail to understand such basic economic patterns and hence fail to anticipate and prepare for them. However, let us assume that though you face this unfortunate position of being substituted by a utility that you’re the warrior style CEO and won’t give up the fight. You are Queen Boudica, the warrior leader, the stuff that legends are made of. Well, it’s not only the 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. 

Let us focus for a moment on cloud computing as it represents a timely example 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 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.

In such a case, it is true for you that longer term capital gains will be made by investing in that future focused space but 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 and as long as those companies are returning capital to shareholders then a short term benefit exists. 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, this assumes that the CEOs playing in the legacy space know their role. The ideal scenario for hedge funds are companies that are sweating legacy business models to return value to shareholders which can be combined with acquisition of equivalent business (again for synergies). 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 cracks start to appear, I'd be moving capital out of the legacy space and start shorting. 

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 the CEO / founder of a company in that legacy position then you are likely to ask what’s the plan for the future? 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 don’t react well to this. 

As the CEO, 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’re 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. 

What grand mistake?
This is known as the spiral of death. 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 into new industries (more evolved utilities along with higher order systems that have been created on top of this) and we’re watching this marvellous new world forming but we’re on the sidelines. The good news is we’re maintaining our position for now through sweating and possibly acquiring legacy assets. You’re going through the fairly difficult time of cutting costs in order to restore profitability due to declining revenue. 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.

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. Unfortunately, we also tend to remove the radicals, the trouble makers and the pioneers i.e. those often annoying people who are likely to stick a soldering iron into a pot of ink, create inkjet printers and save the company. 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. 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.  

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. But don't forget, you got lucky. There’s nothing wrong with that. 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’ll be buying time for to come up with that lucky break. You need 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, 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.

So 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 of 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 (electricity) opens up adjacent possibilities of novel higher order systems (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. They don't tell you what to do.

With that in mind, I buried several common failures of sensible executives within the Phoenix scenario. 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 the 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. 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 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 and it's far too easy for the competitor to play a tower and moat game i.e. for them to copy any successful differential you create. The effect of the tower and moat play is that whilst the competitor continue to build up and strengthen their future position (the tower) in a utility space then your efforts to differentiate in a product world end up just enhancing this by helping the competitor to copy and grow a moat devoid of differential value around their tower. When you finally make the plunge into the future market then you're likely to have been delayed because of efforts to differentiate (not a good move in a punctuated equilibrium i.e. rapidly changing market) and you will have nothing different to offer from the now incumbent competitor. This is pretty much a disaster. 

We need to cut costs to return profitability
Whilst cost cutting can be useful, when you use it to attempt to recreate the past then 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, use this to buy more time and encourage that 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 differentiate.
In a product to utility substitution then the danger here can be twofold. 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. The second problem depends upon whether your competitor is using some form of ecosystem model. If they're using an ILC (innovate - leverage - commoditise) like 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. Consider that to be Amazon's entire R&D effort and ask, do you really have what it takes?

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 conglomerate 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 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 been 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 the two variants (in-house, public) of the scenario with each variant 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 first variant, some disposal figures have been provided for the in-house assets assuming these are not repurposed.

Figure 195 – Variant I, the In-house model



Figure 196 – Variant II, the public platform model


Engineering
Development has also provided a map of the space including the two variants. The variants are explained as simply 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.  This has a significant change in terms of providing function based billing where 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 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.

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, it states that it can build the environment more effectively than a generalised public provider. 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 any 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'll 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