Understanding your economic and technology landscape with Wardley Mapping

In this episode of The Digital Lighthouse, host Zoe Cunningham is joined by Simon Wardley, owner of Swardley Maps, to share how business leaders can better navigate digital transformation through visual mapping techniques.

Discover:

• How Wardley Mapping evolved from addressing a CEO’s need for strategic clarity to becoming a powerful framework for organisational decision-making
• The fundamental principles of creating Wardley Maps
• How to use mapping to identify hidden organisational blindspots and challenge embedded historical practices
• Why the future of AI and mapping tools requires balancing automation with human agency and decision-making control

If you enjoyed this episode, please subscribe so you don’t miss an episode. We would also appreciate a few moments of your time to rate and review on Apple Podcasts and Spotify; we value all feedback from our listeners to deliver the best content and experience.

Listen here:

Watch here:

Episode Highlights:

• [08:32] – How to build a Wardley Map
• [15:43] – Defusing office politics
• [24:38] – Understanding moldable development
• [33:35] – The future of mapping with AI

About our guests

Transcript

[Zoe Cunningham] (0:04 – 1:54)

Hello and welcome to the Digital Lighthouse, where we get inspiration from tech leaders to help us navigate the exciting and ever-evolving world of digital transformation. We believe that meaningful conversations can illuminate the path forward, helping us harness the power of technology for innovation, scalability and sustainability. 

Today I’m absolutely delighted to welcome Simon Wardley. Simon is a renowned strategist, researcher and creator of Wardley Mapping, a revolutionary framework that helps organisations gain situational awareness, anticipate change and make better strategic decisions. Over the past two decades, Simon has advised governments, Fortune 500 companies and some of the world’s most complex organisations on navigating competitive landscapes and driving large-scale digital transformation. Simon is currently the owner of Wardley Maps Ltd, providing high-level guidance on strategy, mapping and gameplay.

He’s also a fellow at Open Forum Europe, a thought leader at Fink and a former advisor at DXC Technology and Mozilla. His groundbreaking work in mapping has reshaped how leaders approach innovation, cloud strategy, open source and the future of software engineering. 

In this episode, we’ll be exploring the power of Wardley Mapping as a tool for navigating digital transformation, how leaders can build greater situational awareness in fast-changing environments and why understanding evolution is critical to scaling innovation and resilience.

We’ll also discuss the future of open source, mouldable development and how organisations can anticipate disruption and turn it into opportunity. I mean, hopefully, if we have time to cover everything, because there’s so much to talk about. But Simon, welcome to the Digital Lighthouse.

[Simon Wardley] (1:54 – 2:13)

Oh, thank you so much for inviting me. And I’ve got to say, what a fabulous introduction. I totally don’t recognise myself being British.

I’m just like, you know, I’m just this guy who does this mapping stuff. That’s all. But, you know, hopefully I won’t now crash and burn.

[Zoe] (2:15 – 2:44)

Well, tell us a bit, because I think that actually one of the challenges in life is the older you get, your accomplishments kind of accumulate and people think they happened all at once. But perhaps you could explain a bit about your journey to getting to where you are now and pioneering Wardley Mapping through to advising governments and Fortune 500s and obviously advising open source communities like Mozilla. So how’s that journey gone for you?

[Simon] (2:44 – 6:11)

Gosh, that’s an awful lot of questions to unpack there. So I suppose I better start at the beginning. And the beginning was a company called Fotango Online Photo Service.

We had about 16 different lines of business. We’re very profitable, but we had a problem. And the problem was our CEO was completely clueless.

They were just making stuff up as they went along. They had no idea what they were doing, you know, how to set the direction of the company, none of this stuff. They had no strategy at all.

And I know this because I was the CEO. I used to come up with these wonderful vision statements and everything else, but mostly they were just copied from other companies. And I just changed a few words.

And I was never ever concerned somebody would rumble that I had no idea what I was doing. And so I used to read every book I could find on strategy. And I was sort of getting nowhere.

And I ended up in a bookshop in Charing Cross. And I was talking to the bookseller and explaining how I’d read all these books and blah. And she asked me, had I ever read Sun Tzu’s  The Art of War?

