Wednesday, October 31, 2018

What is an expert

(draft)

I often see examples where people add characteristics to a map or use new definitions for one of the axis. There's nothing wrong with this and I want to encourage people to explore. One recent effort by Manish has the axis as Rookie to Expert which leads to the question - what is an expert?

A map (and I have an entire creative commons book on this, if you want to know more) is a map of capital. The nodes are stocks of capital and the lines are flows of capital. On the x-axis, I normally use the labels for activities - genesis, custom, product (+rental), commodity (+utility).  But you can map not only activities but practices, data and knowledge. We use different terms for each stage of evolution of these forms of capital which for reference I've included in the table below.

All of these forms of capital have common characteristics as they evolve.  These characteristics are captured in the cheat sheet, which even after nearly a decade, I still find to be a useful tool though to be honest, it's embedded deep in my mind these days.



So what has this got to do with expertise? Well, let us take a grossly simple map of healthcare starting with the public and assuming some form of Government sponsored healthcare system. One of the components is treatment but treatment isn't a static thing. There is constant range of new treatments produced whilst the once remarkable becomes routine, even dull. 


So, what do we mean by expertise? Well an expert could be someone who is experienced in a broad range of treatments. They would be a generalist or an expert in general practice.


 But an expert could equally be someone who has specialised in a particular area e.g. the novel study of epigenetic cures or even appendicitis. This person would be a specialist



What is important to understand is that every node on a map can in fact be itself a map.  For example, if we expand out Appendicitis into its own map (see below), there will be many components involved in its treatment. A specialist would have in depth knowledge of each of those components.


Now, you might ask me why the nodes on the last map have no labels. Well, it's because I don't know what they are. I've just added some node and links as a way of saying - there will be components involved but I have no idea what they are. If you actually want a map for it then you'll need to talk to an expert on the subject.

The only people who can actually map a space are those with expertise in that space. In the same way, the only people who can draw you a map of London (even a crude one) are people who have either been to London (physically or virtually) or seen a map.

The beauty of maps is we can have many experts (both generalists and specialists), sharing and communicating with each other through the use of maps and hence improving them. This leads to  best thing about maps. For a rookie like me, then a map is the fastest way I know of bringing me upto speed of a complex and complicated environment. It's also the fastest way of discovering just how little I know.

Tuesday, October 30, 2018

Rebooting GDS

(draft)

There has been a lot of chatter recently about rebooting GDS (Government Digital Service). Don't get me wrong, GDS has made mistakes but some were actually my fault. I made a terrible assumption in writing the "Better for Less" paper to do with mapping and how much people were aware of it. In hindsight, I should have pushed mapping into that paper rather than leave it as background noise.

So, in order to avoid making this mistake again, I want to extend this question of rebooting GDS and tackle the scenario of you're newly minted CxO (CIO, CEO et al) or Dept Head or - it doesn't really matter. 

The first thing you're probably going to feel is a bit of panic. Who put me in charge? I know there is the temptation to stamp your mark on organisation, to create that strategy which will propel the company to fortune but I'm going to ask you to hold your horses. The Titanic might be sinking and we've got to plug the massive great big hole before messing around with the deckchairs or plotting a new course.

To begin this journey, I'm going to introduce you to the strategy cycle (figure 1). It's fairly simple :-

1)  Have a purpose, a moral imperative.
2) Observe the landscape you're operating in and the climatic patterns that impact it (in terms of business we call these economic patterns). These patterns are useful for anticipation of change.
3)  Orient your organisation around the landscape using basic principles (known as doctrine).
4)  Decide where you're going to play, game the landscape to your favour and act. This is collectively known as leadership.
5) It's a cycle - every time you or anyone else acts it can change your purpose, the landscape, where you need to act etc.




I'm going to assume you don't have a map of your business landscape. You might have things like business process maps, systems maps, mind maps and a host of other things called maps but none of these actually are maps. The odds are, you're blind to the environment. But that's ok, so is almost everyone else.

When it comes to using the strategy cycle then is these early stages we're going to skip climatic patterns, anticipation, gameplay, leadership and all that good stuff. Instead, we're going to focus on doctrine and how to stop the organisation from actively harming itself. We're going to plug the Titanic!  We're just going to loop around adding doctrine.


Now, there are forty patterns that make up doctrine. These are all universally useful to any organisation but not all doctrine is made the same i.e. some is more important than others. Hence, I've provided a phased implementation of doctrine and we're going to start with principles in phase I (marked in blue). These principles are challenge assumption, know your users and know your user needs.


