Wednesday, October 31, 2018

What is an expert


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


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.