And I hadn’t. And so she persuaded me, because she was a great bookseller, to buy two different versions of the book because they’re all translations. And I’m really, really grateful for this because it was in the reading of the second version that I noticed a particular pattern.

So Sun Tzu talked about five factors that mattered in competition. One, have a purpose, a moral imperative to do something. Two, understand your landscape, the space you’re competing in.

Three, understand the climatic patterns, the heavens, how the landscape is changing. Then you get into doctrine. So these are principles of organisation.

And finally, you get into gameplay. And at the same time, I came across this work by the mad major, John Boyd, which was called UDA. And the UDA stands for Ode to Observe the Environment.

That’s landscape and climatic patterns. Orient yourself around this space. That’s what basically doctrine and principles of organisation are about.

And decide where you’re going to act and act. And that’s what leadership and gameplay is about. So these overlap really nicely.

And I realised that my problem was I didn’t have a way of understanding the landscape that I competed in. Now, I sort of assumed back then that this was the secret sauce that you learned when you did an MBA or something like that, because, you know, I’m a cheapskate and I never did an MBA or whatever. These days, I get invited to teach on MBA programmes about mapping because though I was convinced everybody else obviously had a fantastic way of doing the landscape, it turns out that people weren’t looking at this problem.

So I ended up creating my sort of cheap and cheerful way of doing it. And because I come from an open source background, I made it sort of open source expecting maybe a few other people in my position who hadn’t done MBAs, hadn’t been taught the right way, might find it useful. And then it grew from there. And was it by design and plan and everything else?

No, as with all things, it was a complete set of accidents. It started out with a need, a need for me trying to understand what the hell it is I was supposed to be doing, rather than just faking it all the time. And that is how mapping originated.

And since then, it’s just grown.

[Zoe] (6:11 – 6:26)

Well, I was going to say, because you say, and since then it’s just grown, I think that one of the things we find sometimes, isn’t it, when we identify our own need and solve for our own need, we find that other humans actually have very similar needs.

[Simon] (6:26 – 7:18)

Yes. That was a shock. Because I sort of assumed everybody else knew what they were doing.

And it was just me. I just thought I was, you know, imposter syndrome. I’m the only faker in the room.

I didn’t realise I was in a room with a whole bunch of other fakers as well. I mean, we often pretend that we know what we’re doing. I used to come up with these wonderful vision statements, which in my heart I knew were based upon nothing at all, mostly because I’d copied them from other companies and changed a few words.

And it took a time to realise that we actually compete over multiple landscapes. One is territorial, which we are good at. We understand geographical maps, but we also compete over economic, technological, social and political.

So there’s four other landscapes that we compete in. And what I realised is I didn’t have maps for them.

[Zoe] (7:19 – 7:49)

Right. So I would really love to bring it onto a more practical footing, because I think that, you know, we’d all love to have a map. We’d love to have a solution.

But could you maybe give me an example of how an organisation, because there’s so many organisations who are accelerating digital transformation, and like you say, don’t necessarily know exactly where they’re going. So how could a leader use Wardley Mapping to help them avoid kind of blind spots? Oh, gosh.

[Simon] (7:49 – 10:40)

Well, you come up with the best questions. OK, well, first of all, we better describe, because at the moment these sound like mysterious, magical objects, what a Wardley Map is. So a Wardley <ap very simply starts with you identifying who are the users.

And so those users could be your business, your customers, regulators for something. It could be something you’re producing. It could be an industry or whatever it happens to be.

So you start off by thinking about who are the users and then you start thinking about what are their needs. So the business has a need to make profit. The users, if it’s a tea shop, let’s say, because I love using the tea shop example, which is also giving me a good excuse to look at my cup of tea.

[Zoe] (8:33 – 8:35)

And another universal human need, right? 

[Simon] (8:35 – 10:40)

Another universal. Well, it should be. It should be. The world would be a lot better. But yeah, anyway, so if we start from the point of view of, you know, I’m running a tea shop, I’m business, I want to make profit.

So I have a need to sell cups of tea. The consumer hopefully has a need to drink tea. OK, so there’s regulators as well.

We want to make sure that my tea isn’t killing people. So they have needs. But we’ll just ignore those. We’ll just stick with the users and the business. And so you have this and then you say, well, what does a cup of tea need? It needs a cup.

