Maps, AI, and the Future of Reasoning: A Conversation with Simon Wardley

Storytelling vs Mapping

Charles Humble: Hello and welcome to this episode of the "GOTO Unscripted" podcast. I'm Charles Humble. I'm a freelance techie, editor, author, and consultant. And this is the sixth episode in a mini-series of podcasts that I'm doing for GOTO talking to software engineering leaders. Today, I'm joined by Simon Wardley. As a geneticist with a love of mathematics and a fascination in economics, Simon has always found himself dealing with complex systems, whether it's in behavioral patterns, environmental risks of chemical pollution, developing novel computer systems, or managing companies. He is a former CEO, a former advisory board member of Startups, all now acquired by U.S. giants, a fellow of Open Europe, and the inventor of Wardley Mapping. He has twice been voted the top 50 most influential people in the UK IT industry and is also a regular conference speaker, and he and I met up recently at GoTo Copenhagen where he was giving a keynote. I'm a huge fan of Wardley Mapping. It's a technique that I've used myself on the executive teams I've served on and more recently in my consulting work. And if you heard the episode of this show I recorded recently with David Anderson, you'll know that David also applied the technique with astonishing results at Liberty Mutual. So, I'm really looking forward to this conversation. Simon, welcome to the show.

Simon Wardley: Fantastic. Thank you. I barely recognize myself in the introduction. I'm just this guy who has an interest in maps and, because I found it useful I made it all creative-commons and it turns out that other people have found it useful as well. So, gosh, wow, I don't know what to say. I'm sort of, I'll just crash and burn now. But after that introduction, I really am just a very ordinary person by the way. But, anyway.

Charles Humble: I don't think so but either way. So, as I said you're very well known for mapping obviously but you're also well known for being somewhat hard on stories and storytelling in this context. So, I thought maybe we could start there. So, could you explain what it is you have against storytelling?

Simon Wardley: Oh gosh, so one of the things about... Is it something I have against storytelling? That's an interesting one. So, part of the problem with storytelling is we have this idea that great leaders are great storytellers. In fact, we've run all these courses to teach people how to be better storytellers, etc. And the problem with that is that when somebody gives a story, if you're challenging the story, you're actually challenging their leadership ability. So, whether you know it or not, you're actually saying, "I don't think you're a great leader." And so people get very, very, very defensive in this world of stories. So, one of the reasons why I use maps, and almost, it's the same reason why architects use models, is it gives something that people can look at and say there's something wrong with the model. So, in which case, in my case, you take a story, you put it into a map, and then people can challenge the map, say there's something wrong with the map.

Because all maps are imperfect representations of space, there's no such thing as a perfect map, even geographical maps. I mean if you wanted a perfect map of Paris it would have to be one-to-one scale, which means it would be the size of Paris. And as a map that would be useless and of course, somebody would have moved something, so it would be wrong. So, all maps are imperfect representations which encourages a challenge. And so it's not so much... I understand and see the benefit of stories. The problem with them is they are too tied up with this concept of leadership and so it makes it difficult to challenge. And so that's why I like maps. Get out of the world of stories, get into a map, then you can say the map is wrong, not the person is wrong. And that way we can come together as a group and we can get some consensus about what we need to do.

Recommended talk: The Value Flywheel Effect: A Modern Cloud Strategy • David Anderson & Charles Humble • GOTO 2024

Understanding Wardley Maps

Charles Humble: Yes. That's actually really interesting because that was... I mean I reached for mapping in exactly that situation. I was trying to argue against a CEO who had a very definite opinion about a direction we should be taking and I was saying, "I don't think this is right." It became very personal as these things sometimes do, or it started to feel very personal. I said, "Well why don't we, you know, let's just draw it out, map it out and see what it looks like." And it changes the context which I think is really powerful and really important. It's a little tricky...