But how to introduce challenge in the organisation? Doesn't challenge already exist? Why challenge?

Ok, for most organisations you have endless lists of committees - global architecture group, business strategy forum, policy committees etc. They are generally full of well meaning people but there's usually not a lot of actual challenging going on and communication is nearly always suboptimal. If the organisation is of any size it'll have lots of waste, failed efforts, bias and duplication but no-one can really tell you how bad the problem is. When most CxOs stumble on this, they often want to take stock.

Taking stock of a large estate (whether IT or otherwise) is usually a pretty daunting task and the problem we're trying to solve is not "what we have" but "don't do silly things". Hence we really don't need to know how much waste we have, we just want less of it. To solve this we're going to introduce a group which will become a future bedrock of strategy in the organisation. That group is Spend Control.

The beach-head of Challenge

The purpose of spend control is simply to challenge what we're doing. It's important to remember that it doesn't control the budgets. Those budgets belong to other departments. Spend control simply says that if we're going to spend more than £25K on something then that has to be presented us and exposed to a bit of challenge.  To begin with, spend control should simply ask - who are the users, what are their needs and by what metric will we measure those needs?

You can even reinforce this by going around leaving posters of "What is the User Need?" or sticking it on the back of your phone as per Liam Maxwell (former UK Gov CTO)



Who are the users, what are their needs and by what metric will we measure those needs - surely everyone does this? You'd be surprised. Last time I counted, less than 20% of organisation could clearly identify their users and far less could describe their users needs. You might be lucky and be in one of those exceptional organisations but chance are, you're not. 

So, how does spend control work? Well, a project owner turns up at spend control with a project that they've got budget to spend £100K on. Spend control asks who are the users, what are their needs and how we will measure this?  The response can often be "I don't have a clue, it's only a £100K". 

Well, spend control's job is to ask the project owner to find out. But remember, the project owner is also the budget holder and so they can simply ignore spend control on the grounds that "It's a waste of my time".  You'd be amazed at how many people try to get exceptions to spend control because they're too important to be challenged on basic questions.

Let us assume the project owner does the work anyway. They might be successful but the problem for the project owner is should something go wrong then there is paper trail that they refused to ask the most basic of questions. This is the other side of challenge - you need to ask the questions and audit what happened. Now, what is happening here is spend control is not only building up a picture of things we might be doing (the projects coming into spend control), the users we serve, their needs and how we measure success but it's also building up a picture of which project owners listen, accept the challenge, succeed in projects and also understand their users. This is all good stuff.

At some point, maybe six months or a year into the process, then spend control needs to have a showdown with one of those failing project owners. You need to emphasise that people can't keep on just doing stuff without understanding the users, their needs and some basic metrics to measure against. This showdown is rarely comfortable but you need to push for no exceptions to the idea of being challenged. Once you're there,  the beach-head of challenge has been established then we can start to ramp things up.


Introducing Awareness.

At this stage, we going to extend spend control to ask more questions. We're going to go beyond just simply users and their needs but start to look at what is needed to build a project. I've highlighted the extended set of phase I doctrine that we're going after in blue.


The first thing spend control is going to ask people for is a map. This is a fairly simple exercise, you simply start with the users, their needs and then work out the components involved in making that happen. You do this through a chain of needs i.e. this needs that which needs that etc. The tricky bit with a map is you ask people to also put down how evolved the components are. There's an entire book on this, so I won't repeat that here. I've provided a very simple map for a tea shop.


The point of the map is we can challenge more i.e. there's a lot of components missing from this map for a tea shop from chairs to sit on to a method of taking payment. By sharing a map with others we can often find basic things that have been missed. We can also challenge in terms of what we're doing i.e. why are we custom building kettles?

These maps are in fact maps of capital (with flows and stocks). So we can add metrics to the map. Each line is a bidirectional exchange of capital i.e. the user gets a physical flow (the cup of tea) in return for a financial flow (money to pay for the cup of tea). The capital itself can be physical, financial, social, risk, information ... all sorts of things and yes we can build P&Ls from this.


The point is, we're now asking who are the users, what are their needs, how will we measure this, what components are involved, where is the money going and challenging across the lot. As we get more maps, we can even discover duplication between maps i.e. we're building the same thing twice. The worst I've found in Government is 118 times. The worst I've found in the private sector is a Finance company that has managed to rebuild the same thing over 1,000 times. Do remember, it's not because people are daft but because of suboptimal communication. People just don't realise they are doing this.