It needs tea. It needs hot water. What does hot water need? It needs a kettle and it needs cold water. And what does a kettle need? It needs power.

So what you’ve now got is an anchor at the top, which are the user needs and the users. And now a chain of components, what we call a value chain with inside the boundaries of an organisation or a supply chain if we’re crossing multiple organisational boundaries. So now what we’ve got is anchor and position in a supply chain.

And by position, I mean the further I get away from the cup of tea, the less visible it is. So the more jumps I have to go to get to something. So like power is essential, but it’s quite far removed from the cup of tea.

From a user perspective, rarely users go, what power did you use to make my cup of tea? Now that’s only part of what you need. You see, that gives you what we call a graph.

And graphs are very, very useful, but almost everything we have in business we call a map. That we call a map is in fact a graph. So my maps, business process maps, they’re all graphs.

And to understand the distinction, if I take three locations, Nottingham, London, Dover, put them on a piece of paper and draw lines between them. So I’ve got three nodes and three lines. And if I rotate it by 90 degrees, does it change its meaning?

Well, in a graph, it doesn’t. In a map, it does. So a map has very specific characteristics, which is the space has meaning.

[Zoe] (10:40 – 10:47)

I just thought of a question, but I think you’ve answered it. I was just suddenly wondering, is the London Cheat Map a map or a graph?

[Simon] (10:47 – 14:21)

But I think it is a map, based on your definition. We’ll get to that one, because that’s a fabulous one. So to turn, the distinction between a map and a graph is the space itself as meaning.

It’s not blank. And so the way you do that, in my form of maps, is you start with the user, you create the chain of components, and then you ask yourself how evolved are the components? And that creates a map.

And the way you treat, for example, a custom-built kettle is very much different from a commodity kettle. So the key about evolution, which is the only access on a map, is that there are four different stages. Genesis of novel and new items, custom-built examples, products, and then commodity utility services.

Now, what you’re doing is you’re looking at the space of possible options. And what I’m doing on a map is expressing how I think a tea shop should be built. Now, the interesting thing about this is it’s a medium which enables other people to easily challenge.

So if I put kettle in custom-built, and if you ever see my examples of the tea shop, I always put kettle in custom-built, because people will go, why have you got a custom-built kettle? Why aren’t you using a commodity? And that’s the point, is to encourage challenge.

The biggest problem that we have in business is that businesses are mostly run on the basis of stories. And we tell everyone that great leaders are great storytellers, which means when I challenge your story, I’m saying you’re not a great leader. And so people get very defensive very quickly.

If you get them to express the story in a map, then I can challenge the map by saying, I think the map is wrong. And so what we see when we use these maps within business is people actually thinking about the economic and technological landscape they are competing in, because they’ve got a map, but also working together without the normal politics, because we’re fighting over whether the map is wrong or right, not whether the individual. And this actually brings us together very quickly.

And you’ll often find, I’ll be sitting in a meeting, we’re mapping it out, and the knowledge we need is in everybody’s head. And the map helps us to get this down. And somebody in the room, they might be junior or whatever, they might be senior or whatever, there’ll just be somebody who knows something which nobody else in the room has realised.

And it comes up in the map, and that makes you go, “kaboom!”. An example from government mapping out Her Majesty’s Court’s tribunal service, we’re starting off with, you know, thinking about the judiciary, we’re thinking about, you know, the public, we’re thinking about government needs, and the map is there. And somebody in the room goes, shouldn’t we have prisoners on the map?

Because, and as a result of that, and adding that chain, we discovered there was an educational programme in one prison, which reduced reoffending rates. But no one knew about this. No one was measured on this, but this came out of that process.

So to cut a long story short, the benefit of doing it in business is A, it provides an ability for everybody to express their ideas in a fairly safe environment, because we’re sticking with the map, not the story form. And secondly, it helps us focus on the actual landscape itself and how things are changing. So those are the two mechanisms, why it brings benefit to organisation.

I hope that made sense. Now, do you want me to tackle the underground map?

[Zoe] (14:21 – 15:15)

Well, there’s so much. So what I love about this, and I think one of the reasons why the concept of orderly mapping has been so applicable, is that there’s so much depth to it. And it’s very much, I can see it as this kind of visual representation, where it’s almost like you can zoom in, you can always zoom in and map something in more detail, or you can zoom out and say, we’re going to take that bit as read.