Simon Wardley: ...well I'll give you another example of this. It's often, I use maps in things like conflict resolution. So, we'll take two opposing groups. So, one example I did for this was because mapping is about any form of capital. And so you can map physical practices, you can map data, you can map knowledge, you can map ethical values within a social system. So, you can map all of these sorts of things. And it enables therefore people to discuss that environment. And sometimes you'll get opposing groups. And so the example is I took a group of Brexiteers and a group of Remainers. And this was in the UK after Brexit. And it was quite amusing because in the room if you'd ask the Remainers, "Do you want a cup of tea?" And they went, "Yes." If you asked the Brexiteers, they would go, "No, I will have coffee." And you'd ask, "Would you have a biscuit?" They'd go, "Yes." And the other group would go, "No, we'll have cake." I mean these two groups would not see eye to eye on anything whatsoever. But through the medium of a map, because we got them discussing through the map, not the stories that each held. We managed to map out a general concept of culture, which is what we were actually looking for in relation to political systems. And so we were able to have a very vibrant discussion and find lots of commonality between the groups, even though in a story form, we were just going to go nowhere.

Charles Humble: That's really, really interesting. And it's a little difficult to do this on a podcast because obviously they are very visual by nature. But are you able to give a kind of quick description of what a Wardley map looks like for someone who hasn't seen one?

Simon Wardley: Sure. I mean, well, first of all, I'd better explain one difference, which is the difference between a map and a graph. Then we can talk about what the properties of a map are. And then I'll explain how you create a Wardley map. So, we have lots of things in business, which we call maps, business process maps, mind maps, systems maps, customer journey maps, all sorts of different maps, which is great. The problem is if you take something like a mind map or a systems map, and you take a component and just move it, keep the lines, the connections the same with other components, just move the component and ask yourself, "How has that map changed?" And the answer is it hasn't. Now, if you take a geographical map and you move a location somewhere else on the map and say, like you move Australia, you put it next to the UK, and ask how has that changed. It has fundamentally changed. And the reason why things like mind maps and systems maps don't change is because they're not maps, they're graphs. See, in a map, space has meaning. So, all the white space outside of the lines and the nodes is not nothing. It actually has meaning, which is why maps are very good for understanding a landscape.

Now, in order to create meaning for space, you need three basic characteristics. You need an anchor, such as magnetic north. You need position of pieces. This is north, south, east, or west of this. And you need consistency of movement. So, if you're going north, you're going north. You're not going east or west or south. If you're going south, you're going south. You're not teleporting all over the place, okay? So, you need those three basic components in order to describe a space. So, with a Wardley map, we start with the anchors of the users of the system. And those users can be vast and many. It could be if you are mapping a tea shop, it could be the consumers, as in the public buying cups of tea, the business, as in selling the cups of tea, the regulators making sure that your tea isn't poisoning everyone. So, there can be multiple different actors involved. Okay, that's anchor. So, how do you do position? Well, it turns out that, you know, if you're selling a cup of tea, a cup of tea has needs. You have a need to sell cups of tea or you have a need to consume cups of tea. But a cup of tea has needs. It needs tea, it needs hot water, it needs a cup.

Hot water has needs, it needs cold water, it needs a kettle. Kettle has needs, it needs power. So, what you can do is you can describe a chain of needs. Now, the further you go down the chain, the more components you jump over, the less visible something becomes to people higher up or components higher up. So, this gives you a sense of distance. By that, I mean, if you remember the public buying a cup of tea, the cup of tea is very visible. The power to heat the kettle, to heat the water is quite far removed unless you create a new chain which goes straight down to the power. So, that could be something like a desire for sustainability. So, a consumer not only wants a cup of tea, they also want sustainability. So, now you've got anchor and position described through a chain of needs. Now, how do you do the movement bit? Well, it turns out all of these components are living in a landscape of capital, which is the fundamental thing within our systems. And that capital has many forms. I mean, it's not just physical activities, it's not just money, it's also other forms of resources, even practices. And all of those forms of capital evolve through a common set of stages.

When we talk about physical activities, we talk about the genesis of novel and new items. And then over time, we evolve custom-built examples. Then over time, as we get more of those, we have products and rental services. Over time, we have commodity and utility services. So, if I just take my users, understand the chain of needs underneath it, you call that a supply chain or a value chain. The distinction being that a value chain is generally within an organization, the supply chain is usually an industry in most forms. So, if you go from users, understand the components in that chain of needs, and then simply ask the question, "How evolved are each of those components?" Then you can turn that into a map. And you do it by simply putting the evolution axis at the bottom, genesis, custom, product, commodity, or if you're dealing with, if you're mapping social values, you know, it's concept, emerging, converging, accepted, same four stages, same characteristics, we just use slightly differently. And so what you're doing is you're starting with the anchor at the top, the users, you're thinking about the components, and then you're simply asking the question, "How evolved is that?" And that will create your map.