Let us repeat those steps just to be clear.

Step 1 - Focus on the user needs which means you also need to identify the users.


Step 2 - Know the details i.e. what is involved in building the thing. This allows others to challenge, find missing components and create a common image which can be communicated with others.


Step 3 - Reduce duplication.  When we have several maps then we usually start finding duplication rather rapidly. In general, I hold a view based upon experience that over 90% of the P&L of most organisations is waste. It's a far bigger problem than people realise and I'm genuinely surprised by organisations that have any sort of handle on this problem.


Step 4 - Reduce bias. I can't tell you the number of times I've come across organisations custom building what is a commodity because it's so common that it is normal. I've had people looking to invest in robotics (with lovely business cases provided to show an ROI for the capital investment within 12 months) to improve the efficiency of some workflow for a problem that only occurs because they're custom building something which is a commodity. In this case, the item was custom built racks, the problem was standard servers didn't fit into their custom built racks requiring people to remove cases, drill holes and add new plates. The "proposed solution" was to replace people with robots. The actual solution was to stop making custom built racks and start using standard racks. This sort of stuff is very common.

Hence, use the maps to challenge and question - why are we custom building this thing?


At this point, you want to give the changes another six months or a year to bake into the process. Spend control should be challenging across a much broader spectrum of things from the user needs, to the components involved, to duplication, to bias and where we're spending money.  The process of making a map is fairly quick - a few hours or so - but expect more resistance. Everyone likes to talk about the importance of challenge but no-one actually likes to be challenged. Expect lots of demands for exceptions and why this is too complex to go through the process and a host of other excuses. 

Don't get disheartened. In some cases, spend control will be able to really help others by showing them that what they're building is also being built by others. This will enable people to focus their efforts on stuff that matters, to get rid of the common (the boring) or even identify opportunities across multiple maps for building common services. But there will always be those who think they're too important. Just remember to record the advice given, those who ignored and what the end result of the project was. Build that evidence base. I'm afraid you'll probably need a few more confrontations with failed projects before it becomes accepted that challenge is not a bad idea.

What is also happening behind the scenes is you're also now building a view of the landscape you're competing in. All those maps are connected, part of a wider landscape and you're starting to get a view of this and your estate.

Finishing Phase I

At this stage, whilst things should be getting better, you're still going to have oodles of failed projects. You need to have built that evidence base and trust before you really embark on this part of the journey which is all about completing phase I (highlighted in blue).


To begin with, we going to have to start breaking down projects. Just because we have a map, doesn't stop people trying to build the entire map in some Death Star like project outsourced to their friendly SI. You'll need to introduce ideas like FIRE (Fast, Inexpensive, Restrained and Elegant - see Lt Col Dan Ward) and constraints. What we need to do is break things up.

Step 5 - break into small contracts.


The usual resistance to this is because it makes the landscape more complex as I've got multiple contracts now and interfaces between them. Please note the interfaces already existed and no amount of pretending they don't by trying to hide it in a big contract is going to make them go away. But breaking into small contracts is vitally important because it means we can now apply appropriate methods.

Step 6 - apply appropriate methods.


You might not be aware of this but there is no magic one size fits all method for project management anymore than there is for purchasing. You need to apply multiple methods at the same time. Hence you'll tend to outsource those more industrialised components on the right whilst building in-house with agile techniques those uncharted and uncertain components on the left. You'll also use different purchasing mechanisms. 

The overwhelming majority of large scale failures that I see come from misapplication of techniques and almost all of them can be anticipated before the project has even started. Typically, we'd take a project like the one above and outsource it all in one big contract. To mimic this, I've just marked all the "mini contracts" as outsource. Now the components on the left hand side are uncharted i.e. novel, new and changing. We can't actually specify them because they constantly change. Hence sticking them in a contract with components that can be specified always ends up with excessive change control cost overruns.  People argue that next time we need to specify it better but you can't. The solution is to use appropriate methods.

Step 7 - Learn about context i.e. what works where.


Helping and advising project owners on how to manage their environment is where spend control can truly shine. At this stage spend control will already be on the path to becoming the intelligence function that every organisation needs. But let us not get carried away with the future. At this stage you've completed all the doctrine in phase I and should be embedding that into the organisation through spend control. You're challenging across multiple aspects from the user, user needs, components, how we treat them, where we spend money etc. All the time you're learning about the environment and what methods work where, removing duplication and bias and hopefully becoming fitter and leaner.