Something I’d like to discuss, which you mentioned early on as one of the landscapes is doctrine. And I feel that that also perhaps links a little bit to how we discuss things and what people accept. And I think that, you know, you’ve mentioned it as a foundation, and it’s often overlooked.

So which are the doctrines that are neglected, and what are the hidden costs of ignoring them?

[Simon] (15:16 – 15:47)

You do ask the best questions. This is great. So when it came to mapping, I started mapping out environments.

And one of the things I used to do, ha used to do, I still do. Remember, I’ve been mapping for 20 years. So one of the things I do is what we call pre-mortem, post-mortem.

So before we take on a problem, we try and map it. And we use that to challenge what we’re doing. So we think about the users, we think about the chain of components, how evolved, and then we challenge our assumptions about what we’re doing.

[Zoe] (15:47 – 15:50)

Just to clarify, you’re saying you map what you’re doing right now?

[Simon] (15:50 – 16:46)

Yeah. If I’m going to build something, I map books. If I’m going to build something, I’m going to start by first, let’s map the problem space out.

And then we’ll use the map to get an agreement about what we’re going to do. Then we’ll go and do it. And afterwards, post-mortem, we’ll use the maps to look at what happened, and what did the map say.

Now, it’s from that process of pre-mortem challenge, post-mortem learning, that we pick up patterns. And there are three basic types of patterns. The climatic patterns, these are like the rules of the game.

So these are the things that will happen on a map. Things will evolve, for example, they move across if there’s supply and demand competition. They will happen regardless of what you do.

If there’s competition, things are going to evolve. There’s about 30 of those. Then you’ve got the sort of gameplay patterns.

These are context-specific, so things like open source, depends on where you are in the landscape. There’s over 150 of those.

[Zoe] (16:46 – 16:55)

And they’re your choices, right? So the climate is kind of the background, and the gameplay, they’re your choices within it, yeah?

[Simon] (16:55 – 18:36)

Almost. So they’re how you manipulate the space. It’s like a game of chess, except for the board is constantly moving, and pieces themselves move due to these rules.

And you’re right, it’s the decisions you make, the way you manipulate the space to your favour. So you’ve got two basic forms. Climatic patterns that you can’t, there’s nothing you can do, they’re going to happen, things will evolve.

And there’s about 30 of those. And then the gameplay, things you can decide to do, but they’re context-specific. Asin, certain plays are really good when something’s in the genesis, custom-built phase.

Others are really good when it’s in commodity. Now there’s a third set of patterns, and these patterns are called doctrinal. And they’re principles, and they’re universally useful.

You have choice, you don’t have to do them, but they turn out to be useful everywhere. And there’s 40 of them. And this has come through this process of pre-mortem, post-mortem learning.

And I’ve sneaked in a couple already. The first one I sneaked in is challenge assumptions. Turns out that’s a really good thing to do, but in order to challenge assumptions, you’ve got to have, second one, a common language.

So we’ve got to have a way of talking to each other, and a safe way of challenge. Now that common language has got to have an understanding of the landscape. So third one is know who your users are.

Then fourth one, understand their needs. And then fifth one, know the details, i.e. the supply chain itself. And the sixth one, we’re already up to six basic principles or mental models.

Understand the details, how evolved something is. And so there’s, as I said, there’s about 40 of those.

[Zoe] (18:36 – 19:04)

Well, can I ask a question? Because they make sense to me, and from an intellectual standpoint, I can see how we need these things. How would you use them within a conversation about a map?

Is the idea that you kind of have them visible somewhere to remind you, and then when someone breaks one of them, you can kind of say, oh, hold on, hold on, doctrine number 23. Let’s just revisit what you said. Is that the kind of use case for them?

[Simon] (19:04 – 22:02)

If you do the maps, they’ll give you at least, well, we have them broken down into different, I have them broken down into different phases. And if you do a map, you get most of the phase one. So these are things like challenging assumptions, having a common language, understand your users, user needs, all that sort of stuff.

And give you a practical example, I’ll go back to 2011. Insurance company. It’s a bit of a technical example. A lot of my stuff is nation state stuff, but we’ll do this one.