Did that make sense? Although I need to have said...

Charles Humble: It did. Absolutely.

Simon Wardley: ...with that map, the first thing you find with most businesses is that once you do these mapping exercises, A, most businesses have a poor idea of who their users are. So, that just helps anyway. Secondly, most have a very poor understanding of their value chain, let alone the supply chain and industry. So, that actually helps mapping out those components. And thirdly, the way you treat things, the way you finance things, the way you purchase things, the way you manage things change as the components evolve. So, the way you would treat a custom-built kettle if there was no such things as products and utilities, or commodities, I should say, is very different from, you know, if you can just go down to, I don't know, Argos and buy yourself a very commodity like kettle. So, what you find is that most organizations poorly understand their users, poorly understand the components of the supply chain, and then poorly understand how to treat those components as well, because they don't even realize they are.

Charles Humble: Yes. Absolutely. How do you know when a map is a good enough representation?

Simon Wardley: A good enough representation. Okay. So, I map all sorts of different things, not just individual projects or businesses, you know, or even nations. I mean, I will do mapping of industries. And so, for example, healthcare, I took about 30, 40 clinicians and we got together and mapped out the healthcare system. And when you map, one of the problems you've got is perspective. So, what do I mean by that? Imagine no one's ever mapped Paris, and you send a group to go and map Paris, and they come back with a map, and you want to know where to invest. So, you say, what's the most important thing in Paris? They might go “Pierre's Pizza Parlor” because they've mapped Paris from a perspective of nice places to eat pizza. So, one of the things that you have with a map is not only things like a date, a map, you know, have a time when it was mapped, because it will change, but you will also have a perspective. And so if you want to try and understand an industry, what you will do is map from multiple different perspectives, and then you'll look at where to invest in all those different perspectives, and then you’ll aggregate it to give yourself a general picture.

The process of mapping itself, and, you know, be mindful of the time and the perspective you're coming from. We start by asking, you know, who do we think the user is, what components we start throwing them on the board, and how evolved, and have lots of discussion. And what you generally find is that the information that you need to map a space out is not in the minds of a single person, it's in the minds of many, many people. So, having that environment where you can just throw things on, and anybody can do this. And this is why I like tools like Mapkeep is one tool. I use Miro a lot. I like Miro, it's a great tool as well. Where people can throw things on top. And then what will happen is we'll start running through the chain of needs, does this make sense, having discussion, realizing other bits, throwing bits off, because we realize that's too complex. So, we'll put this in a sub-map somewhere else and have a new component.

We keep going until we find that we've got a good enough map that it's helping us have a discussion about the space and asking questions. And that process, you know, for an industry, it can take quite a bit of time. I mean, these groups that I run, we could spend up to six hours mapping, but I mean, to map out an entire industry. For a single organization or a single project, you know, really a couple of hours, ideally. And if within a couple of hours, you've not got something which is helping you to talk about the space, discovering things that you didn't realize was occurring, you're not learning, it's not what you thought is good enough, then just throw it away. And either start again or just give up and do something else. That's the way I look at it.

Charles Humble: There's actually an interesting point that I don't know if you would agree with me, but certainly my experience of this is that the process of mapping is more valuable than the map itself a lot of the time. The process of getting to a point of, you know, being able to have the conversation is really, really helpful. But quite often I find the map itself is fairly disposable at the end of it a lot of the time.

Simon Wardley: The process of mapping, I think, I agree, it's really important. It's interesting because I map books I read, I map my meetings I go to, I mean, I'm not mapping here, you can tell, I've got my key hands up here. But the one thing I do find is I often map meetings because if I come back to a meeting, 9 months, 10 months, 11 months later, I can bring up the map and very quickly be teleported back into the meeting. Because the main components and the users and everything's been identified so easily, I find it incredibly easy to be back in the meeting in a way that reading pages of meeting notes, I find it a very, very slow process. So, it takes me time to get back in, whereas I find I can just look at a map and be back in there within minutes. So, for me, I do find them useful for that sort of teleportation aspect. But the other thing I find useful is what I call pre-mortem, post-mortem.