You should be a couple of years into your journey. We've still several more phases of doctrine to go and we're years away from creating adaptive cell based organisational structure that use multiple cultures to cope with evolution (see below) but we're better than we were. We're also a good 5-10 years away from being able to effectively anticipate change, to use maps to target the landscape and to start learning how to manipulate the market and write strategy. 


At the beginning, I did say hold your horses on organisational change and strategy because the honest truth is most people haven't got a clue how to do this - it's pretty much all random, blind luck, memes picked out of the air. The reason why you felt panic is because you didn't know what to do. The good news is, most executives don't either.

Rather than blindly stumbling around, it's far better that we've made our first steps and mapping is itself a journey. You will eventually get to the point that you can play those more advanced games but let us get these basics sorted first. As a a rule of thumb in the private sector, by the time you complete the first phase of doctrine then you should probably set a stretch target of demonstrably reducing waste in the P&L to about 50% or below i.e. less than 50% of the P&L expense is waste. Obviously, some players are already far better than others. In Gov, there tends to be less waste because there are pre-existing mechanisms of challenge such as the MPA, NAO and PAC but even in such spaces, it's more than possible to save billions.

When it comes to the original question of rebooting GDS, I can't emphasise enough the importance of focusing and doubling down on spend control.

Wednesday, March 07, 2018

On Playing Chess

Chapter 19
(rough draft)

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

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

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

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

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

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

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

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

Figure 246 - Combination Plays


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

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

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

Whichever method you use, aim to make this a stepping stone to a further play. For example, in the case of Zimki then:- 
  • creating a utility service in the platform space and exposing it through APIs was a stepping stone towards running an ILC (ecosystem) like game. 
  • open sourcing Zimki was simply a stepping stone to achieving an exchange with many providers. 
  • the play to open source Borg (our underlying infrastructure system) was a counter play against any one competitor becoming dominant in the IaaS space.
This idea of future possibilities through stepping stones is an important concept within strategy. If we look at the first method again (i.e. banking on recombination efforts in the uncharted space) then this is often a bad position to find yourself in. More often than not it leads to a dead end - the phone firearm or the phone tooth. I tend to refer to these high risk approaches as "gambling" rather than "opportunities" because opportunities should expand your future possibilities and not reduce them.  If you're going to gamble then the only way to consistently make this work is to be lucky.

Try instead not to gamble as much as focus on expanding future possibilities. Just because you could do something, doesn't mean you should do it. Strategy is as much about saying what you won't do as it is about what you will do. This is summed up in the highly mischievous phrase "opportunities expand as they are seized" which is often misinterpreted as "grab everything" which is precisely not what you should be doing. This is also why Fotango pivoted from a declining online photo service to a platform play, as it expanded our possibilities. See also Stewart Butterfield who seems to have become a master of such pivots. This doesn't however guarantee success as these are opportunities and not certainties.

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

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

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

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

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

First thing I want you to do is to take 30 minutes and come up with ideas of how you will solve all of this?

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

Figure 247 - Regulator's Map
















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

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

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

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

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

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

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

Figure 248 - My answer
















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

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

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

Roughly speaking (and based upon an idea proposed by Krzysztof Daniel) then  :-















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

I said roughly for two reasons. Firstly, potential value itself implies uncertainty and hence the "equation" above breaks down to uncertainty is inversely proportional to certainty i.e. the less certain of something we are then the more uncertain we become. It's the self referencing flaw of Darwin's evolutionary theory and survival of the fittest. We define the "fittest" by those who survive. Hence evolutionary theory breaks down to survival of the survivors. This obvious circular reference doesn't mean it isn't useful. The second issue is the actual relationship between value and evolution isn't simple. The value of an investment in an activity and its related practices and other forms of capital which we spend financial capital on to acquire (e.g. by training) doesn't just decline with evolution. There are step changes as it crosses the boundary between different evolution stages. For example, a massive investment in computing as a product (e.g. servers, practices related to this and other components such as data centres) changes as compute shifts from product to utility. What was once a positive investment can quickly become a technical debt and a source of inertia. The act of computing might be becoming more defined, ubiquitous and certain but our past investment in assets can quickly turn into a liability. In practice, the early adopters of one stage of evolution (e.g. buying compute as a product such as servers) can quickly find themselves as the laggards to the next stage of evolution (e.g. cloud) because of their past investment and choices. The same change appears to also happen up and down the value chain. For example, with serverless (a shift of platform from product to utility) then often the first movers into the world of cloud (i.e. utility infrastructure) and DevOps (i.e. co-evolved practice) exhibit the characteristics of laggards to the serverless world whilst some companies that many would describe as laggards to cloud are the early adopters of serverless.