So they had a problem, which in this insurance company, is they were getting, they were growing, but they had trouble getting as much computing to their data centres as they needed. Okay. So it’s about service.

And so they had this wonderful business process map with the flow on it. They’d go and order a server, server would come into goods in, they’d mount it, modify, rack it, blah, blah, blah. And anyway, there was a big bottleneck.

So they’re very good at their value stream stuff. After they were solving their bottleneck and they come up with a plan to do robotics, they built an entire business case, they had all the ROI calculations, the whole lot, you know, big thick document, all the vendors, real group of smart people spent six months on it, how to use robots. And I was asked to have a look at this. So, you know, they’ve already got their narrative and story.

So I turn up and of course they’re like, doesn’t know anything about what we’re doing. All right. That’s a given.

So I said, well, do you mind if we spend a bit of time, quickly try and map it? And, you know, there was hostility as usual, but about after 15 minutes of arguing, they agreed they would spend a bit of time mapping. So we spent 15 minutes mapping.

And so they had computing product, they had the user needs above computing product and they had goods in, in commodity and servers in commodity, even the computer, it’s okay, fine. And power connected in commodity. Great.

And then they had modify map, mount and rack, and they had racking custom bill. Now I was able to look at the map and of course challenged the map. I said, I think there’s something wrong with the map.

Well, why have we got racking custom bill? And somebody said, no, it’s right. We have custom built racks.

So what are the modifications you’re, you’re making to the servers? Oh, well, the servers, they don’t fit our racks. So we have to take cases off, drill new holes, add new plates in order.

That’s why you need robotics. Yes. And then somebody in the room went, why aren’t we using standard racks?

And suddenly millions and millions of pound of robotic investment just went, puff, we’re in a smoke. Now these people weren’t stupid and daft. These people had been tracked by narrative because at some point in the past, there was no such thing as standard racks.

So they had custom built racks. And so this had been come embedded in their processes and ways of working. And at no point have they challenged this.

And so this happens quite a bit, is your map out. I’ve got so many stories, which just make you go, no, they weren’t. Do you want another?

[Zoe] (22:02 – 22:35)

Well, I actually, I know, and I would love to hear them all. We might have to make this into the series because there’s so much to discuss, but I want to move on and talk about another concept, which I promised in the introduction. So you’re a proponent of mouldable development.

So, and you’ve called this the most, one of the most exciting shifts in software engineering. So I’m particularly thrilled to discuss it. So how do you see mouldable development transforming how organisations build and evolve software systems and what kind of new opportunities does that lead to?

[Simon] (22:36 – 24:47)

Oh gosh, gosh, that’s such a huge question. But we better get to the heart of, we better get to the heart of what mouldable development is really all about. So I suppose the way to do this is start in the physical world and then we’ll translate to the digital.

So in the physical world, we have tools. If I’m making soup, I’m in my kitchen because I love making soup, I’m using a blender. So now if I’m building a deep shaft mine, I’m not going to try and do that with a blender.

I’m going to use, that would be pretty daft to sit there trying to build a mine with a blender. I’m going to use some other tools. So now let’s go to the software world.

In the software world, where we’ve got highly contextual problems, all written in symbolic instructions, we have highly standardised tools. So we have our kitchen blenders, you know, you go into most organisations, it doesn’t matter it’s a healthcare system, the development tools they’re using, exactly the same as the development tools we’re using when we’re building, I don’t know, an online gambling site. Hang on, these are contextually utterly different problems and we’re trying to build them with the same tools, except for in one place.

One place we’ve clocked this, which is tests. So we start off with a problem and we write a test for the problem, either before or after the code. So before the code, we call test-driven development, after we call, whoops, or whatever.

So, but nonetheless, it’s good to write the test. Those tests have input output, they transform something, they are basically small tools, really small tools. And we build them for the context.

If I’m writing an application and somebody says, oh, I’ve just bought 100,000 Acme test suite for our application. I’m going to look at them going, what on earth are you talking about? But we do this with tools as in other tools, our development tools and our development experience.

It’s not contextual, it doesn’t change to the context. And the reason why we do this is because we’re told by tool vendors that it’s really hard to do and build tools. But there’s a conflict of interest there.

[Zoe] (24:48 – 25:04)