So, before I do something, I tend to get the group together and we'll map out the space and decide what we're going to do on the map. Then we'll go and do something. And then afterwards, we'll do a post-mortem. So, we do the pre-mortem, we challenge what we're going to do on the map, we go to it, and afterwards we do the post-mortem with that same map. And so we can look at the map and from this is where I learn patterns, how things change. So, there's about 30 common economic patterns I've learned from this. Everything evolves, for example, we have inertia, particularly when we cross boundaries, all this sort of stuff comes from that. So, for me, yes, I totally agree. The process is more valuable per se than the map itself. But I do find value in the maps both for teleportation back to where I was and also learn the patterns from pre-mortem, post-mortem.

Recommended talk: X Marks the Spot: Navigating Possible Futures with Wardley Maps • Simon Wardley • GOTO 2024

Evolution and Movement in Technology

Charles Humble: That's really interesting. Can you talk through the basic stages of evolution in the tech industry? So, in terms of how we kind of industrialize and get to utility as it were, what does that process look like?

Simon Wardley: So, God, a little bit of history. So, I'm going to go back to 2004, just before I developed mapping. I was running a particular company as the CEO. I was completely clueless as to what I was doing as well. I mean, I was forever worried people would rumble. I used to read sort of every book I could find on strategies, I was getting nowhere. And then I very fortunate ended up in this bookshop in Charing Cross, a bookseller, she persuaded me to buy Sun Tzu's, "The Art of War." And it's in reading that, that I discovered the importance of understanding your landscape, mapping your environment. So, when I started trying to map, the bits that were easy or I thought were easy, was trying to work out what the anchor was, because they just picked an anchor and tried to understand the chain of components. Well, that gave me a graph. The tricky bit was trying to understand this concept of movement. Because geographical movement is fairly straightforward, because if I go from, I don't know, London to Birmingham, it's unlikely that Birmingham will have changed its position during my journey. Now, if my journey took 200, 300 million years, then yes, Birmingham might have moved. And so part of the problem with the capital is that the landscape moves much, much faster. It doesn't take 300 million years for things to dramatically change.

I mean, you look at computing 1943, Z3, Lyons Electronic Office (LEO), then you get the IBM 650, first products, rental services, eventually commodity hardware, and then cloud in 2006. So, you're talking about 60 years to go from a concept to utility provision. I mean, electricity took about 1300 years to do that journey. And every time we industrialize communication mechanisms, the printing press, telephone, the internet, that process speeds up. And so these days, you're talking maybe 30, well, there's some debate, about 30 years, 30, 50 years, maybe from something to go from actual genesis to becoming sort of more of a commodity. So, that process is fast. So, if you're going to map movement, you've got to map it in terms of change or evolution. But how do you do that? I had no idea whatsoever. I tried all sorts of different ways, thinking of different axes, blah. I had some great ideas over coffee. And then, of course, I went looking for data and it all fell apart. So, I spent six, seven, eight months just trying to solve this one particular problem. And I had almost given up at the end. It was just, like, because I was doing it then on my own dime and everything else. And it was just like, it's just impossible. I have no way of doing this. But I was really lucky. Again, I have been very fortunate in lots of things.

I'd collected about 9,223 publications. And I was reading some of the publications and one of them was all about the wonder of the telephone. And it was going on about how you hold the telephone receiver and everything else, which way up it goes, and all the rest of it. And I just thought, "You don't teach people this, these days," you know, you don't have to write manuals on this. And there was another one, which was a poster, which was for Edison Electric Light. And it was a poster about how you should use the switch. Don't try and light it with a match. And you just don't teach. And so it dawned on me that maybe there was something in the publications. And so I started categorizing the publications around key particular words. And out of this, this pattern of the genesis and novel and new things we talk about, the wonder of things appeared. So, like the wonder of radio, all the publications talked about the wonder of radio, for example. Then, as it evolved, they started talking about how to custom build your own radio sets, crystal radio sets, how to construct one blah de blah. Then the publications changed again. And so I'm talking more about feature differentiation, this radio is better than that radio, etc. So, it's all about that sort of stuff. And lastly, the publications changed again.They didn't talk about radio at all—s in the device—they talked about what was on the radio. So, the Radio Times, good shows and all this sort of stuff, how to have a radio voice or whatever. 

