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,