These changes in the value of a stock are problematic because in accountancy and financial reports we rarely reflect the concept of evolution. At best, we use the idea of depreciation of some form of static stock but fail to grasp that the stock itself isn't static.  The balance sheet of a company might look healthy but can hide a huge capital investment that has not only been depreciated but is now undergoing a potential change in the stage of evolution e.g. data centres, servers and related practices that will quickly become a huge financial burden requiring massive investment, retraining and re-architecting. The idea that suddenly an asset can become a liability due to a change of evolutionary stage in the industry is not one that fits well with double entry book-keeping. In other words Assets = Equity + Liability doesn't work quite so well when Assets become Liabilities due to outside forces. It's not that these things can't be accounted for, it's simply that we generally don't. This is one of the dangers of looking at a company financials. We can often make statements on the market evolving and impacting revenue but less frequently consider the debt that a change in evolution can cause. This also is not something that should surprise us. Unless there are genuine constraints then with enough competitive pressure, all the technical/operational obstacles to evolution (the four factors of technology, suitability, attitude and concept) will be overcome and such changes will happen. It's never a question of if but when.

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

Figure 249 - Capital and Purchasing.


The point of this is that not only does capital evolve (whether activities, practices, data or otherwise) but so does the means by which we should purchase it.  In any organisation you need at least four different purchasing frameworks across the company. In any large complicated system, there isn't such a thing as a one size fits all purchasing method and you'll need to use many. Unless of course, you like things such as explaining massive change control cost overruns and trying to blame others. Maybe that floats your boat because it's simple and at least the vendor provides nice conferences.

On Balance
Whether it's finding opportunities (i.e. stepping stones that expand your future possibilities), using policy to change the game rather than just technology or whether it's the flows of capital within a system and how we account for or purchase it - these are all elements which we use in gameplay. There are also complications within the system i.e. inertia is both a good thing in terms of keeping you from industrialising an industry too early but also a disaster if you haven't effectively managed it when an industry is industrialising. In the same manner an investment in some form of capital can rapidly become a debt as the space evolves. The maps can help guide you but you'll need to scenario plan around them. In the next few chapters, we're going to start going through a long list of specific plays before we come back and break down an entire industry.

To prepare you, I've listed the general forms of gameplay in figure 250. I've organised the table by broad category i.e. user perception, accelerators, de-accelerators, dealing with toxicity, market impacts, defensive, attacking, ecosystem, competitor, positional and poison. Each of the following chapters will deal with a single category (eleven chapters in total) using maps and where possible examples to demonstrate the play. By now, you're probably ready and dangerous enough to start playing chess with companies or at least learning how to do so.

Figure 250 - Gameplays.


Wednesday, August 23, 2017

Better for Less

Chapter 18
(a very rough draft)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

I started talking with other CEOs, CIOs and CTOs and rapidly discovered that nobody knew what maps were. Even more shocking, despite my assumption that everyone else had their own way of mapping, it turned out that no-one did. It was in 2011 that this revelation truly hit home. I was working for the Leading Edge Forum (a private research organisation) with access to the great and good of many industries and many Governments. I had undertaken a very informal survey of around 600 companies and concluded that only four of those companies had anything remotely equivalent to a map. In each of these cases, they were using mental models. The entire world was playing a game of chess without ever looking at the board. Suddenly, my success at taking over the entire cloud space with Ubuntu despite the wealth and size of competitors made sense. Their inability to counter my moves was simply due to blindness.

Part of the problem with the “Better for Less” paper was I had assumed that everyone had some form of maps. Without these, it would be next to impossible to remove duplication and bias, to introduce challenge into the system and to apply the right methods. I had talked about spend control becoming the institutional seat of learning for Government but without maps that wasn’t going to happen. By late 2012, I had already started to notice problems particularly with the use of agile.

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

Figure 235 - High Speed Rail Map


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

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

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

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

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

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

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

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

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

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

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


Assumptions and bias
Assumption is a very dangerous activity and one which has constantly caught me out. In the past I had assumed everyone knew how to map but the real question is why did I think this? The answer in this case is bias. When it comes to bias with maps then there are two main types you need to consider. The first is evolutionary bias and our tendency to treat something in the wrong way e.g. to custom build that which is a commodity. By comparing multiple maps then you can help reduce this affect. The second broad and powerful group of biases are cognitive biases. Maps can help here but only through the action of allowing others to challenge your map. The most common and dangerous types of cognitive biases I have faced (and my description as most common and dangerous is a bias itself) are: -

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

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

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

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

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

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

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

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

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

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