So, what I found was in the publications themselves through history, there's this pattern of these different four stages. And that pattern appeared whether I was looking at money, telephone, penicillin, computing, all over the place. And so that text analysis became the basis for those four stages of evolution, which when we talk about physical activities, are genesis, custom build, product, commodity. And there's something called the cheat sheet, which has a list of characteristics for each of those stages, all coming from that publication stuff. The text analysis, which you can use to sort of help guide you, particularly if you're in a debate about where something actually is. So, it was all a bunch of luck. And I almost gave up many, many times. And I spent far too long buried away, hidden in the British Library. And it was luck. And that I found this pattern. And I have to say a big thank you to the bookseller who started me on this journey. And whoever wrote the pamphlets on how to use your telephone, has a big thank you because without that, I would never have stumbled upon any of this.

Centralization vs Decentralization

Charles Humble: As we move towards commodity thinking particularly about tech, do we always end up centralizing? Because we did that in the cloud to a very logical extent. We ended up, you know, converging on, essentially, it's AWS. And if you're not using AWS, you're using Microsoft or possibly Google. And at least obviously in the West and China, it's a little different. So, do we always end up centralizing?

Simon Wardley: All right. So, there is one question, which is the evolution of something to more of a utility. And there's a second question, which is decentralization versus centralization. And they're governed by different forces. So, if you think about electricity provision, I mean, electricity, well, for most people, it's become a utility, as in you've got a plug socket in the UK, it's 240 volts, it's 50 hertz. If you actually map out the supply chain underneath this, there's a world of other stuff going on. I mean, you've got not only generation, you've got distribution mechanisms, and you've got things like not only supply and demand, but you know, things like mechanical inertia, big spinning metal discs are actually really important for stability in the grid. So, there's a massive amount of other components involved hidden behind this interface, 240 volts, 50 hertz, okay? Now, it has become a utility. And that's the way we treat it. And we buy it from somebody and it is provided to us in a very standard form. We pay per kilowatt hour, etc. But that doesn't mean it all has to be centralized in one party, it can be decentralized. There's no reason. And that's governed by different forces, different economies of scale.

So, in my home, I have my own solar systems, I have my own batteries and all the rest of it. So, I do part of the generation. I mean, I haven't built my own grid. I'm not changing... I'm not running a different... I'm still using 240 volts, 50 hertz. I'm still attached to the grid. I haven't gone around saying, "I'm going to have a completely different voltage system," because then all my devices wouldn't work as well. That would just be madness. But I'm partially decentralized, I get some from the grid. So, when we do the transition from product to utility, what controls whether it centralizes or decentralizes? Actually, it's quite interesting that change, because we have a lot of inertia to that change, because of pre-existing practices. And you saw this with cloud where people with data centers and all the rest of it, were in denial that it was going to become a utility. So, what determines whether it centralizes or not is actually the level of strategic play of the competitors. Mostly. So, if you've got one player in there, who knows what they're doing, and against a whole bunch of people who are fairly hopeless, that it would centralize around them, particularly if they can create some sort of network effect.

But that's not a permanent state of affairs. I mean, eventually, other people start to get an idea of what's going on. They can find other ways of creating network effects. So, you can start to deal with other reasons for people to be decentralized. So, it can be broken away. So, even something like compute. I mean, over time, it might be more and more decentralized, but it will all be the same standard, or should be, which is why I try to push OpenAI before they launched to adopt the Amazon EC2 API. Because it was just like, just co-op them, just distribute it. But unfortunately, they didn't. And power, you're seeing that some of us have distributed, and some of us, it's more centralized. And a lot of that depends upon things like the economy's operation, the cost of actually setting up your own environment, is it worth what I'm doing? Are there other needs you're actually meeting? So, in my case, because where I live in the UK, we actually have fairly poor power supply. I mean, we've had 11 power cuts in the last year. So, I need resilience to that. And, of course, it's very sunny, so I wanted to generate most of it as well. So, there was a whole bunch of reasons which conspired to be distributing on my side.