Just give me an example of what you mean by a tool, because I think for me, I’ve not quite understood because I see as tests as something you build using tools and software as something you build using tools. So I think I’m missing a distinction.

[Simon] (25:05 – 27:42)

Tests are tools that run on your software and very small tools. And we build them with a toolkit. In the same way, if we’ve got a software system and we’ve got tools like small tests, we really need a toolkit to build the tools for that software problem because every single software problem is highly contextual.

And so that’s what mouldable development, it’s a bit like test-driven development. We’re going to start by first building the tools to solve the problem. And then we’re going to use the tools to solve the problem.

And to give you an example, there’s a small company called Think and they have Glamorous Toolkit. And Glamorous Toolkit is really interesting because it’s a toolkit for building tools, but within itself, it contains tools. And there’s over 5,000 tools built by the six people by Glamorous Toolkit.

And you go, how can you cope with that? Because whenever you’re dealing with a problem, the tools which are relevant to that context, and that’s the trick, come towards you. It’s a bit like being on the internet.

When you go to the internet, you don’t get suddenly hit by a billion pages. There are a billion pages out, but it’s much more contextual and the same patterns with tools. And so an example, they had a particular company who had a problem, which was this legacy environment written in a dead language, as in the people who developed the language were dead.

The developers were actually dead. It was all dead, but it was critical core to this billion dollar business. And everyone was terrified of it.

And they needed a way of understanding what the hell it was actually doing. And then had multiple large scale efforts over years and completely failed. And so they asked the group of Think to come and have a look at this.

And so they gave them all the code and everything they could hand to them. And they had another meeting with them about a month later. And that meeting, the client thought it was a meeting about what more information they were going to need.

They’d actually had an internal bet, that this group would fail after a year. And so they said, how are you going? And they said, we’re finished.

And they were like, how is this possible? Well, they spent the first three weeks building the tools to understand the problem. And then they spent the last week actually fixing the problems.

And so that’s the distinction. I mean, they built a large number of tools for the problem. And this is why we see a really increased speed of development, or particularly when we think about a problem space, because we start by building the tools to the context.

And that’s it.

[Zoe] (27:42 – 27:58)

Yeah. Can I just ask another clarifying question? So what differentiates a tool from a component?

Is it that the tool does not form part of the final solution? It’s something that was used to make a component and then discarded. Is that the difference?

[Simon] (27:58 – 30:10)

So most of the stuff that we’re doing, you can use things that there is that approach of doing multiple developments as well. A lot of the stuff we do is about understanding systems, because most of the problems that people have at the moment is legacy migrations, all these sorts of things. They’ve got something and they often don’t actually understand their environment.

They had loads of architectural diagrams, but architectural diagrams are paintings. They they’re somebody’s belief of how a system is. They’ve rarely generated from the system.

And so we often find there’s missing things all over. So the tools themselves are things that you build to understand the space. And once you understand the space, then you may go on to build components, which are the solution itself.

Or it may turn out that your entire tool that you’re actually building becomes the component itself. But the first thing to do is to understand the environment, because when we think about what is software engineering, fundamentally, it’s a process of decision making, making choices, and of understanding the landscape. And so that’s what mouldable development fits into.

It’s a bit like mapping. When I first did mapping in 2005, people were like, well, what are you going on about? And I was saying, yeah, you’ve got to understand.

It takes a little bit of time and practice. You know, you use it a few times, and then suddenly it starts to, oh, my God. So the best hooks I can give to people is if you think about tools, test as tools, we build very contextual tests for the problem.

And we use toolkits to build those tests or tools themselves are highly contextual. Why aren’t we building? So if you think about the analogy of the sort of like blender, in the software world, we do use blenders to try and build deep shaft mines.

And then we compare with AI, which is like saying these robots are better at building deep shaft mines with blenders than we are. Great. Well, why don’t we actually try and build a deep shaft mine with some proper tools designed not for making soup?

And that’s your issue with the tool set. They’re all designed for solving somebody else’s problem, not your problem.

[Zoe] (30:10 – 30:53)

Yes, I can definitely see that there is a lot more to explore. And unfortunately, because of time, we are going to have to move on. Because I really want to talk about the future.

So I think that we’re in a very fast moving landscape at the moment. And I want to just ask a bit about as more organisations adopt Wardley Mapping and strategy tooling, how do you envisage the role of mapping evolving? So could we see a future where AI augmented real time strategic maps guide decisions across industry?

