Transcript
Hastie: This is Shane Hastie for the InfoQ Engineering Culture podcast.
I have the privilege and pleasure of sitting down with Simon Wardley, across the miles, we are on opposite sides of the globe and in the midst of the COVID chaos. Simon, thank you so much for taking the time to talk to us today.
Wardley: It's an absolute pleasure. And thank you for inviting me and also for staying up so late, as well. It’s very much appreciated.
Hastie: My absolute pleasure. Some of our audience will be aware of you and aware of Wardley maps for which you are quite well known now, but I suspect some haven't come across you and your work yet.
Introduction
Could you give us a very brief background and introduction?
Wardley: Certainly. First of all, I'm delighted that you say that, many will have come across my work because I believe it's still incredibly rare. And a little bit of background to myself. I used to be the CEO of a software company.
We were doing very well, attended different lines of business, we'd been bought by Cannon, but despite the fact we are doing very well, very profitable, the business did have a problem, and that problem was me: I didn't have a clue what I was doing. I was making it up as I went along. I was the fake CEO, about as fake as you could get. I was worried people would rumble that I was making it all up. I started looking into the whole issue of strategy, trying to get a better way of understanding it, and I actually started by going around, recording other CEOs talking about strategy and recording; you know, taking these recordings and taking out the common words.
I was always looking for secrets of success. And I called these common-word blahs or business level abstractions of a healthy strategy. It was hilarious, it was always the same: digital business, ecosystem, efficiency, open source, all that sort of stuff. And then I created something called the blah template. Our strategy is blah, we will lead a blah effort of the market through our use of blah and blah to build a blah. To which I then just inserted those random words into.
A friend of mine started to put this all online now. It's actually a service. If you ever need a strategy, go there and it would just generate you some gibberish for you. And I said these random people would come back with comments like: “Oh, that’s our business plan”, and it was just like desperate.
I didn't know what I was doing. And so I went into a bookseller, and bought a whole bunch of books on strategy and got nowhere. And then the next time the bookseller said, “Well, have you read Sun Tzu, The Art of War?” And I went “No”, and he said, “Well, you need to buy two copies”, obviously a canny, bookseller, “but they're different translations”. And I was reading the second translation, I noticed that Sun Tzu talked about five factors that mattered in competition: The first is have a purpose or moral imperative. The second is to understand your landscape that you're competing in. The third is the climactic patterns, how the landscape is changing, the principles of operation and getting play.
What struck me was the landscape bit. So, I really got into landscape and understanding about the question of situational awareness and what I realized is everything I have in business, which was called a map, business process maps, mind maps, systems maps, and things like that, all had one thing in common. None of them were actually maps. They're all graphs. And what I needed to do was somehow create a map. And, I went through the process of working out the characteristics of a map, built a map, and then I started to use it and I found it useful.
I sort of assumed everybody else in the world did this because they had all done MBAs and I'm the only CEO who'd never did an MBA , well that's in my mind. And it took about another six years for me to discover that, no, they weren't using maps and that most people were suffering, by making things up, and mapping has just grown from there and some other people, some people find it useful.
I mean, some hate it, but some people find it useful and it's just grown into a community. So that's it. That's what I did with maps.
Map Versus Graph
Hastie: What is the distinguishing characteristic of a map versus a graph?
Wardley: A fabulous question. On a graph, you'll have multiple nodes, often connected together. You see there's three graphs at the top and they're identically the same. Nottingham, London, Dover they're places in the UK. Nottingham, London, Dover, Nottingham, London, Dover connected by two roads. I mean, they're not very accurate, but they are, but those three graphs at the top are identical.
The images at the bottom they're maps and these three maps are totally different. The difference between a graph and a map is quite simply that in a map space has meaning. If you take a graph, like any of them on the top and move Dover left or right, say, or up or down, but keep the connections the same, their context doesn't change, the meaning doesn't change, they remain identical. Whereas, the ones at the bottom, if you take any one of those and move Dover a little bit, you change the context and the meaning of the map. And, this is why maps are good for exploring space.
Almost everything you see in business, we call a map, like mind maps. I'm not knocking the tools, they're still useful tools, but if you take a mind map and you move a box slightly left or right, does it change the context or meaning? No. If you take a business process map and move a box left or right does it change the context or the meaning? No. Same with a systems map.
But if you took an atlas and we take New Zealand and move it next to the UK, does that change the meaning and context? Of course it does. But that's because it's a map. So, that's the critical difference.
Basic Characteristics of a Map
Now in order for something to be a map, you need to have a couple of basic characteristics.
You've got to have points of reference or an anchor. In this case, that's like magnetic North on geographical maps. You have an anchor as in magnetic north, the point of reference. You've got to have position of pieces, relative to the anchor. In the first left-hand map, London is North of Dover, but it's also East. The last thing you've got to have on a map, you've got anchor and you've got position, relative position. You need what's known as consistency of movement. By that I mean if I go North, I'm going North, I'm not suddenly going South or not going West , there's consistency. There's no sort of like I'm going North, actually, I'm going South. It's always North is North. If you've got anchor, position and movement, and consistency of movement, then you can describe a space. And that's what gives space meaning. Does that make sense?
Process Flow
Hastie: What is the implication of this for the process map? One of the most common tools of looking at analyzing an existing business process and trying to improve it, or, maybe a value stream map because there we put numbers on the process.
Wardley: The maps that I use are all maps of capital. Each of the nodes are stocks of capital or things like that. I'm going to have to show you two things. I'll show you what a map looks like, and then I'm going to have to jump into something else. Because you've asked specifically about process flow then I better show you the issue with a process flow.
Can you see that screen got a little robot in it? This is one of the most common problems that I come across. This was a particular insurance company and they'd spent six months on this problem. They had a process flow where they would basically need compute and they would order a server and the server would come into goods-in and they would modify, mount and rack it, and that gave them the compute they needed. They had a big process flow, a bottleneck around the modification of servers into the racking of them. They'd spent six months looking at this problem and come up with the idea of investing in robotics and automating the entire process. Many, many millions, tens of millions capital investment, this was the whole plan.
Most Organizations Run Themselves on Stories
One of the things about maps is most organizations run themselves on stories and when you challenge a story, you're actually challenging the person, the storyteller. We spend a lot of time trying to persuade organizations that what makes a good leader is being a good storyteller. We often say to people, “Well, you sold the idea in the wrong way” and that just reinforces this concept, that the problem is not the story, the problem is the storyteller. When you attack a story, you're attacking the storyteller.
One of the beauties about maps is you're forcing people to put all their assumptions down in a map. I can attack a map without attacking the person, which makes it much less political. In this case, if I had gone in there and said, you know: “Why are you using robots?” it would have been a big political fight and everything else, and it's just like, “Whoa don't go there! Remember they'd spent six months working on this.”
Hastie: Yes. Somebody's invested quite significantly in coming up with this idea.
Wardley: Political capital the whole lot. Can you map it? Literally 15 minutes was spent and this is the map.
The Characteristics of a Map
I better tell you the characteristics here of a map. At the top you've got User, on any map you need points of references. We could have that user, the business, we could have government, you're going to have multiple. We did maps for the UN reducing global poverty, which goes all the way down to the national statistics organizations and the stuff they do. And of course, you've got multiple actors and multiple points of reference. The first thing you've got the point of reference and in this case, just one. As in the user needing compute.
The second thing is a chain of needs. User needs compute and that needs them to say order server, that needs a server, that needs goods in. What you've got is a chain of needs. And from the point of view of the user ordering compute the compute's more visible, I see if I've got my compute or not, whereas goods in, of course, is an essential part of the chain, but it's far removed, it's less visible. It's a metaphor for distance from further away. What you've got is a chain of needs, which gives you position and you've got anchor. Now it turns out that each of these components of capital, and it doesn't matter whether we're talking about activities, practices, data, knowledge, even ethical values, evolve through competition.
There are four common stages, that I'm aware of, and a long list of characteristics for each, but rather than stage one, two, three, and four, which is fairly meaningless, what I've done is taken the common labels for each of those stages. When we talk about activities we talk Genesis, custom built, product, commodity, utility. Just like drugs: we go from the sort of novel Genesis of a drug, like penicillin, custom-built examples, products and eventually it becomes a generic. Or compute: how we went from the Z-3, 1943, custom built examples like Leo -Lions electronic office - products and rental services, and we start with the IBM 650. We go through things like time share and then eventually more commodity and then utility, cloud. And same with electricity as well. They all evolve through that pattern. That is a way of describing movement.
It is slightly tricky with business, it's easier with geography to do, because if I want to go from London to Dover, I'm going to go South, Southeast-ish. OK, probably South-Southeast. The thing is during that journey, Dover is unlikely to move. But over a 200 million year period, when you think about Pangea and all this sort of stuff is , the continents were all different, it's unlikely to move in our life. That's why it's fairly static.
In the world of business, nuts and bolts took 2000-odd gears to go from Genesis to commodity and work with standards and things like that. Electricity took about 1400 years passed in battery to Tesla and Westinghouse. Telephone was about 80 years, computing was about 60 years. These days we're looking at 30 to 50 years to go from Genesis to more commodity.
What we're talking about is things which will change in our lifetime. It's a bit like going to Dover, but on the way to Dover, Dover's moved. In which case, you have to describe movement in terms of change and that's why you have that axis at the bottom, Genesis across.
Now what we've got is anchor position and movement. So this was 15 minutes, you know, it's taken me longer to explain it, but 15 minutes to, for them to draw and they go user, compute, order server, server, goods in.
Now argue with compute. See, I can say the map is wrong without the person. I might say compute, it's more of a utility, but they also put rack, mount and modify.
Now I can ask questions. And the first question I said was, “Why have you got rack in custom build?” To which the answer was, “They had custom built racks”, to which I was able then to say, “What are the modifications you're doing to servers?” Well, the servers they bought didn't fit their racks so they have to take cases off them, drill new holes, add new plates, and then we'll just get them to fit their racks. And that's why they needed to invest in robotics. Now, remember, they've been working on this problem for six months and you could see in the room, the penny drop. It's just like “Why are we doing this?” This is the most common problem I see, is people being trapped by context. Obviously the sensible thing is to use standard racks.
I'll come back to your process flow question. This is probably the most common thing I see and billions are wasted, enormous sums of money wasted on this. We had a UK government project, which they mapped and they reckoned they're going to save 1.5 billion. This is the most common problem that I see, is that investing in robotics is the right thing to do if you're focused on improving the process flow, but in reality, once you've mapped it, literally this is a 15 minute discussion, you realize actually that things evolved.
By following process flow, you will invest in exactly the wrong thing. What you should be using is getting rid of racks, custom to more standard. And in fact, once you've done that, you can then just basically say, well, “Why have we got compute with anyway, that should be more of a utility, we should be using cloud”.
But most organizations, because these people aren't daft, they are simply trapped by context and stories. And so that's the big difference between just doing like a value stream, because a value stream map, you would invest in robotics. Because you'd be optimizing.
Hastie: Yes. You would look at the time that it took to mount and drill and so forth. How many times we do that and I can Six-Sigma it to make it completely consistent repetition and the best way to do that is have a robot do it.
Wardley: Yes, but in this case, what you see, in literally 15 minutes discussion. I love value streams so I'm not knocking it. I think they're really, really good. But what I'm saying is, before you make that choice, that optimizing process flow, it's a really good idea to look at the actual context itself. Does that make all makes sense?
Hastie: Now we've got a lot to think about very much. What does this imply? You said you came to this when talking about strategy. What does this imply to the audience, technical influencers, technical leaders often working in that IT space, and also people moving some of these ideas outside of information technology?
Sun Tzu's Five Factors and Boyd's OODA Loop
Wardley: We'll go back to Sun Tzu's five factors and then in fact, it overlaps with Boyd's OODA loop.
First thing you need to do is observe the environment. You need to understand your landscape and how it's changed and if you can observe the landscape, you can see common patterns of change. There's about 30 common economic patterns that I'm aware of. This stuff is all creative commons, has been for 15 years. I just publish it out there.
Those patterns you can use for anticipation, by taking them, applying to a map, you can see how the map will potentially lead and at least have a discussion.
One of the beauties about maps is, and because each of the nodes are stocks of capital and each of the lines are capital flow, you can actually put financial figures in there; you're focused on the user, you're focused on what you're building and how you operate it. Certainly in my businesses, I found that people from totally different backgrounds can all talk together with a map which is quite powerful and because we can learn those patterns we can anticipate.
Then you get on to what's called doctrines. These are universally useful principles of operating, they come out of their ways of structuring things, but they're universally useful so you should do them all and there's 40. And they have ridiculously simple things like focus on your users, focus on your user leads. Remove bias and duplication, challenge assumptions. These all come out of the maps anyway. I mean, most of them, you read them and go, “Oh, well of course you should do this”, but we're pretty bad at actually doing them, partially because we keep on getting trapped by stories and context, then the whole political side.
One of those pieces of doctrine and one I've just explained is why one size never fits all. Once you get beyond that, then you get into the more strategic place. This is understanding your landscape, anticipating where it's going to go, how you can position yourself and then, more importantly, how you can exploit and manipulate the landscape. There's over a hundred different patterns for doing that, which again, most people are oblivious to. And then from out of that, and the use of scenario planning, you can determine a play and this actually is an incredibly fast process. Sounds like that's a lot of work; and where is it, in Belgrade, they do battle camps where they have basically people playing strategic games against each other with the maps I created. It can be a quick process.
I'm just going to go through one of doctrine because I like also to give a shout out to some mappers, this is what I like. It's a whole community.
HS2 - High-Speed Rail
This is HS2. High-speed rail. Big, massive, great big, heavy engineering project.
This is James Findlay, he used to be the CIO. He's moved on, he's doing all sorts of wonderful stuff saving lives elsewhere.
Anyway, so HS2, they wanted to build the railway in a virtual world because it turns out it's cheaper to dig up a virtual world and go “Whoops, we’ve got that wrong”, than it is the physical world. You don't want to dig up half the countryside of the UK and discover, “Whoops, we've put it in the wrong place”. They decided to build the whole lot in a virtual world and this particular project ended up in front of the public accounts committee being praised for being under budget and ahead of schedule, which is like a government project - wow, pretty amazing. By the way, anybody who thinks that government projects are bad compared to the private sectors, never really looked at the private sector, because, the level of waste is just obscene in the private sector. Alright, so this is the HS2 project. This was the systems diagram for the HS2 project, for building the railway in a virtual world. It has various different components with various different actors involved, and James' problem was this: he wanted, well, “What should I do with it? Should I outsource it all? Should I use off the shelf products? Should I use, build it all in house with agile techniques? Should I use a combination of those three things?” Now, given those number of components and those three questions, the number of permutations of that is about 370 million. Which is the right one? What James did was he drew a map. This is his original map, the focus at the top in terms of the users, different components, and evolve. That is what the map, tidied up it looks like. The different components anchors at the top.
One of the things you see it says Uncharted, Industrialized at the top of the screen, this is cause as things evolve their characteristics change and because of that, there's no such thing as one size fits all methods.
Extreme programming is very good on the left hand side, because what you want to do is reduce the cost of change and change is going to be the norm. In the middle, it's more Scrum and BPR of those other artifacts. So Lean, because you're focused on reducing waste and learning and on the right hand side, you're all about reducing deviation, things like Six-Sigma are the right way.
My company in 2002, we'd gone all Agile, extreme programming. Kent Beck's a friend, great stuff, 2002 probably 2001, and of course by 2003, 2004, we were finding it doesn't work everywhere and by about 2005 we'd learned you need multiple different methods. You can't use a single method, it can show you what it looks like on a map. It's pretty simple. Stuff on the right hand side you tend to outsource, if you're going to build and use Six Sigma. Stuff in the middle, you tend to use off the shelf products, lean. Stuff on the left hand side, you use agile techniques.
This was HS2 being heavy engineering. This is the stuff I was doing back in 2005, 2006.
If you go to an Agile conference and say, “Agile, doesn't fit everywhere”, you're going to get booed, hiss, heretic, the same as if you go to a Six Sigma conference and say “Six Sigma doesn't fit everywhere”, boo, hiss, heretic. And everybody would always tell you why their method applies everywhere and everybody else's does. And the honest answer is you need multiple. Does that make sense?
Hastie: Yes.
Wardley: Generally, what will happen in organizations the vendor will want you to outsource the whole lot and in the process of outsourcing you won't have a map. You'll want to get a specification document because you want to know what's being delivered. Now this is basically a con, and the reason why it's a con is the stuff on the right hand side will get efficiently treated because it can be debunked. These components we can describe and therefore can be delivered. But the project will incur massive change control costs, excessive change control costs, because the stuff on the left we cannot define; you know, we're still exploring, we're still learning. So we just tried to specify what cannot be specified. And we get paneled and of course, when we get into a fight with a vendor, the vendors point at all the stuff, which was delivered effectively.
You knew what you wanted, but all the stuff, where is all the excess cost it's cause you kept on changing your mind. And the honest answer, you couldn't help, but change your mind because there was no way you could know. The disaster is always when somebody on your side says, "Next time we need to specify it better". Fire that person, and never let them go near a project.
Hastie: The stuff on the lift is why XP, scrum, the agile methods, that's where it came from.
Agile – Lean – Six Sigma
Wardley: There is a problem I'm going to say, with Agile. I'm going to go to Elizabeth Shove and Social Practice Theory. Social practice theory, great stuff, really brilliant stuff. I'm just going to apply it to maps and then show you the problem with Agile.
It's not just activities that evolve, but practices, do we just use different terms, novel, emerging, good and best. You also have data evolve, un-modeled, divergent, convergent, modeled.
We start off collecting astronomical data. In the early days we were collecting whether the wind was blowing, whether there was leaves on the tree, as well as the lights moving in the sky, because we didn't know what's connected to what, so lots of different forms of capital evolve.
Agile and by Agile, I mean, as in Kent Beck’s extreme programming lightweight, has evolved from novel emerging, it's good practice, heading towards best, for building some new thing. Now that new thing could be teleportation, could be anything you want. But that new thing will also evolve. We start with that first ever teleportation. Let me get teleportation as a product, also teleportation booths, and eventually there's some sort of utility, or whatever.
Now, Lean, as in by that, I mean the whole approach of using Scrum, MVP and other artifacts, has evolved to become good, heading towards best practice for building a product.
And Six Sigma has evolved and it is without doubt, best practice for building something which is more on that commodity space, this is all about reducing that deviation.
Here's your problem. You've got three things which have a common meaning of project methodology, but within project methodology, you've got three separate competencies and you've got a thing which has a common meeting like teleportation and what you've got are three separate material instances. Teleportation that is something novel and new, teleportation as a product, teleportation as a utility, and each competency is good for one area. Now, if you don't see the landscape, if all you've got is meaning, so project methodologies and the thing, there's no way that you can, this is why you would naturally fall into, “Oh, there must be one method, which fits across the lot”. And what's going on a lot I see with agile, is people are attempting to co-opt the practices, which are appropriate for other material instances. They are trying to co-opt and bring it into Agile.
You get this wonderful case where now agile projects fail and people say, “Oh, you used the wrong bits of the process. You didn't use that, but you should have used those beds.” And this is what makes a mockery of it because Agile was supposed to be people over process. Now it seems to be coming process over people. It's Agile is almost becoming anti-Agile. And that is why I'm clear - when I'm talking about agile I mean Kent Beck lightweight, and I don't mean all the stuff, which is going on at the moment. Does that all make sense?
Hastie: It resonates with Ivar Jacobsen's work on method prisons.
Wardley: Oh, yes.
Hastie: He wrote an article for InfoQ where he explores the method prisons and the frameworks and, the fact that you fundamentally get locked into a method as soon as you buy into it, so to speak.
Wardley: But the thing is, that's the point about mapping, once you start to map, you start to realize we're going to use multiple methods. There is no one-size-fits-all method. All of this stuff when people say “Oh use Agile, everything can be Agile, everything can be Six Sigma, and everything can be Lean” - No. Because what you're doing is you're taking polar opposite characteristics: you've got the uncharted and the industrialized. You've got the transition, the middle, they're different characteristics and there's three.
Be very careful when people just talk about the extremes, you mustn't miss the stuff in the middle. Otherwise you'd be mad and slightly bimodal. Don't! Bad Idea. A really dreadful idea. Having implemented bimodal in my company in 2003, a good 10 years before or eight years before Gartner created the term and discovered what an utter mess it was, that's why I wrote those articles having a pop at them, about not knowing what they were talking about.
You've got to have those at least those three different considerations of characteristics. What you've learned is you need to have at least three different methods and it's the same with purchasing. There is no common purchasing framework you need at least three. Because sometimes you're talking about VC type approach, sometimes it's actually core, VC outcome, then more unit utility, a lot more COTS and then unit utility. Again, understanding your context, and it's the same with most subjects that I've come across and there is no magic one-size-fits-all as much as we want it, because that makes life simple. Understand your context, understand how to use different methods.
Hastie: So going big for a moment.
Wardley: OK.
Hastie: You mentioned you've been doing work at a global level. We're sitting in the midst of a pandemic. People making decisions. We're seeing massive changes. I'm in New Zealand. We've come through, although we're starting to see, where the border controls fail, we've got a couple of cases that have come in from overseas. How can, at a global strategy level, leaders use these tools?
Wardley: You are seeing a tiny little fraction of what mapping is. I use mapping at looking at things like nation state competition. For example, I was over at Harvard Kennedy, and they've got all these wonderful value chains, describing China's market.
Now, if you don't map it over evolution, it's very difficult to see the pattern, because China's being playing a game, and it's a fantastically skillful game, of building special economic zones aiming at industrializing space and shifting products to more commodity, and in the special economic zones, they set up, basically encouraged start-ups to play game of last man standing in the internal market before pushing them onto the outside market.
There's an awful lot of gaming and everything else that goes on, and some players are really good at it, and the people I'm thinking about in terms of commercial world is Amazon, and their play and China as a nation state government. They operate principally as the world's largest venture capital firm and they do a great job of it.
Terrible on the human rights, but then I'm from the UK and as much as we like to be pious about our human rights, we also have the entire offshore trust industry, which is disgraceful, but anyway.
I used to run strategy for a company called Ubuntu and Canonical. About 2008, we were 3% of the operating system market against Microsoft and Red Hat, and then, I mapped the landscape, I loved working there, but, I mapped the landscape. It was quite fun cause the day I turned up at Canonical some people said, “What are you here for?” I and Mark had talked about this before and I said, “I'm going to bring it to the cloud”. And it was like, “Oh, it's a fad and blah!” I used the maps to explain what was going on. We use the maps to target the market, I think it cost half a million and we spent 18 months and we went from 3% to like 70% of all cloud, we literally owned, everybody was building with Ubuntu. Were you in the industry at that time, do you remember that at all? Do you remember how it was all Red Hat, Microsoft, Red Hat, and Microsoft, suddenly cloud was Ubuntu. You were mapped! We flattened everyone. It was great fun.
Fotango
This is Fotango back in 2005. The customer, this is one of our lines of business, needs online storage, website, needs CRM, needs compute, needs power, needs a data center.
One of the things you learn is the climatic patterns, you learn that things will evolve.
We knew that runtime would go to a utility, compute would go to a utility. Another pattern you learn is inertia to change caused by preexisting capital. It's about 16 different forms of inertia, just in that one pattern alone.
The way to think of this is Netflix and Blockbuster. First with a website was Blockbuster, first with video ordering online was Blockbuster. First with video streaming experiments was Blockbuster. First to go bankrupt was Blockbuster. Blockbuster didn't go bankrupt because they lacked innovation. They out innovated everyone. They went bankrupt because of past success and their existing business model. Do you remember late fees? That's where they made most of that money and you only get that with a physical cassette. They didn't die because they lacked innovation, they went to the wall because of past success.
You learn inertia, you learn componentization, so that as things evolve, their enable higher order systems to appear, and that's Herbert Simon's theory of hierarchy, which create new sources of value and worth. And you've got one, two, three patterns. There's about 30 common economic patterns, which you can apply to a map. The point about this is now we can start to say, where are we going to invest?
In 2005, we'd already converted our own data center to a utility based on Ian Pratt, Simon Crosby, they are old college friends of mine, they work on Zen. I was suspecting Google was going to move into the space of computers and utility. This is 2005 we thought, well, runtime will go. We could build the world's first platform as a service or we can wait until somebody else does that and build something on top, or we can differentiate in terms of our existing service. These were the questions that we were faced with around the board and around my executive team in 2005 and we actually built the first serverless environment, building per function. You just wrote code, fabulous.
I expected that it was going to be Google, it was Amazon 2006, make the move with EC2, and of course, then we quit, we moved everything on to EC2 and it was growing like hot cakes. And then the parent company had a big consultancy firm come in, very expensive US consultancy, and they basically said the three things that we were doing, mobile phones as cameras, 3D printing and this cloud stuff. We hadn't even got the cloud name then, it was not the future. The future is 3D television, so you should shut it all down and spend a billion dollars on 3D TV. I don't think much of big US consultancies. I lost the political battles, so that's what the company did, spent a bucket load of money on 3D TVs. Brilliant. But there we are.
The point about this is you can see the environment, you can put the patterns on, anticipate where to attack and then you learn game play. You learn ways of manipulating the space to your favor, often context specific, and there's about a hundred of these.
Open is a great way of driving things to more industrialized, you can slow it down with things like fear, uncertainty and doubt, and you can use constraints. And then we can have that discussion around the board about how we're going to attack that space.
The key thing about this is you do pre-mortems and post-mortems with maps. You take the map, you do the pre-mortem, what we're going to do, what we think is going to happen, and so on. Then you act, and you do the post-mortem analysis and it's through that you learn more about the landscape, more about the game play. You get better at playing the game of chess. That's what I talked about the five factors, it's actually a cycle. That's what that's all about. Understand your landscape. You're learning more about five basic patents, how to operate around all the principles, and then you're getting into doctrine and you can do this as a company level and a nation state level as well. Does that make sense?
Hastie: It does.
Wardley: It's all pretty basic.
Overview
Hastie: Really interesting introduction and overview of mapping, so if our audience want to explore this further, where do they find it?
Wardley: Well, if you go to medium.com/WardleyMaps, you'll find there's a 600 pages of a 19 chapter book, which is not yet completed, on there, that's what I've written, it's all creative commons, help yourself. If you go to list.wardleymaps.com, you'll find there's an awesome list linked to an awesome list on GitHub where there's an entire community, there's videos people are creating, content, tools, training courses, and people do all sorts of things. People have taken my blog posts and converted it into physical books. I encourage all of this stuff. It's all creative commons. Help yourself.
I work at something called the Leading Edge Forum, it's a research group, so you can always come and find me and talk to me.
Map Camp Conference
You will find there's an entire community and we also have something called Map Camp. Map Camp started with me a couple years ago, going to a pub, anybody want to come and talk mapping and then about 80 people responded. It was wow. We got a church hired and about 200 people turned up. No advertising. The next year we got a slightly bigger hall and we had 400 people, 450 people turn up, again no advertising, and the next year I said, “Right! Well, we'll get a theatre this time”, and so I said, “Look, there's a theater”. I'm not going to advertise, I'm just going to tweet a few times. Quite a bit, invite you to Map Camp, tell your friends if they want to come along, we need a bit of money to pay for it, it's getting a bit expensive now, and we had 850 people turn up.
We had all these wonderful people giving talks about the use of mapping in the environment and in terms of challenges and all sorts of stuff, which you know, because you were all there recording it as well. And you've done a wonderful job of putting these videos up and I've got to say thank you very much.
Hastie: Simon, thank you so much.
Wardley: It's been a pleasure.
See more presentations with transcripts