Charles Humble: Right. 

Recommended talk:Balancing Tech & Human Creativity • Kaiser, Greiler, Carpenter, Terhorst-North & Wardley • GOTO 2024

Understanding Inertia

Charles Humble: You've mentioned inertia a couple of times. So, when is inertia a positive thing, and when is it a negative thing?

Simon Wardley: Oh, that's such a good question. So, every time you cross a boundary, whether it's genesis to custom-built or custom-built to product or product to commodity, we're going to have to cross an inertia barrier. Now that inertia barrier, if you've got the concept of providing the technology in a more evolved form, you've got suitability to be provided. You've got the technology to provide it in the more evolved form. And most importantly, you've got an attitude. So, I call it cast. If you've got an attitude, as in customers are really fed up with the way it's currently provided, then you can then you can often shift it into that new form, okay? So, if you go back to 2006, and cloud concept suitability, technology was all there. Everybody was getting sick and tired of paying a fortune for servers and all the rest of it, particularly for small jobs. So, all the characteristics were there. Now, that inertia, there's about 16 different forms of it. So, you can have pre-existing capital, for example, I've got a data center. You've got political capital; I've just told the CFO we're spending 600 million building the data center or I've got existing practices; we're used to dealing with servers and all the rest of it.We've got our own guides for how to do it. all this cloud stuff is totally new. So, there is all this sort of... Well, it's not new, it's a more evolved form, but the utility is new to us. 

So, we've got all these reasons not to adapt. That inertia often kills companies. So, if you think of Blockbuster, Netflix, Blockbuster first with a website, first with video ordering online, first with video streaming experiments, first to go bankrupt, because its entire business was... Well, most of its business was based on late fees, which required physical stores.

So, inertia sounds like it's a really, really bad thing. And if you've got inertia, you've got to somehow punch your way through to the other side. Yes and no, because if you're thinking about profitability, inertia is the bit that keeps you in the product phase, for example. So, you make a high return per unit, you don't get the volume and everything else when it's in the product phase. And so that inertia is like stopping you from industrializing your own space too soon. The problem is, it's also going to stop you industrializing when somebody's made the move and there's often a first-mover advantage. So, inertia is quite a tricky one to play safely. If you've got it, you've got to be mindful of the fact that if concept suitability, technology, and attitude is there, somebody's going to break through.

Charles Humble: Right. 

Simon Wardley: Does that make sense?

Charles Humble: It does. Yeah. It absolutely does.

Recommended talk: The Art of Strategy • Erik Schoen • GOTO 2020

Strategic Gameplay

Charles Humble: We're sort of hinting around the whole bit of gameplay, but we haven't kind of made that explicit. So, maybe we should. So, can you talk a little bit about gameplay and how to use that and how that sort of fits in?

Simon Wardley: Gosh. Right. So, when you've got a map, I mean, I said pre-mortem, post-mortem is how I learn patterns. Well, there's three basic types of patterns. There's climatic patterns—These are the rules of the game. So, these are things which are going to happen regardless of what you do, because they're driven by supply and demand competition. So, unless you can get rid of supply and demand competition by creating a monopoly, for example, it's going to happen. So, these are things like “Things will evolve”. “You will have inertia to change”. “Efficiency enables more innovation”. “As underlying components become more of a utility, we can more rapidly build higher-order systems”. Now, that's useful for actual anticipation. So, if you've got a map, you can apply those patterns to a map and you can see potentially where things are going to change. It gives you options to look at and that's useful for things like investment, etc., right?