Based on our discussion so far, like we’ll see. So but what excites you about where the practise could go next?

[Simon] (30:53 – 33:28)

Oh, first of all, I know, AI, I find incredibly useful tool. First of all, AI is not a tool, it’s a broad field. And within that, there are many, many different components.

I’ve been doing these various things around machine learning for quite a long time. So and particularly around the ideas of conversational programming, which is what I talked about back in 2018. And nowadays, we call vibes chop.

And so I do. Last night, I was finding a little software game. So there we are.

Great fun. So the interest about in terms of AI with maps, I suppose this all goes back to Yonah Freeman, and Nicholas Negroponte. So a particular paper called architecture by yourself.

The process of design is a conversation that occurs between the heads of multiple designers. And what’s happening is the machine is one of the designers. So you’re having conversations with the machine to design something.

And that is going to happen with the mapping space as well. We’re going to have conversations with the machine to help us create an understanding of the space. And that is exciting.

But again, it’s a decision making process. So the thing about decision making, that depends on questions I ask and answers I get back. And those answers have various properties, one of which is like, it’s got to be explainable for understanding.

And one of the problems that we’ve got at the moment with AI is they’re not explainable. So they are great, but you’ve got to build some mechanisms of how did we get to this sort of understanding? Because I can certainly use them to generate maps, but then I look at the maps and it’s just like, whoa, there’s an awful lot wrong with it.

But as a starting point, it’s good. So do I see a positive future in combination with humans? Yes.

Unfortunately, there will be those who think because you can get very excited by the serotonin hit of it building an application or whatever. We’re going to get loads of people saying, oh, we can just replace software engineers and other things with AI. They did this with cloud, with sysadmins, and then suddenly realised their estate expanded and they had to hire them back at much inflated prices as DevOps engineers.

Perfectly normal. We’re going to make the same mistake because we’re going to realise that we don’t want to be the Eloi to some AI Morlock. We still want to have some sort of control in a decision making process, which requires some understanding.

And so whilst they are a useful tool, they don’t help us understand the space.

[Zoe] (33:28 – 33:48)

Yes. I mean, to go back even a little bit further, I’m always reminded of the machine that goes ping in Monty Python and actually this kind of this human ability to try and give power and our agency as people over to machines, I think, is something we’ve seen happening for a long time.

[Simon] (33:48 – 33:53)

That’s a terrifying one because you’ve got EM Forster’s, The Machine Stops back in 1909 or whatever, 1906, a real threatening sort of dystopian future. The reason why I say it’s terrifying is because what’s happening in the AI space is our language is changing from declarative to much more conversational. Our tools are changing.

So the existing development environment, we’re using things like, I don’t know, ChatGPT or copilots, for example. Our medium is changing. So we’re going away from coders text to coders images.

So you’re using for GenAI a seed image. And so the interesting thing about that is language, tools and medium are how we reason around the world around us. So if you think of, go back in time, printed press as the tool, paper as the medium, language was written word.

Now imagine one group had control of all three of those. They would control how you reasoned. So for example, if you pick any group you don’t like from history, we’ll say some sort of fundamentalist group and, you know, we’ll be Darwin with evolution.

I want to have a new word evolution. No, you can’t have that. We control which words can be written.

I would like to write a paper. No, you can’t use paper. I’d like to this. No, we can’t distribute. 

You are creating a new theocracy, a terrifying new theocracy, unless control over those three things is much more distributed, which is why the only way to challenge is diversity, openness, which is where we get into the sort of open source area and critical thinking. And unfortunately, whilst I applaud the great work being done by like China with its open source efforts and France, because they’re very clear they’re going down that path and people like the Paul Allen Institute in the US down that path as well.

A lot of it is, is about creating a new theocracy, a new feudalism, which terrifies me, but there we are. I still love tools for building stuff, but I’m aware of the dangers.

[Zoe] (33:53 – 33:17)

On that bombshell, we are out of time. And all I can say is thank you so much, Simon. I feel we’ve scratched the surface of so many topics that could be discussed more deeply, but thank you so much for coming and sharing your insights and enthusiasm with me and everyone else.

Thank you so much for listening and see you next time.