There are many forms of bias and it’s worth spending time reading into these. For myself, I assumed that if I knew something that everyone else must know it as well. This is known as the false consensus bias and it’s the reason why it took me six years to truly discover that others weren’t mapping. It was also behind my assumptions in the “Better for Less” paper.


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

I do know that there is an order to doctrine. For example, before you can apply a pioneer – settler – town planner structure (i.e. design for constant evolution) then you need to be thinking about aptitude (skillsets) and attitude (how those skillsets change) within a company. But this also requires you to have applied a cell based structure (i.e. think small teams) to start noticing the differences. But before you apply a cell based structure then you need understand the landscape (i.e. focus on high situational awareness). But before you can understand the landscape, you need to clearly understand what the user needs (i.e. focus on user needs). However, beyond broad strokes, I don’t what bits of doctrine matter more i.e. is transparency more important than setting exceptional standards? 

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

Figure 236 - Phases of Doctrine



The phases are: -

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

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

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

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

Are the phases, right? Almost certainly not and they are are probably missing a significant amount of undiscovered doctrine. However, they are the best guess I can provide you with.

On the question of failure
There is one other aspect of doctrine which I’ve glossed over which is worth highlighting – that of managing failure. When it comes to managing failure then life is a master. To categorise failure I tend to use CS Hollings concepts of engineering versus ecosystem resilience – see figure 237

Figure 237 - Types of Failure



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

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

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

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

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

You need to apply thought
One of the problems of mapping is people expect it to give them an answer. Maps aren’t a 2x2 where your goal is to get into some corner to win the magic prize. All maps do are help you understand the environment, challenge what you’re doing, encourage learning and the application of a bit of thought. There can exist all sorts of feedback loops for the unwary. For example, let us consider healthcare. You have a Government that has needs including a need for people to vote for it (assuming it’s a democracy). Those voters also have needs one of which is to survive. In the case of medical conditions this requires treatment of which there is a pipeline of treatments. From once novel treatment such as antibiotics which have become highly industrialised to more novel treatments today such as CRISPR. Overtime, all these novel approaches evolve to become industrialised and novel approaches emerge. Hence a pipeline. Obviously, such treatment has a cost hence we assume there is a budget for healthcare along with treatment centres. Now, let us assume the Government has decided to provide universal healthcare. Since this won’t be cost free then we will require some taxes. We can quickly map this up – see figure 238

Figure 238 - Map of Universal Healthcare


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

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

Figure 239 - Healthcare Feedback



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

Figure 240 - Medical Fund


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

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

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

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

Figure 241 - OODA


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

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

Figure 242 - JDI to PDCA to DMAIC



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

Figure 243 - The automotive industry


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

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

Figure 244 - The automotive industry, 2025


First is the rising importance of design in creating the immersive experience (shown as red connection line). Second is the issue of status and that immersive experience. If the cars are the same we still have that need of status to be met. One way to achieve this is to have digital subscription levels e.g. platinum, silver and bronze and to subtly alter the experience in immersion and both the look of the car depending upon who is currently occupying. A standard bronze member might get adverts whilst a platinum member would be provided to more exclusive content. But that doesn’t really push the concept of status. The third addition is a link (in red) between status and route management. If a platinum member needs a car then they should be higher priority. But more than this, if you need to go from A to B then whilst you’re driving (or more accurately being driven) then lower class members can pull over into the slower lane. With human drivers that isn’t going to happen but with self-driving vehicles then such privilege can be automated. Of course, there’d be reactions against this but any canny player can start with the argument of providing faster routes to emergency vehicles first (e.g. fire, ambulance) and once that has been established introduce more commercial priority. Later, this can be further reinforced by geo-fencing privilege to a point that vehicles won’t drive into geographies unless you’re of the right membership level.

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

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

Figure 245 - Automotive, points of war and gameplay



An exercise for the reader
We’ve covered quite a bit in this chapter from fleshing out various concepts around doctrine to the issue of bias to the question of failure and feedback loops to scenario planning. Some of these concepts with touched on before in previous chapters but then learning mapping is like the strategy cycle itself – an iterative process. Of course, practice matters. So, I’d you to undertake three separate activities. 

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

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




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