The next set of patterns are known as doctrine. These are a collection of principles, universally useful principles as far as I can tell. So, these are things like “focus on user needs”, “understand the supply chain”, “understand how evolved the components are, so know the details and know what is being considered, “manage inertia”. I mean, when you read them, there's 40 of them. They're pretty basic, obvious things, but most companies are quite poor at those. And they come from mapping and looking at different maps. So, then the last set of patterns are context-specific gameplays and there's well over 100 of those. And I say context-specific because they work in some places, the map, not others. And they alter the pattern. So, a great example of this would be open source. If you want to take something and quickly drive it to a commodity as fast as possible, the best way of doing it is to open source it, reduce the barriers, and encourage others to come into play. Now, why would you do that? Because there are multiple things you can do to take advantage of commodities.

There's another gameplay called ILC—Innovate Leverage Commoditize—which there's a book by AWS, as in Amazon Web Services. I think it's the second of a book called "Reaching Cloud Velocity," well worth reading. It's got 17 pages of mapping in there. It has my ILC model in there. So, if you want to know more, go read that. But the point about this is you've got a map. You can usually manipulate things, constrain things, reduce barriers in different places. And when it comes to strategy, what you're normally doing is combining multiple strategies together. So, you're attacking a map in many different places, including sapping your opponents because you found a core part of the business. If you open source that, that'll put them in a panic while you can attack another space. So, there's lots of stuff you can do, assuming you understand the map..

Most people don't. Most people back in the world of stories, they're completely oblivious to this stuff is going on.

Charles Humble: Yes. Again, I will be honest and say it was hugely eye-opening to me coming across all the stuff. It's like everything you need to know is all suddenly set out and it's kind of astonishing. Because as you say, people don't know this. They don't think in these sorts of terms. It's very, very eye-opening. It's fascinating.

Simon Wardley: I didn't actually realize, you did so much mapping. I mean, there you are. Terrible situational awareness on my part but...

Charles Humble: Yes. Is there a direct link between doctrine and technology? How does that sort of work?

Simon Wardley: That's extremely good. So, what happens is as components evolve, their characteristics change. So, we'll go back to 2005, 2006. If you think about the supply chain or the value chain of software, a user needs an application built on some code, running on runtime, runtime running on our operating system, operating system running several more components and hardware at the bottom—there might be virtualisation in the way, right? So, the hardware in the bottom was servers as a product. And the key characteristic of servers as a product was a high MTTR, a high Mean Time To Recovery, i.e. when your server went bang, it would take weeks, if not months, to get a new server. So, you'd have to physically get a new server delivered and all the rest of it. Because it had high MTTR characteristics, a set of practices developed around that. Those practices were capacity planning, scale-up, disaster recovery tests, because if your servers went bang, you need to recover because, you know, you could be waiting for months for new services. As the service became more of a utility, so with Amazon EC2, for example, in 2006, the characteristics changed. Was it 2005, 2006?It's quite some time again now. Gosh. So, we went from high Mean Time To Recovery to low Mean Time To Recovery.

As in, I could now get new servers in seconds, not in months or weeks. And so now we could distribute systems designed for failure, chaos engines, we could do things like continuous deployment, because we're not sitting there waiting for machines to turn up. I mean, our set of practices changed. So, what happens is practices change with the change of technology. Now, some of those practices, not all of them, turn out to be universally useful. And so, as in, they're more than just applicable to one particular bit of technology. And I run these population studies every 10 years, where I look at the changing characteristics of organizations. And I use that to try and pull out these sorts of more generic patterns, which then I add to my table of doctrine, which there's 40 odd principles in there. And I call it the Wardley Doctrine because these are the best ones I've got. Somebody may provide a better list. I find that these are universally useful. And they are things like, you know, manage inertia, focus on using these, are really simple type things. But they come out of those population studies that I do. And so those population studies are based on change of characteristics, which is connected to a change of technology. So, there is a relationship. It's quite a fraught one, but it exists.

AI and the Future of Technology

Charles Humble: Right. Brilliant. Thank you. We are just about at the end of our time. So, I thought maybe let's step up a level to finish off. What are the things in technology now that are most interesting to you?

