X marks the spot | Simon Wardley

Wow, wow, wow! Thank you ever so much! Has anybody here heard of my stuff? If you can just... Some of you, right? Who is this completely new to, and you have no idea - what I'm going to be talking about? The vast majority, excellent! Right, X Marks the Spot. I'm going to start with the origin of how I got into mapping, - then I'm going to talk about maps themselves. What is a map? I'm going to talk about how to map, why we should bother. Then, I'm going to talk about patterns, and after we talk about patterns, - I'm going to get into the concept of change. So, how we use maps to understand - what's going on with our industry, our space. And then, I'm going to get into gameplay. And finally, I'm going to wrap it all up in X marks the spot. And I'm going to try and do this with a ridiculous number of slides. If we actually get this far, then I'm going to talk about AI, - particularly some of the horror stories, - and then finally, I'll get into something called digital sovereignty, - if we get that far. Does that make sense to everybody? [audience:] Yes. - Right, super. So, let's start with the origin. So, many years ago, I was working for this company. It was an online photo service. This was back in 2004. Very profitable, 16 different lines of business, - but it had a massive problem. And the problem was this person, the CEO of the company. [audience laughs] Our fat cat was completely clueless. They had no idea what they were doing, - they were making things up as they went along. Now, I know this for a fact because I was the CEO. [audience laughs] I used to come up with these wonderful statements, - you know, our strategy is customer focused, - we will lead an innovative effort in the market - through our use of agile techniques and open source. Wonderful stuff. I'd literally pinched that from another company and just changed a few words. That was the level of strategic play that I was exhibiting. And I used to read every book I could find on strategy. I was getting nowhere. And I ended up in a bookshop in Charing Cross in London. And I was talking to the bookseller, - and she said, "Have you ever read Sun Tzu's The Art of War?" And I went, "No." And being a good bookseller, - she sold me two different versions of the book, - [audience laughs] because they're all translations. And I'm really, really grateful for this, - because it was in reading the second version - I noticed a particular pattern. So, Sun Tzu talked about five factors that mattered in competition. First, have a purpose, a moral imperative. Second, understand the landscape that you're actually competing in. Third, understand the heavens, the climate, - the weather, how the landscape is changing. Then, you get into principles of organisation - or the collection of principles we call doctrine. And finally, you get into gameplay. How do you manipulate the space to your favour? Now, I was fascinated by this, and at this time, - I also came across the work of the Mad Major, John Boyd. Anybody heard of John Boyd? Famous for... OODA loops, OODA loops. So, very heavily used in political circles as well - through a particular process called the cycle of outrage. John Boyd was a major in the US Air Force, - came up with this concept of OODA. So, the first O of OODA is to Observe the environment. That's what landscape and climatic patterns are about, - observing the space you're operating in. Then, you orientate yourself around the space. That's what doctrine and principles are about. And then, you need to decide where you're going to act, and then you act. So, that's the OODA, Observe, Orient, Decide, Act. And they overlap quite nicely together. And so, I had this strategy cycle. Now, for me, this sort of made a lot more sense - than anything I had been reading beforehand, - and I started to ponder this question - of how do I observe the landscape I'm competing in, - and that's what got me into maps. Does that make sense? - [audience:] Yes. Good, so I started to read everything I could find on military history, - because they use maps a lot. [audience laughs] And [chuckles] one of my favourite battles - is this battle, the Battle of Thermopylae. So, Themistocles was an ancient politician Greek general, - had a problem, the Persians were invading. Now there are about 140,000 to 170,000 Persians, - we don't quite know how many. And of course, the Greeks were independent city-states - which worked together when there was an invading force. And so, what Themistocles decided to do - was to block off the straits of Artemisium, - force the Persians along a narrow pass called Thermopylae, - or literally it means the hot gates, - where a small number of troops could defend against a larger force. Now, there were 4,000 Greeks against the 140,000, 170,000 Persians, - and including in that 4,000 were 300... Spartans, and that's where we get the story of the 300 from. I was fascinated by this, I could see the maps, - how you could use it to coordinate. So, I started to think about my business. How was I operating? Well, I was using something called a SWOT diagram. Have you ever heard of SWOT diagrams? So, I created a SWOT for this battle. Strengths. A well-trained Spartan army. A high level of motivation not to become a Persian slave. [audience laughs] Weaknesses. The Ephors might stop the Spartans turning up. A truckload of Persians are actually turning up. Opportunities, get rid of the Persians. Get rid of the Spartans. We're Athenian. We actually hate the Spartans, - so if we can get rid of them, that's a bonus. And the threats, the Persians get rid of us, - and the Oracle says a really dodgy film might be produced - in a few thousand years later. [audience laughs] And so, I simply put this next to each other and asked, - what would you use to communicate and determine strategy in battle? A SWOT diagram or position and movement on a map? So, what would you use? A map. What was I using? Magic framework, yes. So, I went back to my office and said, "Right, give me, everybody, - give me all your maps," and I got loads of maps. I got mind maps, I got business process maps, - I got systems maps. This is one of the systems map. Various components connected together, - and I was looking at this map, and I thought, - well, I'm going to take a component, CRM, - and I'm going to move it across the screen. Isn't that exciting? [audience laughs] Right, now I'm going to ask the question, - how has the map changed? How has the map changed? Any answers? It hasn't. But if I take a geographical map, and I shift Australia - and put it next to the UK, that definitely has changed. [audience chuckles] So, why hasn't it changed here? Any ideas? It's not a map, exactly. The one thing that all the maps that I had had in common - was none of them were actually maps. They're all graphs. So, to explain the difference, here's three locations in the UK, - Nottingham, London, Dover, connected roughly by two roads, the M1, M2. Now, if I moved Dover, like that, has that changed? No. No, it's just a graph. In fact, all these three diagrams at the top - are all graphs, and they're identical. But the three diagrams at the bottom - are all completely different, and they're all maps. So, why are they different? Okay. The difference between a map and a graph is, - in a map, the space has meaning. It represents a landscape. It's not nothing, the white space. It's actually a landscape. Now, in order to give space meaning, you need a number of components. You need one, an anchor such as magnetic north. You need position of pieces, and you need consistency of movement - through that landscape. So, how do you map a business? Any ideas? I hadn't got a clue. [audience laughs] All I knew is I didn't have maps. So, I found a way. It took me - approximately 10 months, 9,223 publications later, - to find a way of doing it, and a lot of accidents. I'll explain it through a cup of tea, - because I'm a Brit, and I like cups of tea. So, I want you to imagine I ran a tea shop. What's my anchor going to be on a tea shop? Well, I might have the public who, hopefully, wants - to consume my cups of tea, - and I have the business who wants to sell cups of tea. So, those are my anchors. I could have regulators who want to make sure - that my tea isn't poisoning people, something along those lines. That's fine. So, I've got an anchor. Now what? Well, it turns out that a cup of tea has needs. It needs a cup. It needs tea. It needs hot water. Hot water needs cold water. It needs a kettle. Kettle needs power. So, what I've got is a chain of needs. And that gives me position. The further I go down the chain, - the less visible something is higher up that chain. So, that's anchor and position. But what about movement? Well, this was the hard bit, - because how do you describe movement in a space like this? Well, it turns out that there is a landscape, - and that landscape is capital. So, capital as in terms of the activities, practices, - data, knowledge, even the values that we have. And that capital is evolving through common stages. Now, we call them stage one, two, three and four, - but that's really meaningless. So, what I do is I use labels for each of those stages. And the labels I commonly use are these. Genesis custom-built product commodity. So, I simply take my chain, my graph, and I ask, - how evolved are these components? Is it a commodity? Is it a product? Is it custom-built? Is it something totally novel and new? Now, this is a map. So what? [audience chuckles] But the point about a map is I'm actually putting my story - into a form that you can easily challenge. You might ask, why have I got Kettle in custom-built? You might say, I'm missing staff. Normally, in organisations, we use stories. Now, we tell everybody that great leaders are great storytellers, - and that creates a problem. Because when you challenge somebody's story, - you're challenging their leadership ability. So, they get very, very defensive. If you can get them to put it in a map, - I can say, I think there's something wrong with the map, not the person. Does that make sense? Good. So, here's a typical example. This is from an insurance company. This is 2010. I've been mapping for almost 20 years now, - so this is all quite old, and this is all Creative Commons. This is about 2010, 2011. They had a problem. They needed compute, order server, - server goes into Goods In, they mount, modify, rack it. There was a bottleneck, and they wanted to improve the process flow. So, they came up with this idea of investing in robotics - to get rid of this bottleneck. It was a multi-million dollar capital investment. They had built the entire business case, return on investment calculation, - sub one year, they're about to go. And I was asked, could I have a look at it? Now, the problem is I can't go in and challenge their story - because they built this whole story. So, I said, well, could we map it? They went, "Oh, we don't know about that, we don't [mumbling mockingly]" Fifteen minutes of arguing, then we said, "All right, we'd map it." It took 15 minutes to create the map. Here's the map. It was 2010. Right, user needs compute. Compute order server, very commodity-like. Server, commodity-like. Interesting, server's commodity, - but compute they thought was more late product, okay? Goods in, rack, mount, modify. Anybody got a question to ask about that map? [audience member speaking from distance] Perfect. Why are the racks in custom-built? That's all I did. I said, why have you put racks in custom-built? And they said, "We had custom-built racks." Ah! What are the modifications you're making to servers? Well, the servers we buy don't fit our racks, - so we have to take cases off, drill new holes, add new plates in order to get them to fit our racks. Ah! And that's why you need robotics. Yes. Do you know what happened about two minutes later, - what somebody said in the room? Why didn't we use standard racks? [audience chuckles] Now remember, these people weren't daft. These people had spent six months working on this problem. The issue is they were trapped by past stories. At some point in the past, there was no such thing as a standard rack. And so, being very sensible, they thought we'd organise their compute, - and they had custom-built racks. No one had challenged that story. In fact, what they'd done is they spent all their time improving process flow, - and if you improve process flow, you would invest in robotics - because it makes sense and the return on investment calculation is sub one year. They never considered evolutionary flow, that the things actually change. Does that make sense? How many of you have seen this problem before? Okay, that's more than map. That's pretty impressive. All right. So, one of the things I do with maps is what I call pre-mortem, post-mortem. So, before I do something, we map the space, and we use it to challenge, - to get rid of all the common problems. And then, once we've got a map, we go build it. And once we've built it, we come back, and we look at the map we created - and do post-mortem learning. And from that, we learn patterns. I'll give you an example of a pattern. This is HS2, high-speed rail, big heavy engineering project, UK. This is James Findlay. James Findlay was the CIO for HS2, had a problem. We needed to build the entire railway in a virtual world - because it's cheaper to dig up a virtual world - and go, "Whoops, we've got that wrong," than the English countryside. It's a sensible thing to do. This is the systems graph for building HS2 in a virtual world. Any suggestions on how to manage that? How would you manage it? [chuckles] Don't say SAFe. [audience laughs] Sorry. I was the chaos monkey for the SAFe Leadership Summit back in 2019. I tore into them, but it doesn't matter. That's another story. How would you manage? Any ideas? I'll tell you, back in 2011, 2012, I think this was about 2012, - we used to outsource a lot in government. So, we'd break it down into common components, - so bounded context, we'd say like power, data centre, compute, - that sort of infrastructure, we'll put it in one project. We'd go GIS, land registry, that's all engineering, - we'd have another contract, and we'd outsource it all. So, multiple different contracts we'd outsource, - and then we'd have mass cost overruns and failures. Anybody experienced that? Yes. So, James spent Sunday afternoon, mapped it out, sent me the map. This is what the map looked like. It was 2012. And he said, "How do you manage something like this?" This was easy for me. See, back in 2005, 2004, I'd adopted... No, sorry, back in 2000, it was a friend of mine, Kent Beck, - I had adopted extreme programming throughout the entire organisation. By about 2004, we realised it didn't work everywhere. We couldn't explain why. Once we had maps, - we had a way of explaining what the problem was. So, it was easy for me to explain to him - this pattern that I had learned beforehand. So, here's your map, and all the components are evolving - from the unchartered space on the left-hand side - to the more industrialised space on the right-hand side. It doesn't matter whether it's money, computing, penicillin. It all starts over here on the left, so compute. First compute Z3 in 1943, - then you get custom-built examples like LEO, - then you get the products, first products IBM 650, - rental services like Tymshare, - commodity, hardware and cloud eventually. So, everything's evolving, - and what we had learnt is there's no such thing - as one-size-fits-all project management methods, - or purchasing methods, or finance methods. So, on the left-hand side, you're all about change. So, what you want to do is reduce the cost of change. So, extreme programming, very good on the left. The same thing as it evolves - over an unspecified amount of time ends over here - in the more industrialised space, well, there you're reducing deviation. You don't want change, you just want the same thing, but many, many times. So, Six Sigma outsourcing works well. And in the middle, you're all about learning and reducing waste. So, things like LEAN works well. So, we simply apply that. You do stuff on the left, build in-house Agile techniques, - stuff in the middle, off-the-shelf products. If we're going to have to build, we'll go down to LEAN. Stuff on the right-hand side, outsource to utility providers if they are provided. If they're not, if we're going to build our own utility service, - we'll be doing something like Six Sigma. Does that make sense? Easy, isn't it? Use appropriate methods. There's a world of difference between being Agile, - or using Agile I should say, - so using things like extreme programming, - and being Agile, which is using appropriate methods, - including maybe Waterfall over here, - a lot of off-the-shelf products in the middle. Of course, if you turn up to an Agile conference and say, - "Agile doesn't work everywhere," they will go, "Burn him, heretic." [audience laughs] It's okay, you can go to a Six Sigma conference and say, - which I've done, "Six Sigma doesn't work everywhere," - and you'd get, "Burn him, heretic", as well. So, let's take one of the original contract structures. There we are, from the graph. I'll simply overlay that on a map. That's what that contract structure would look like. I know that this contract will fail - as soon as we've signed the paperwork. Why? Because the stuff on the right can be specified. So, we can put it in a contract and know what's going to be delivered. The stuff on the left can't be specified. It's always going to incur massive change control cost overruns. Now unfortunately, if we go back, - the worst thing that can happen to you - is you get into a fight with the vendor, the vendor says, - "Oh, but you know, we delivered all this stuff and blah-de-blah"- and you say, "Yeah, but at massive cost." Well, that's because you didn't know what you wanted. You can't know what you want. The problem is the contract. The worst thing that happens is somebody on your own side turns around and says, - "Next time, we need to specify it better." [audience chuckles] No. [chuckles] [audience member:] SAFe. - No, go SAFe. My only suggestion there is fire them. So, anyway. [chuckles] It always leads to cost overruns. Now, to give you an idea of scale, one project alone in UK government, - we save 450 million simply by changing the contract structures. This stuff has been used all over the place. I mean, my friends at Planet Labs worked with NASA - on putting the Carbon Mapper satellite. They actually used maps between the two different groups. I didn't even realise NASA was using mapping. I found out yesterday. Somebody, oh, sorry, today, somebody mentioned they were. But anyway, I want to give a quick test. This is the Elvish self-driving car. So, what I mean by that is I've taken a self-driving car - and translated the system diagram into Elvish. [audience laughs] And I translate it into Elvish because, well, to IT, finance is a bit Elvish, - and to finance, IT is a bit Elvish. So, I'm going to be IT, and you're going to be finance. Here's the systems diagram. I want to cooperate. I want to collaborate. I want to work together with you. So, A, B and C. A, what should we do with it? Do you think we should outsource it, build it in-house, - or maybe use off-the-shelf products? What do you think? Any suggestions? Anybody willing to say? - [audience member:] We build our own. Build our own, okay. People actually make these decisions - based upon this sort of information. You shouldn't do anything, actually. All right, so let me try it again. Exactly the same, but this time mapping format. A, should we outsource, build our own, or off-the-shelf products, - what do you think? - [audience member:] Outsource. Outsource it. C, what should we do with C? [audience member:] Off the shelf. - Off the shelf. What about B? Easy. Make sens