The LFP example is based upon a real-world event. I say “based” because I usually take time to disguise the actual event to protect any guilty parties. In this case, the haphazard and stumbling CEO was … me. I’m very wary that my long experience with mapping means that I tend to gloss over parts through assumption. In much the same way, I spent six years assuming everyone already knew how to map and it wasn’t until 2011 that I started to realise they didn’t. With that in mind, I’m going to go into excessive detail in the hope that I don’t miss anything useful to you. To keep it relevant and not just a history lesson, I’m going to go through the steps of how you would tackle the LFP scenario as if it was happening today.
I always start with the strategy cycle. To me, it doesn’t matter whether I’m looking at nation states, industry, corporates, systems or even individuals — the strategy cycle applies. For completeness, I have repeated this cycle in figure 198.
Our initial purpose for this LFP system is to help create leads for our client. That is what they need and it is also how we will be measured and paid. We don’t have to agree to the proposal but if we choose to accept it then our focus must start here. Of course, we have our own needs — to survive, to make a profit, to have fun — which we could choose to map. In this case, I’ve chosen not to because this is a teaching aid and I want to keep it simple.
We know we also have a “why of movement” question in the scenario — do we build the entire system “in-house” or do we use elements of a “public” platform? Do we go here or there? Why? Before we can answer this, we need to understand the landscape a bit more. Fortunately, a map has been kindly provided by engineering along with the more common financial models. I do love a good spreadsheet, I’ve spent years of my life immersed in cashflows, GAAP, chart of accounts, options analysis, business models and all manner of delightful things. However, a word to the wise, put these to the back of your mind for the moment. The financials can often be skewed by a bias to the present. So, as tempting as it is to dive straight into the financials, start with the landscape.
With the map provided, one immediate thing I’m going to note is that we have inertia against using the public platform space via both security and the systems group. I’m going to mark that onto the map in figure 199 and cut out the superfluous “in-house”, “public” terms as it should be obvious by now.
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
By applying that basic pattern to our map, we can anticipate that as the world shifts towards more utility platforms, some new-fangled practice (a sort of DevOps 2.0) will emerge. We don’t know what those practices will be as they will emerge in the uncharted space. But we do know they will emerge shortly after the formation of utility platforms and that we will have inertia to this change. We also know that such changes tend to be rapid (the punctuated equilibrium) and we can also go a bit further in our “prognostications” or as I prefer to call them, cowardly custard pronouncement of self evident trends.
The nodes on the maps represent stocks of capital. The lines represent flows of capital between stocks. With evolution from product to a more industrialised form then we normally expect to see flows of capital away from the past industry into the more industrialised providers and / or new higher order systems and / or new practices. I’ve marked on these flows of capital and were to invest and what will become legacy onto figure 201.
We describe these industrialised components along with the new higher order systems that they enable as the “new industry”. There will also be new practices (i.e. co-evolved) that will replace those past practices. The new higher order systems will themselves enable new needs (technically, they expand the adjacent possible, the realm of new things we can do) which means new customers. The past ways stuck behind inertia barriers, increasingly devoid of capital will die off.
If this sounds familiar, then it should. This is what Joseph Schumpeter termed “Creative Destruction”. The question is when will this happen? For that I turn to weak signals and examine those four conditions — does the concept of utility platform exist, is the technology there, is it suitable and do we have the right attitude? See figure 202.
In this case, someone is providing such a platform hence the concept and technology exist. We have services like AWS Lambda. In the scenario, there’s obviously some sort of dissatisfaction with the current models otherwise the client wouldn’t be looking for a new way of doing things. The attitude seems to be there, maybe this platform space will help? But is it really suitable? I tend to use weak signals to help determine that but you can also use the cheat sheet. When you examine an activity, it often has characteristics from more than one stage of evolution e.g. it might be strongly product and a little bit commodity or vice versa. You can use this to help you refine your understanding of where something is by simply going through each characteristic and counting “is it more this or that?”
When discussing something about to evolve from one stage to another then I’m looking for more of the evolved characteristics. In this LFP case I’m looking for whether platform has more “commodity” characteristics. I’ve published a more advanced cheat sheet in figure 203, with each stage (I to IV), the terms used for different types of components (activities, practices, data and knowledge) plus the general characteristics.
So, let us examine the platform space today in 2017. What we’re focused on is a code execution environment which in the product world is normally described as some form of platform stack (e.g. LAMP or .NET) or in the utility space where we have the emergence of systems such as Lambda. It’s important to focus on the “code execution environment” as unfortunately platform is one of those hand wavy terms which gets used to mean any old tripe — see also ecosystem, innovation, disruption and almost anything in management that is popular. Don’t get me started on this one as I’m not a fan of the field I work in. I’m sure along with strategy consultants talking about “earlobes for leadership” (HBR, Nov, 2011) then I suspect it wouldn’t take me long to find a cacophony (the collective noun for a group of strategy consultants) of them talking about how a “cup of tea is a innovative platform” or some other load of dingo’s kidneys.
From the cheat sheet, comparing stage III (product) and IV (commodity), I’ll score up how many commodity characteristics exist for platform: -
-
Ubiquity? Is the platform space rapidly increasing OR widespread in the applicable market? I think it’s fair to say that this is very widespread. It’s not a case that you normally have to suggest to a developer that they consider using a platform to build something, they often have their favourite stack whether it’s LAMP or something else. We can give a tick for commodity here. [1/1]
-
Certainty? Are we seeing a rapid increase in use (i.e. rapid diffusion in all companies) with platforms that are increasingly fit for purpose OR are they already commonly understood, just an expected norm? I think we can say most developers would be surprised to walk into a company that was excited about its platform roll-out. They’d expect some sort of platform to exist. Strike two for commodity. [2/2]
-
Publication types? Are trade journals dominated by articles covering maintenance, operations, installation and comparison between competing forms of platforms with feature analysis e.g. merits of one model over another? OR are trade journals mainly focused on use, with platforms becoming increasingly an accepted almost invisible thing. If we go back to 2004 then journals were dominated by discussion on this platform or that platform — LAMP vs .NET and the best way to install. Today, this is much less and most of the discussion is about use. Strike three for commodity. [3/3]
-
Market? When we examine the platform market are we talking about a growing market with consolidation to a few competing but more accepted norms? OR are we talking about a mature, stabilised market with an accepted form? From my perspective then the platform market seems mature and stable with an accepted form — .NET, Java, NodeJS, LAMP etc. Commodity wins. [4/4]
-
Knowledge management? Are we mainly learning about how to operate a platform, starting to develop and verify metrics for performance OR is this field established, well known, understood and defined? In this case, platform probably wobbles on the side of product rather than commodity. Hence, product wins and it’s now [4/5] for commodity.
-
Market Perception? Do we have increasing expectation of use of some form of platform and is the field considered to be a domain of “professionals” OR are platforms now considered trivial, almost linear in operation and a formula to be applied? Though we are getting there, product still wins and hence it’s now four to commodity out of six. [4/6].
-
User perception? When it comes to platforms are they increasingly common and a developer would be disappointed if it was not used or available? Would there be a sense of feeling left behind if your company was not using a platform OR are they standard, expected and there would be a feeling of shock if you went to a company that didn’t use some form of standard platform (whether .Net, LAMP or other). I think I can probably say that commodity wins this one, it would be shocking to find a company that didn’t use some form of platform approach and it’s that “shock” which tells you this is in the commodity space. [5/7].
-
Perception in Industry? Advantage in platform is now mainly seen through implementation and features (i.e. this platform is better than that platform) OR platform is now considered a “cost of doing business”, it’s accepted and there are specific defined models. It would be difficult to imagine a software house today that didn’t view a platform as a “cost of doing business”, so whilst there’s some wobble, I’d argue that commodity edges this. [6/8].
-
Focus of value? Are platforms considered to be areas of high profitability per unit and a valuable model? Do we feel that we increasingly understand platforms and vendors are focused on exploiting them? OR are platforms more in the high-volume space, considered “known”, often mass produced with reducing margin. Are platforms essentially an important but increasingly invisible component of something more complex? In this case, especially with provision of utility like services then commodity wins again. [7/9].
-
Understanding? In the platform space are we focused on education with a rapidly growing range of books and training combined with constant refinement of needs and measures? OR do we believe platforms and the concepts around them to be well defined, almost stable, with established metrics and even respected certification programs. This is a tough one, I steer to the side of commodity but can easily see a case for it being still in product. [8/10].
-
Comparison? Do we have competing models for platforms with feature difference? Are authors publishing some form of evidence based support for comparison i.e. why this platform is better than that because of this feature and why you should use them over not use them? OR are platforms just considered essential, an accepted norm and any advantage is discussed in terms of operations — this is cheaper or faster than that? This is a tough one but in this case, I’d edge towards product. We’re not quite at the pure operational comparison. Product wins. [8/11].
-
Failure modes? When it comes to a platform is failure not tolerated? By this, I don’t mean there is no failure — a distributed environment based upon principles of design for failure copes with failure all the time. But do we have an expectation that the entire platform system won’t fail? Are we focused on constant improvement? Do we assume that the use of such a platform is the right model and there exists some resistance to changing it? OR have we gone beyond this, are we now genuinely surprised if the platform itself fails? Is our focus on operational efficiency and not stopping the fires? Whilst there will be many companies with the home-grown platform effort and inevitable out of control fires, as an industry we’ve moved into the commodity space. [9/12].
-
Market action? Is the platform space entrenched in market analysis and listening to customers? What shade of blue do you want that wheel to be? OR has it become more metric driven and building what is needed? Commodity wins here, just. [10/13].
-
Efficiency? When it comes to platforms are we focused on reducing the cost of waste and learning what a platform is OR are we focused on mass production, volume operations and elimination of deviation? Again, especially since utility services such as Amazon Lambda now exist then I’d argue commodity edges this. [11/14].
-
Decision Drivers? When making a choice over what platform to use, do we undertake a significant analysis and synthesis stage, gathering information from vendors and analysts on its suitability OR do we just pick the platform based upon previous experience? Tough one, but again I view that commodity just edges this in the market overall though some companies love their requests for tender. [12/15].
Overall, we can safely say that the platform space is firmly in stage IV (commodity + utility) in 2017. It’s also fair to say that platform isn’t quite yet the industrialised commodity that electricity and there’s a bit further to go.
Hence, what do I know from my map and the basic patterns so far? Platform is moving into stage IV (an industrialised component) with provision of utility services. This will happen rapidly (a punctuated equilibrium) with such a shift (known as the “war”) normally taking 10–15 years. There will be a co-evolution of practice associated with this. Many companies will have inertia. Capital will flow into the more industrialised platform space and those higher order systems built upon it — there is going to be lots of future opportunity here. Capital will also flow out of those spaces stuck behind inertia barriers, not exactly where you want to be. Or is it?
At this point, we need to think about our purpose. My goals as a “retiring” CEO might be very different from the “upstart warrior” CEO. Let us assume I’m more Queen Boudica than Victor Meldrew and I want to fight for a bold future for my “people” rather than just giving up on the battle and exploiting where we are for my comfortable “retirement”. My cultural heritage is therefore more inclined to investing in the new space rather than just exploiting the legacy. This assumes I have a choice in the matter and fortunately in 2017, I’m not yet in a position where I’m forced to exploit the legacy as the change is only just starting in earnest. I’m a little late but not that late. Whoot!
But, hang on, aren’t I deciding here? I haven’t gone through doctrine yet and I’m already talking about how to play the game and where to attack. The strategy cycle is a cycle which you will loop around many times in coming to your decision. Each time you loop around, new information and biases form that will change your purpose, your view of the landscape and ultimately your choice. This is all normal. It’s not a rigid linear path. It’s a guide. At this point, let us peek at those financial models.
The first thing to note is that numbers are not reality. Just because it’s written in a spreadsheet doesn’t mean it is going to happen any more than a Gantt chart tells you what the future really holds. In this case, the CFO has had the good sense to examine a range of outcomes for two variants (the build “in-house” and the use a “public” platform) and then complain about the lack of probability provided. I like this CFO.
Let us assume that after some badgering we have managed to tease out some probability figures for the outcomes from marketing and sales — outcome 1 (10%), outcome 2 (10%), outcome 3 (15%) and outcome 4 (65%). I happen to agree with the CFO that sales are marketing may well have bias here. Later in this chapter, I’ll explain mechanism for how you might more accurately determine those probabilities. Obviously our choice of building “in-house” or using a “public” platform doesn’t impact those probabilities. They are independent. In figure 204, I’ve added probability onto the financial models for each of the variants.
Let us go through the terms.
-
Probability: the likelihood of this outcome occurring according to sales and marketing.
-
Total investment: the total amount of capital we’re putting into this effort.
-
Total return: the amount of capital being returned (after repayment of investment). This is the annual net cash flow including any disposals.
-
Opportunity loss: the return I would have expected had I spent the capital on other projects. In the LFP scenario our standard return on investment (ROI) is 40%
-
Net Benefit / Loss: How did this investment do compare to my standard expected return? i.e. total return — opportunity loss.
-
Expected return: the net benefit / loss * the probability of this occurring.
By summing the expected returns for each outcome, we can determine the value of each variant. The best expected return comes from building “in-house”. But wait, didn’t we say this building in-house was the future legacy? Well, as I did point out, most financial models have a bias to the present and hence they discount the future. The problem is that by following this path we’re are building up the legacy practice (and related inertia) and not positioning ourselves to build a future market. We might maximise our short term position but we end up in a dreadful long term one.
Can we somehow financially account for inertia and future position? Yes. The essential question between the variants is the following — are we prepared to gamble $435k of expected return to explore and potentially secure a more lucrative but undefined future position? To analyse this is very complex. So, what do we do? Well, at this point we depart paths. I will build monstrous complexities for navigation and do things to spreadsheets that shouldn’t be done. You can SWOT it.
SWOT? But isn’t SWOT the curse of simplistic management? Yes, but it also has its uses particularly if we understand the landscape. The problem with SWOT isn’t that it is useless but instead we apply it to landscapes we don’t understand.
We have two variants — build in-house and public platform. The strength of build in-house is we’re familiar with this approach within our teams and it provides the greater expected return. Its weakness is we build up our legacy position which comes with the threat of increased inertia and future inability to change. On the other hand, using a public platform play has different characteristics. Its strength is we build up experience in the future space and though it has a less expected return it provides an opportunity to develop skills and explore new opportunity. The weakness is we’re unfamiliar with this and the threat is that it fails we lose face with the customer but also potentially political capital with the board. The path you decide really depends upon who you are. The “retiring” CEO will tend to plummet for in-house and the short term expected return whilst the “warrior” CEO is more likely to go for the public platform and a long term future.
At this point questions such as “But what if those probabilities are wrong?” and “What if the options I’m looking at aren’t right?” should be racing through your mind. So, let us tackle that bit.
As with most things in life, there exists huge amounts of uncertainty over which outcome will occur. This is only exceeded by a willingness of people to tell you that they would have chosen a different outcome if in fact you pick the wrong one. Fortunately, you can exploit this. First up is to use the Marquis De Condorcet’s work and get everyone familiar with the business to assign probabilities and take the average of the lot. A more refined version is to use an information market.
Information markets are fairly simple concepts that are fiendishly difficult in practice because of unintended consequences. A basic example of one is as follows. Let us assume we want to know from the company whether a project called “X” will fail to deliver or succeed? We create a bond (called project X) which will pay a certain principal (e.g. $200) if the project is successful at a specified date but will return $0 if it is not. We give everyone in the company one bond and $200 as a bonus. We then let them trade the bond in our own internal market.
Along with the nice “thank you” for a $200 gift (which has its own secondary benefits), the bond itself maybe worth upto $200 or might be nothing at all. So, people will tend to trade it with others. If I expect the bond is 90% likely to fail then I’ll be over the moon to sell it to someone else for $40 (the strike price) and a bit gutted if it subsequently succeeds as they cash in an additional $160 bounty ($200 the bond’s principal — the $40 strike price). The price on the internal market will reflect the likelihood or not of the bond i.e. the question asked. The use of such information markets is well over a decade old but there can be lots of political complications in practice particularly if you get an individual starting to make a small fortune on this. There’s nothing wrong with that, they’re somehow providing you accurate information on the future but it can cause “difficulties”.
I mention information markets more to point out that there are lots of ways of skinning Schrodinger’s cat and finding probability. I’m certain there must be a good few books out there on this topic, so I’ll leave that to the reader to go explore. The question on probability is always how much is that information worth to you? The cheapest way is to guess yourself, the slightly more expensive way is to aggregate other peoples guesses and the far more expensive (but also far more accurate) tends to be the use of an information market. But let us assume our probabilities are “right” despite my reservations and those of the CFO. This doesn’t mean one outcome will happen, it’s just a probability. We must still roll the dice.
Hence, what we know so far is that we have this opportunity to build an LFP system, there are two variants (in-house, public platform) and whilst the in-house variant gives a greater expected short term return, the platform play prepares us for the future and the co-evolution of practice that will happen. Let us get back to our strategy loop and start looking at doctrine especially the issue of “managing inertia”.
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.
All forms of inertia relate to some loss of capital whether physical, social, financial or political. We know that two groups (security and systems) are exhibiting inertia, however such visible signs are usually not the problem as we’re aware of it and hence it can be managed. The danger is always the group that haven’t quite made themselves clear.
In the case of security, the inertia is probably related to two types. First, we have uncertainty over the use of a platform play and any co-evolved practices that might emerge. This will require “Investment in knowledge capital”. We can overcome this with either training or providing time and resources to develop the necessary skills. We can certainly provide an argument that if we fail to do this then the future cost of acquiring these skills will be higher and we will also miss out on shorter-term motivation for staff. The second type of inertia is “Changes to governance, management and practices”. Co-evolution is always difficult for people to get to grips with as it means that their existing and perfectly valid best practice for a product world become no longer relevant. We can only overcome this by explaining co-evolution usually by pointing to past examples. Both types of inertia are relatively simple to manage.
Slightly trickier is the systems groups. Along with the two types of inertia mentioned above, we’re likely to have two additional types especially since the group builds and controls the underlying infrastructure behind any home-grown platform efforts. These additional types are “loss of political capital” and “change of business relationship (loss of social capital)”
The “loss of political capital” includes fear over becoming irrelevant in the future, loss of status and loss of past empire. Don’t underestimate or dismiss this as it’s very uncomfortable for those who face it. You counter by giving people are path to the future and relevance in it. Start by acknowledging what has been achieved and move onto modernisation. You need to emphasise the importance of future agility, efficiency, importance to the business and how we must build for the future. You also must include them in this future. At this stage, with utility platforms just in the early stages of industrialisation then such action is relatively trivial. The co-evolved practices haven’t been developed and so there’s plenty of time for training, re-skilling and the re-application of essential system concepts from configuration management to versioning in a more utility platform world. In all likelihood the biggest danger is that by helping your systems team develop into this world at this stage, they’ll become super valuable in the not so distant future. It is however, far better to have a small army of super valuable people that everyone else is trying to poach than to be left with a bunch of legacy skills and trying to desperately poach from others.
The co-evolved practice will be different from the past but someone has to develop that capability, no-one yet has those skills and why shouldn’t it be your systems team? Unfortunately, what normally often happens is companies don’t anticipate obvious changes and leave it late. This creates an added complication which I’ll discuss in a moment.
The “change of business relationship (loss of social capital)” is the second additional type of inertia you must contend with. Within a company, there’s often a pre-existing relationship with vendors who might be supplying products or services. This relationship creates inertia to change i.e. we have our familiar and favourite vendor. In normal circumstances, you can deal with this inertia through normal vendor management approaches. You can emphasise that the time is right for a change, that the past has evolved and we need to re-evaluate the vendor’s offering. However, there’s the complication mentioned above.
If you’ve left it late then the vendor of a product may well be spreading huge amounts of fear, uncertainty and doubt over the more utility form to your own team. They will probably have tried to convince your own team (e.g. in this case, our systems team) that they have no future in this “future world”. If they’re canny, they would have encouraged articles in related trade press spreading the same message. This is all designed to get your own people buying the vendor’s product rather than adopting to the new world. If you haven’t had that conversation about the future and painted that path, this can make it much harder for you to overcome any “loss of political capital”.
You can try and say, “don’t worry but will invest in retraining” but this is also where any past Machiavellian efforts or brutal corporate action will bite you in the bottom. If there exist doubt in your trustworthiness then they won’t follow but will resist. Whatever you do, as annoying as it is to be confronted by this — remember one thing. They are behaving perfectly rationally. You are the wally who left it late to deal with a highly anticipatable change and therefore caused the mess. If you want someone to blame, buy a mirror.
Unfortunately, we all make mistakes. This is also why you must always consider not only our action today but the future consequences of such action. Having that trust can bail you out of your own face palm. However, we’re not in that position with the LFP scenario yet. We shall assume we have a team who can have an open and honest conversation. We can anticipate where the future is heading with the map and we’re going to share this. We’re going to have that discussion and invest time and money in bringing our systems and security teams into this new world with new skills and new capabilities. We leave no-one behind and we certainly don’t turn up five years late to the battle in a blind panic.
Alas, we might still have a problem. There’s potentially another source of inertia and it’s a powerful one. The board. We know they have a concern but aren’t going to raise an objection … yet. Now that can either be just a general question on the change or could be hiding something else. We need to explore that. It could be as simple as “Data for past success counteracts” i.e. they’re used to us operating in one way and we’ve not been down this path. It could be concerns over “Loss of existing financial or physical capital” because we’ve invested in data centres. It could be a question of political capital or that one board member has looked at the model and wants to focus on short term expected return rather than building a future.
Whatever the cause, you need to find it and to fix it. That’s one of your many jobs as the CEO. There are also many other forms of inertia and so for completeness, though not necessarily relevant in the LFP scenario, we will quickly run through the other types of inertia: -
-
“Threat to barriers to entry”, the fear that a change will enable new competitors. Whilst that fear may be justified it is often an unavoidable change that is already happening in the market and outside of your control. You cannot ignore it.
-
“Cost of acquiring new skill-sets” is one of the more bizarre sources of inertia because not only do you not have a choice but the cost of acquiring skills will often increase over time. This is a common consequence of a punctuated equilibrium where huge numbers of companies that are very late to the party, simultaneously declare this change as the future and promptly cause a shortage of skills. There are many ways to counter this and mitigate the cost — assuming this is done in a timely fashion — from developing in-house, use of conferences to creating centres of gravity to attract talent.
-
“Suitability”, one reasonably common form of inertia comes in the form of questions over whether it’s ready e.g. ready for production, is the market ready for this, are customers ready? The best way to counter is through weak signals and examination of the components (e.g. using the cheat sheet).
-
“Lack of second sourcing options” is often a valid concern but can be used to disguise other forms of inertia. Back in 2008, it was not uncommon to hear a company say without irony something of the form — “We’re an Oracle shop. We’ve thought about using public cloud but were worried about the potential for getting locked in with Amazon. We want to see more choice”. If you can overcome the irrational side of the debate and any tendency to point out the ridiculous flaw in the argument, then this is all about supply chain management, trade-offs and use of standards where appropriate. There are a wide range of techniques to mitigate it.
-
“Lack of pricing competition” is another reasonable concern which really points to how well functioning the market is. Do we have single or multiple vendors? What are the switching costs?
-
“Loss of strategic control” is usually wrapped up with fears of letting go and in the cloud space led to the idea of “server huggers”. However, there are some valid aspects to the concern around buyer vs supplier power relationship. Most of this can be overcome with strategic planning and examination of different scenarios i.e. what should we do if the supplier rapidly increases price etc.
-
“Declining unit value” is usually a business concern related to a desire to maintain the past. The only way to counter is through awareness of evolution and how markets aren’t static. You need to look at alternatives opportunities, think Charles Handy’s 2nd curve and try to avoid the spiral of death.
-
“Data for past success counteracts”, an extremely common form of inertia particularly if the company has been successful. Most companies build up a significant stock of data that informs them how successful the past was. This will often be used to argue that the future will be more of the same. You need to take a leaf out of portfolio management and realise that your portfolio will change over time. Options analysis and risk management approaches can be useful here to avoid having all your eggs in one “past” basket.
-
“Resistance from rewards and culture”, hugely problematic for most companies and easily exploitable by competitors. Performance bonuses linked to selling an existing product set can be a significant source of inertia and weakness. You can manage this through HR by using higher rewards for adaptation, education, longer term thinking and promoting greater situational awareness.
-
“External financial markets reinforce existing models”, another common but tricky form of inertia to deal with. As discussed in the previous chapter, it’s important to understand your context and the role being played by others such as fund managers. There are certain techniques that can be deployed here to overcome market inertia including spinning a future story.
We have a map of the landscape, we’ve applied basic economic patterns to anticipate change, we can see opportunity in co-evolved practice and obstacles in inertia to the change, we have financial models and understand how we can trade off higher short term expected returns for building a future position. Though we have inertia, we also have an idea of the types and how to deal with it. Our awareness of the situation is expanding. This is good. This is how it should be.
In the above, I specifically state “anticipate change” because we cannot predict evolution over time (see chapter 7, section “the trouble with maps”). We must use characteristics or weak signals or information markets to give us a probability of when the change will happen or even if it’s occurring today. Mapping is all about probability rather than time; the uncharted space is uncertain and the industrialised space is more known. To predict over time would mean we could say “in 453 days this [activity or practice or business model] will change from A to B”. As far as I’m concerned that is straying into the realm of charlatans, crystal ball fanatics and soothsayers.
I often hear people counter with vague notions of time e.g. “at some point in the future”. That is not predicting over time as time requires a “when”. I cannot, nor have I ever been able to predict evolution over time. Of course, I’m fully aware that I have my own inertia caused by my own past success with mapping and that the subject itself will evolve (see chapter 7, section "a map of mapping"). Someone else may well find a way to map over time. I will no doubt dismiss it and be proved wrong. I do hope I have the wit to use my own tool on myself at that time. “When” will this happen? As I said, I can’t predict over time and the weak signals aren’t even strong enough for me to guess.
In terms of the strategy cycle, we’ve observed the environment and moved onto orientating around it with doctrine such as “manage inertia”. However, let us explore the cycle a bit further.
In this section, I’m going to look at how we organise around the LFP scenario and put down a few markers for strategic play that we might consider. Once I have a general outline, I’ll often loop around this several times with others to refine, to create alternative scenarios, to alter course before finally deciding upon a choice of action. When it comes to organisation then I use not only use a self-contained cell based structure (i.e. small teams) with the right aptitudes (finance, engineering, marketing) but also for the last decade I’ve been using attitude (pioneers, settlers and town planners).
I note recently that Kent Beck has been discussing a model called 3X — eXplore, eXpand and eXploit. This is excellent as there’s nothing like independent discovery to give a bit more substance to a topic. Pioneers eXplore, Settlers eXpand our understanding and Town Planners eXploit by industrialising with each group operating and maintaining its own space. This all deserves a good hat tip to Robert Cringely and his marvellous book “Accidental Empires”. Anyway, back to our map. Since we’ve previously built our own systems then I’ll assume we know how to do this and it would be superfluous to cover the build in-house variant. Instead I will focus on the platform change and how to organise around this. In figure 206, I’ve outlined the two obvious cells that we need to consider when using the public platform.
One cell refers to town planning around the platform. Obviously, someone else is providing the platform as a utility service to us but we still need to make sure we create highly industrialised process around monitoring the platform, access control and how much we’re getting billed. This is not something new and chances are that provider will be offering tools to make it easy. However, there are a new set of practices that will develop around the financial cost of a function, re-use of functions, the type of events and how we monitor the code itself. This is not so much related to the platform itself but how we use it. In much the same way, the practices that changed industry were not so much about whether we paid the right electricity bill but how we used it to do other things. What those new practices will be is uncertain. I can guess based upon experience of running a code execution platform (i.e. serverless environment) with Zimki in 2005. But it’s no more than a guess.
We can also at this point start adding some primitive gameplay. For example, we could — if we have decided to play a legacy game and not build for the future market — spread fear, uncertainty and doubt over the utility platform. Alternatively, we might play an open play around the co-evolved practices to help them evolve more quickly. We might do this to create a name for ourselves in this space, to build a “centre of gravity” around the skill-sets needed in anticipation that this will become a lucrative market for us. I’ve outlined these two very simple plays in figure 207.
So, complying with my natural bias, I’m going to focus on creating a future position and market rather than exploiting a legacy position and waiting for the future to catch up and do horrible things to me. I can do this because I haven’t yet left it too late to make that choice. I’m going to try and own those future co-evolved practice, build a centre of gravity and use open source to achieve this. I’ll accept the lower expected return in exchange for a stronger future position and not building up my legacy. I’ll add my structure and gameplay around the platform space onto my LFP map. See figure 208.
The first thing to note is the map is a bit messy and things seem to be in the wrong position i.e. somehow my emerging architectural practice is above my microsite in terms of user needs despite the client not mentioning anything about this changing world. This is fine. All maps are imperfect representations and with a bit of fiddling around and moving pieces then I can create something which appears to represent the situation more clearly. See Figure 209.
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.
We now understand the landscape, the trade-off between short term expected return and future position, the structure needed, the main sources of inertia and some basics on the gameplay. Our situational awareness is constantly improving. The next thing we do is loop around the strategy cycle again and refine it. But isn’t that time consuming? Yes.
With experience, for a business that has a map then a single loop (what we’re covering in this chapter) could take anywhere up to 30 mins. Add a couple of loops, discussions between people and you could have easily blown an hour or two before you commit to the choice. Add to that the additional hour or so it might take to create that first map and the financial models and yes, you could be looking at half a day. That is of course an incredibly long time to go from concept to decision to act.
To be honest, I can’t think of many examples where it has taken anywhere near that long. There are a few M&A activities (covering hundreds of millions) where I have taken a day or so but that is the exception and only occurs in fields that I’m not familiar with. Being locked in a room or given people to interview and asked the question “should we buy this company” often involves extracting information from others. Most of the time was spent developing an understanding of the landscape because very little existed. However, we should acknowledge that mapping does take some time and I don’t know how to make it faster. It’s one of the obvious weaknesses of mapping versus gut feel which can just be instant.
Another problem is complexity. First, mapping exposes the complexity of what exists. In the example of Themistocles SWOT (chapter 1, the importance of maps in military history), it’s usually obvious to everyone that you should use a map not a SWOT to run a battle. We understand this because we’re familiar and comfortable with geographical maps. However, there is a downside which is a map is inherently more complex than a 2x2 such as a SWOT and this makes management more challenging and requires more thought. But what if you’re not familiar with maps.
Let us consider how Vikings used stories for navigation. Put yourself in the role of a Viking navigator having spent 20 years learning epic tales and being trusted with steering the boat. Imagine someone says to you that you don’t need a story but you could use a map. The first time someone shows you a map or you will see is diagram with dots on it. You will have difficulty in understanding how can such a thing can replace your twenty years of learning epic tales. You’ll tend to react negatively because of experience i.e. you know the stories work. You’ll have a natural human bias to that which is comfortable and previously experienced. The map will be unfamiliar even alien and its complexity will overwhelm you. It will take many points of exposure and realisation that a map would have been better than a story before most will put in the effort and thought necessary to use it.
Go back to the Themistocles SWOT. Imagine if battles had been run with SWOTs and someone came up and said, I’ve got a map thing which might help. The reaction would be overwhelmingly negative to begin with because it’s unfamiliar (not a SWOT) and complex. It can also threaten those who have spent 20 years learning how to “Battle with SWOTs” or “Navigate with stories” because at its heart, it is basically saying that they’ve been meme copying all this time without understanding the landscape. Into this mix you can throw in the issue that exposing the complexity also exposes assumptions made and opens decisions to more challenge — another thing people don’t tend to like. You’ve got quite a mountain to climb with mapping. Which is probably why those with a military experience (and some familiarity with situational awareness) have an easier path to mapping. The worst cases are normally those who have no military background, 20 years or so of “strategy” experience and an MBA.
However, let us assume you persevere, you create a map, you loop around the strategy cycle and over time (and hour or two, possibly more) through the application of thought then a context specific path becomes clear. What now? I tend to double check it as a final step. I find that using a business model canvas is brilliant for this as by that stage you should have everything you need to fill it in. Let us assume you decide to build the LFP system using the public platform. What now? Well, let us roll the dice and see what happens.
You’ve decided to build the LFP system using it as a springboard to develop a future position around the co-evolved practice that will emerge in the platform space. You’ve overcome your internal inertia through discussion, formed the teams and explained this to the board. You’ll sacrifice some short term expected return for a future position with an eye to repackaging the solution and selling it to others along whilst developing a new practice in the co-evolved space. You roll the dice and it comes up … outcome 2. Oh, damn.
The LFP system isn’t going quite as well as we might hope. Fortunately for us, we didn’t build in the in-house variant otherwise we’d be losing money right now and our discussions with the board might be getting more tasty. The problem with our options analysis is we didn’t price in any variability and risk appetite. The in-house variant was riskier because it not only had the highest expected return but the lowest — there was a wide spread. In this case outcome 2 is a net loss. We can chalk that up as a future learning lesson (or in my case — past painful lesson). However, let us compare what happens with outcome 2 in both variants. Let us say that despite things not going so well both marketing and engineering have dived in and come up with proposals. There are two options on the table. So, which, if any, do we choose?
-
Engineering says they could improve code efficiency by 75% for $350K
-
Marketing say they could add 400k extra microsite visitors for $150K each month
Let us go through each variant. In figure 211, I’ve added the financial impact for the proposals on the in-house variant.
Since outcome 2 is happening, we will use this as the base case and add the impacts from the proposals. The first thing to notice is that the development proposal doesn’t make the case better but instead it makes the finances worse. Why? Because the cost is already sunk and spending money on refactoring doesn’t improve the financial case as there is nothing to be recovered through code efficiency. The only possible saving grace would be through releasing some hardware to get a quicker sale of it and less depreciated value. That’s in the realm of wishful thinking in most cases. Sadly, it’s often difficult to justify spending more money on a refactoring effort in such circumstances. The marketing proposal however gives us some uplift. At least it recovers some of the pain. Our final expected return is still below our normal of 40% but we’re saving a bit of face. The combination of both development and marketing gives us the benefits of marketing combined with the loss of development. It’s far better to just do the marketing proposal.
Ok, so let us repeat this exercise but now look at the public platform variant which is the one we actually chose. I’ve created the model in figure 212.
The first thing to note is we’re in much better shape with outcome 2 because we didn’t have that initial sunk cost of investment. But then something odd happens. If you look at the development option, by spending money on refactoring then we make a much better return. In fact, it’s a huge return! Hang on, how’s that possible? Well simply put, we’re paying for consumption of the utility platform (such as AWS Lambda) based upon our actual use. If you make the code more efficient then you pay less. There is suddenly a financial reason for refactoring code. There are many other benefits with such platforms from consuming services to code re-use but the changes to the way we write, refactor and monitor code are significant. This is what co-evolution is all about and in this case, it’s the collision between development and finance.
The second thing to note is that marketing is a net loss. How is that possible when in the in-house variant it’s positive? On a consumption basis, the cost to acquire and cost of operation for each new user significantly exceeds the additional revenue they create and so it’s a loss at this acquisition price. The marketing proposal doesn’t make sense in the public platform variant because there’s direct linkage of actual cost against revenue. But in the in-house variant, then most of the costs of operation have already been spent in the initial upfront investment. It’s a sunk cost. In which case given we’ve already spent most of the money and we’re actually comparing the acquisition cost versus the additional revenue. The marketing proposal makes sense in the in-house variant precisely because you’ve already blown most of the cost.
But hang on, the third option of both marketing and development looks better than all of them. How can that be? In this case, the reduced cost of each user on the service (because of refactoring i.e. the development effort) means that the total cost per new user (i.e. marketing acquisition plus operational) is now less than the additional revenue they create. The sum of the whole is greater than the sum of the individual parts. Hence the last option gives us the best choice and that’s where we invest. The shift towards utility platforms and billing at the functional level fundamentally changes your entire investment approach in projects. From no more nonsense about additional IT users having a marginal cost of zero (i.e. we’ve sunk a lot of cost and can’t actually allocate them) to refactoring suddenly becoming a financial consideration. The true costs (not just of acquiring but operating) of marketing are hence exposed.
We’re already starting to experience some of those co-evolved practices and this looks like a big change. This is why I created that first platform back in 2005 but as you’ll come to learn, these opportunities jump at you when you embrace the future. But, why didn’t I continue and rebuild the platform after the parent company decided it wanted to go elsewhere? Well, I spent a bit of time working on printed electronics and then met an astronaut but that’s the next chapter.
The one thing I want you to remember from this discussion is that spreadsheets are wonderful but they’re not a substitution for situational awareness. Loop through the cycle, understand your landscape, anticipate change, manage inertia, structure around it and then apply tools, choices and biases to help you decide where to act. Maps however aren’t a substitution for thought, they’re an enabler of it. By now you should be thinking of how you can use maps to communicate across finance, engineering, operations, purchasing and strategy from anticipation of change to organisational structure. As you’ll discover soon enough, this is only the beginning,
Oh and in terms of the original questions, then my answer would be :-
-
Do you sign the contract or not?
-
Sign it
-
If you do sign which variant do you go for (in-house or public)?
-
Public platform, variant 2
-
Are there any other changes that you would make?
-
I would use this as an opportunity to explore a future business
So, did I tell you the story about how I met a real life spaceman? That’s next.