Simon Wardley: Well, it's unavoidable to talk about technology today without mentioning AI and large language models. So, future technology, the thing that interests me most is something I talked about back at Eurofu in 2006 or something like that. It's called, 2004, Spine script. So, this is future languages, which are compiled both to physical and digital form. And I think these days we call it cyber-physical, which is great. So, I think there's a massively interesting space of cyber-physical heading towards us, which makes people fairly able to stick. So, that's the thing that interests me, particularly the language is the way we code in that space despite the way it is. So, today, AI. So, AI is interesting because it's changing the toolset, the language, and the media. So, what do I mean by that? So, the language is becoming more conversational. This goes back to Nicholas Negropont's work, which was based on Yonah Freeman's ideas of basically a graphical conversational theory. So, the process of designing something is a conversation between people. And what we're starting to see is one of those people is the system like ChatGPT. So, this is where we get into co-pilots and its conversational programming.

Something I talked about back in 2017, 2018, a friend of mine, Alexander Simvich, built one of these, the first ever systems or one of the first systems, presented it at re:invent 2018. Now, you're seeing it all over the place with things like code language. So, the language is changing. It's becoming much more conversational, less declarative. The toolsets are changing. So, much more. They're built upon this prompt engineering. It's that environment and the medium is changing. So, we're moving from large language models to large multimodal models. So, it's not so much code as text as symbolic instructions. You've now got code and images and all the rest of it could be, you know, your code could be text or images and we’re changing the media. Now, why that matters is because that's how we reason around the world around us. Tools, language, and medium. So, to give you an analogy, tools would be the printing press, language would be the written word, and the medium would be paper. Now, if you allow control of that into the hands of a small group of individuals, they will literally control the way you reason about the world around you, which is terrifying. It'd be like somebody owning the printing press paper and the written word. You know, you're Charles Darwin coming along saying, "I've got this new idea for how species adapt. I'm going to call it evolution." They go, "No, you can't have that word."

"Well, I thought I'd write a paper." "Not on our paper, you won't." "I'm going to publish it." "Not with our presses you won't." I mean, you control, you hand over control to a small group, which is terrifying, which is why open source is so incredibly important in this space. But I saw the OSI definition of open source, it's not enough. I mean, it's got to be all the symbolic instructions and that includes the training data as well because they are symbols that change the behavior of the system. So, you know, that's the hot topic at the moment for me, is the fact that we're walking into this wonderful world of basically handing control of reasoning, our government seems to be handing control of reasoning to... Except for the Chinese, the Chinese are always on the ball with this stuff. But we seem to be handing the ability to reason to a small group of individuals. Our government should be coming out strongly in support of open-source AI. And that's not just the code and the models. That's all the way down to the training data. And I mean, there should be huge pressure towards that. Of course, it means people might make a little less money. But you know, we're a society here. And the rich are rich enough.

Charles Humble: You said that. What it makes me think of, there's a linguistic theory, linguistic relativity, sometimes inaccurately called the Sapir-Whorf hypothesis, which always annoys me because there is no Sapir-Whorf hypothesis. But linguistic relativity is this idea that essentially what you are able to think is controlled or dictated by the language that you speak.

Simon Wardley: The language, the tools, the media.

Charles Humble: It's really interesting. I think it's a fascinating moment. I also feel like we're handing an awful lot of reasoning to a tool which doesn't, as far as I can tell, reason. Which is whole nother…

Simon Wardley: I also mapped out the education system, unfortunately, you know, with a whole bunch of professors of education is terrifying. I mean, the things we need to invest in right at the top of the list are things like critical thinking, which we don't even. You know, it should be like maths, English, critical thinking, it should be on that sort of level. We're not doing and so we're throwing people into this world of misinformation, systems which are trying to reason for them, control with beliefs which you don't know, with values embedded in them which you may not be aware of. We desperately need to teach people more critical thinking. It's a bit like healthcare. We desperately need to turn our healthcare system into an actual healthcare system measuring patient-reported outcome measures rather than a sick care system, which it is, which is just treating, you know, clinician-reported outcomes. So, much we need to do. But this one, you know, if we lose the power of reason, we're done for

Charles Humble: That's a bit disturbing. Simon, thank you so much, I would love to to chat to you for hours but thank you so much.

Simon Wardley: It's been a pleasure and delight. And thank you so much.

Tools mentioned:

Mapkeep

Miro

Resources

Learn Wardley Mapping
The Art of War

Reaching Cloud Velocity: A Leader's Guide to Success in the AWS Cloud