A live conversation with Simon Wardley, creator of Wardley Mapping

Most government modernization skips the step that makes strategy possible: seeing the full landscape.

Programs often jump straight to action—buy the platform, stand up the pilot, adopt the framework everyone's talking about—without a shared picture of how their value chain works, what users need, or what's evolving. So they copy what worked somewhere else, defend sunk costs, and react to change instead of anticipating it.

The result is less failure of effort and more like playing chess without looking at the board.

In this Mission O/S Live, Rise8 Founder & CEO Bryon Kroger and VP of Enablement Adam Furtado sit down with Simon Wardley, creator of Wardley Mapping and one of the most original strategic thinkers working today, to talk about how to map your situation before you commit to action.

Wardley developed his mapping method as a frustrated CEO who couldn't answer a simple question: does this strategy even make sense? The method has since become a way to expose assumptions, surface hidden dependencies, and decide where to build versus where to buy.

They'll cover:

• Why situational awareness is what most government programs are missing
• How mapping a value chain exposes where to differentiate, where to commoditize, and where you're wasting money fighting the inevitable
• How technology evolves toward commodity, and why programs keep custom-building AI that's about to become off-the-shelf

If you're tired of strategy that's really just guesswork dressed up in a slide deck, this conversation is for you.

Adam Furtado (00:00:30):

Hey everyone and welcome to Mission OS Live. I'm Adam Furtado, vice president of enablement here at Rise8. And today I'm joined by Rise8's founder and CEO Bryon Kroger and really glad to have Simon Wardley as our guest today. If you've spent any time thinking about strategy, you've probably run into Simon's work. He's the creator of Wardley Mapping, a method for actually seeing the landscape you're operating in before you actually commit to a direction. He built it years ago as a frustrated CEO who couldn't answer a pretty basic question about his own company. Does this strategy even make any sense? Worldly mapping became the answer to that. It's since been picked up across governments and enterprises around the globe as a way to expose assumptions, surface hidden dependencies and figure out where to build versus where to buy. He also has a sharp eye for AI is heading strategically, what's commoditizing fast, what isn't, and the risk of building your own mission on an infrastructure a handful of companies can control.

(00:01:25):

Simon and Bryon, thanks for joining us today. I want to say, Simon, also, thanks for joining us today. I know you had to take a break from scouting Norway's back line in preparation for England's big match tomorrow. So thanks for fitting us in.

Simon Wardley (00:01:38):

Thank you. Thank you very much. And yes, it's a big game tomorrow, obviously for us in England. So yes, we're pretty terrified, but we'll see what happens and also somewhat hopeful.

Adam Furtado (00:01:52):

Fair enough. Yeah, our audience wishes we had one today, but before we get into the thick of it and fair warning to everybody watching, this is going to be a 200 to 300 level conversation. But before we get into that, I want to make sure we're all starting from the same place. So Simon, can you give us a brief origin story of Worldly Mapping? Where'd it come from? What's it actually look like when does it show you, I guess, that you couldn't see before?

Simon Wardley (00:02:15):

Gosh. Okay. So where did it come from? I used to work for a company called Fatango, online photo service. This is back in 2004, roughly. We were very profitable. We had about 16 different lines of business and total 10 million users across all the lines of business. But we had a problem. And the problem was our CEO was completely and utterly clueless, making stuff up as they went along. And I know this for a fact because I was the CEO. So I used to come up with these strategy statements, which were basically just pinched from other companies and a few words changed. I had no idea what I was doing, but we were being very profitable and all this sort of stuff. And I used to read every book I could find on strategy. It was getting nowhere. And I ended up in a bookshop in Sharon Cross talking to the bookseller.

(00:03:09):

And she persuaded me to buy a copy of Sun Tzu's The Art of War. Now, she was really a good bookseller. So she persuaded me to buy two versions of the book because they're all basically translations. And for this, I'm forever grateful because it was in reading the second book I noticed a particular pattern that Sunsu talked about. Have a purpose to do something. If you have a purpose, then understand the landscape you're operating in. Then understand the weather, the heavens, the climactic patterns, how the landscape is changing. Then you get into basically how you organize and structure yourself. So principles or doctrine. And finally you get into gameplay. How do you change the environment to your favor? And so I became really fascinated by this idea of how do you understand landscape? Because when we compete, and I better just clarify terms, competition is the act of groups of people seeking some resource.

(00:04:12):

And we do that in many different forms. Sometimes we do it through conflict, fighting others, sometimes through cooperation. So helping others, sometimes collaboration, so working with others. So we normally do all three at the same time, bit of both on whatever landscape. And we're really good at doing this in territorial landscapes, but we also compete over economic, technological, social and political landscapes. So I became fascinated about how you mapped those. And the problem I had is everything I had in my business, which called itself a map. So my maps, customer journey maps, all this sort of stuff all had one thing in common. None of them were maps. They're all graphs. So the way to tell the difference is if I take a territorial map and I shift Australia and put it next to the US, that's fundamentally changed the meaning of the map. If I've got something calling itself a map and I can move a box and move it somewhere else and it doesn't change the meaning of the thing, then you're always certainly talking about a graph which has nodes and connections rather than a map because a map is tied to the landscape.

(00:05:27):

So facing this problem, it took me about a year. I developed a way of mapping technological, economic, social, political landscapes. I sort of assumed that this is what you learned when you did an MBA because that's the secret source. They teach you this stuff properly and there's cheap old me just trying to read books and having no idea what I was doing. These days they drag me for a couple of days a year to teach at places like London School of Economics. The World Economic Forum's just written a whole thing on technology convergence, which uses my mapping. So it turns out my assumption 20 years ago that you learned the proper way of doing it and here's my cheap and cheerful way of doing it. Turned out to be somewhat flawed because most people were actually competing on the basis of stories, not actually through understanding the landscape.

(00:06:20):

So how do you map? Pretty simply, you start with thinking about the users, the user needs. Then you start asking yourself what components are involved in making those needs. That will take you to a graph of the space and you can get graphs with things like SPOM, software, billing materials, et cetera, fairly standard. Now to turn that into a map, you have to think of it through each component, which is in fact just forms of capital and ask a simple question, how evolved is this component? Are we talking about the genesis of novel and new items? Are we talking about custom-built examples? Are we talking about products? Are we talking about rental services, commodities? And the reason why you have to ask yourself how evolved the component is because our practices change the way we treat things change as something gets evolved. So a classic example of this, I had an insurance company in 2010.

(00:07:22):

They were looking at a big project to invest in robotics to basically speed up the process of putting servers into their data centers because they're growing and that was a big bottleneck. And what you do with bottlenecks is you try and solve the bottleneck. And so they came up with this big plan of investing in robotics. They'd spent six months working on it. Wonderful story. And all the return investment calculation stuff one year. And I was asked what I thought. Well, the thing is you can't challenge somebody's story because we tell people great leaders are great storytellers. So if you challenge somebody's story, they get very defensive, very protective. So I simply said, "Could we map it? " And so we spent a bit of time mapping it out. And so they started off with the user needs compute and this requires goods in, et cetera.

(00:08:13):

And I was able to look at their map and they had racks in custom built, quite a low level item. And I said, "Why have you got racks in custom built?" And they went, "Well, because we custom build our racks. So what are the modifications you're making to service?" "Well, they don't fit our racks so we have to take cases off, drill new holes, add new plates in order to get them to fit our racks. "And then somebody in the room just went," Why don't we use standard racks? Big revelation, 10 million pound project disappears in smoke. Now these people weren't stupid. They were simply tracked by past story because at some point in the past, there was no such thing. So by simply being able to visualize and challenge the map rather than the person, that entire project disappeared. So let me show you what a map looks like.

(00:09:01):

I've got some horrendous examples because I like to use horrendous examples. So we've got image one. And so this is a map of the healthcare value chain. So basically I took a whole bunch of people who were clinicians, so doctors, surgeons, professors of medicine, nurses as well, people who worked in the healthcare space, and we were looking at investment areas in healthcare. So we simply started, well, before we begin, we better think of different areas of healthcare we need to look at. So the healthcare value chain was one. There's others such as clinical pathways. And so we started off with this one. What do we mean by healthcare value chain? So they start off with the users, medical industry, insurance and government. And okay, what do these people need? Well, government needs a public because it needs to be voted for. And the public needs health and that health is avoidance of disease and treatment to existing symptoms and potentially there could be patient education.

(00:10:05):

And so what you do is you start building up this chain of components. Now where you've got health, that's actually... When we talk about something like health, there's normally multiple things which have that meaning. That's why you have this little rectangle because what it's saying is that treatment, avoidance of disease and patient education are all part of or have a shared meaning of health. And so you can go through this chain and we end up at the bottom with things like sensors and last mile medical centers, hospitals, all the way down to population data. So once we've got an agreement on a landscape, what does that mean? Why is that useful? Well, let me pop up image two.

(00:10:49):

So what we are able to do then is start saying, "Well, look, if we want to invest in this space, where should we invest?" And so they were able to use the map to highlight different areas. We could invest in health economics, understanding that better. We could invest in availability of treatments. There was the last mile, telemedicine hospitals. We could invest in virtual consultation. We can invest in medical monitoring. There are a number of different areas we can invest in. Now, why is this interesting? It's interesting from the point of view of where do you invest for a market benefit and social benefit? So three of them they've colored in purple because they though these were really important to society. So measurement of health outcomes, education and medical data, really important, not necessarily the greatest areas for growth and making money, but really good for healthcare in a society.

(00:11:51):

So if I now, we flip to the last image, which is image three, sorry. My apologies, image three. All right. By taking a group of 80 people, and they're all practitioners in medicine, getting them to map out healthcare from different perspectives. They like the healthcare value chain, you've got clinical pathways, we map those out. It's a bit like the analogy I would give is if you've never mapped Paris and no one's ever mapped Paris, let's pretend. And we send a group of people to map Paris and they come back with a map and you ask them what's important about Paris. They might say to you, Pierre's Pizza Parlor, because they've mapped it from a perspective of nice places to eat pizza. And Pierre's Pizza Parlor is like the best place to eat pizza. So what you do is you send multiple groups out to map from different perspectives and then you aggregate across those and then you can find what matters.

(00:12:56):

So this is exactly what we did in this case. And we asked them to look at investment, each of those groups looking at where to invest for a market and social benefit and then aggregated across all of them. And what you find with healthcare is that if you want to improve healthcare for a society, the primary areas you want to invest in are things like measurement of health outcomes because we don't actually measure health outcomes. What we do, we're actually a sick care based system. We're very good at treating symptoms. So people turn up with symptoms, we treat them. We often send them back into the same environment that made the meal in the first place and then we see them later again and treat them for the same symptoms. Really good for KPIs, really good for selling drugs, not necessarily very good for making people healthy.

(00:13:45):

So if you want to focus on benefits to society, you'd be a measurement of health outcomes, sharing medical data, which would be your priorities. But equally, we can use the same maps to look at where do I want to make money? So if you want to make money, it's all about personalized DIY medicine. I mean, we don't know what actually a healthy person looks like because we don't even know what a person for symptoms looks like, but not what healthy looks like. But nonetheless, we have entire industries around DIY medicine, education preventive healthcare, even though we're lacking some of the basic data. Now the reason why I like this particular table, this summary table is it shows that if you look at the market benefit measurement health outcomes right down the bottom, low priority, because it's not considered a place you can make money, but it's really important from a societal angle.

(00:14:37):

And I've done 21 different industries, so things like construction, manufacturing, defense, and you often see this difference. In fact, I found this difference in every industry bar one. And that was within a section of the space industry where there's actual overlap between social and market benefit. In every other industry, it's quite different. So people often tell me, you want to improve society. Market growth is the answer. I'm saying those are two completely different things. So what did the map do? Well, the map helped us one, understand the landscape that we were doing, working in, in this case healthcare. Two, it helped us have conversations around where to invest from multiple different perspectives. Thirdly, we can often aggregate and find other patterns we weren't expecting. So that's mapping. And I use it in terms of running businesses, helping governments. And I even use it personally on myself as well.

Adam Furtado (00:15:35):

There you go. That's great. Thanks, Simon. You roll the ball out, let Simon cook. That's what we're doing around here. So that was great. And I think you hit on a dozen things that I think really tie into the way that we work around here. But Brian, with your deep roots in government software delivery, Kessel around the Air Force now at Rise A in a variety of context, I'm just curious, where did you first encounter Simon's work and what clicked for you, I guess, within this context specifically within GovTech?

Bryon Kroger (00:16:07):

Yeah, I think I was trying to learn how to do software development and I just watched every episode of the GoTo conference for four years running. But Simon gave a talk called Crossing the River by Feeling the Stones. And I looked him up and he had his book on Medium, which by the way, you should check that out if you haven't. It's probably one of the mapping aside just as general strategy, probably one of the better books on strategy. But I instantly fell in love because it starts with John Boyd and I'm an Air Force veteran. So got to love Boyd and putting good context to Boyd that I think gets left out of the very basic loop conversation. But outside of that fanboying on John Boyd and Simon, I then immediately started using it to solve the problem that we had, which was everywhere I looked in our organization, this is our Air Force Custom Run, and then outside of our org in the larger enterprise, folks were mistaking.

(00:17:05):

It was like that classic server rack example that Simon said. Why are we building our own racks? We could just buy those. These are commodities. And it was happening literally everywhere. And people couldn't sort out when it was, because sometimes it is necessary. In the defense industry, there were things that we probably couldn't leverage commercially even if they were commodities, but nobody was making good strategic decisions about that. And so we started mapping it and we ended up coming to a lot of different decisions than the rest of our colleagues across the enterprise. And it made us very successful, but it also caused a lot of organizational friction. And so maybe something we can talk about later, but yeah, it became the basis for almost every strategic decision that we made.

Adam Furtado (00:17:48):

I think -

Simon Wardley (00:17:50):

Oh please.

Adam Furtado (00:17:51):

Yeah, sorry.

Simon Wardley (00:17:52):

I'm

Adam Furtado (00:17:52):

Terrible.

Simon Wardley (00:17:53):

I can't keep on scheduling. That's great. I am absolutely apalling. And so if anybody's under any thinking this is scripted, it's not got a chance with me in the room. All right? So do you mind if I just... Because I just want to build on that point that Brian said. I've got a presentation open. Let me just share a share screen

(00:18:16):

And please by all means stop me at any point. Can you see... There we are. I've got a screen there. Slide share. Okay. So this is James Finley. James Finley was the CIO of HS2. He's a good friend of mine. HS2 is high speed rail. Big, big, massive scale, heavy engineering project in the UK. I mean, many, many billions. Now James had a problem that he wanted to build the entirety of HS2 in a virtual world. And this is a systems graph for building HS2 in a virtual world. It has various components, engineers, public website, graphical information system, and it's a graph. And James's problem was this, how do I organize it? So typically in government, what we used to do back then is we would group things together into what we called lots. And lots were basically things which seemed sensibly sort of connected.

(00:19:27):

So we'd have lot one engineering, there's a bunch of engineering staff, lot three back office, lot four infrastructure, lot two user experience. We'd outsource it and we'd have massive cost overruns, massive failures and all this sort of stuff. And James wanted to avoid this. So he's an old friend of mine. I taught him to map. So back in about 2000, I think 11ish, 12-ish, he spent Sunday afternoon draw a map. So again, starting with the users, thinking about their needs, the components is exactly the same. This is the map. It's 2012. And he said, "Right, how do I organize this? " Now for me, this was quite easy because I'd been mapping since 2005. My organization, we'd gone all agile way beforehand in 1999 actually. Kent Beck's a friend of mine. And I'd actually picked up the whole sort of extreme programming as soon as that book came out.

(00:20:28):

And of course, by 2004, we discovered it doesn't work everywhere. In 2005, we had maps and we'd worked out why it doesn't work everywhere. So if I look at this map, the stuff on the left is what we call uncharted space. So things like 3D visualization starts off in Genesis, something novel and new. Eventually you get custom examples, products eventually become commodity accepted. Websites started off in something Genesis and evolved over time as well. And so everything is moving from uncharted to more industrialized. And because of this, there's no such thing as one size fits all methodologies, whether it's project management or purchasing. So agile in - house was really strong on the left-hand side because it reduced the cost of change. Whereas Six Sigma and Outsourcing and those sorts of methods strong on the right-hand side because they reduced deviation and getting rid deviation is what you want to do with a commodity.

(00:21:28):

And in the middle, you're all about learning and it's off the shelf. So by simply applying that to a map, and this is what I did in 2006 and we just repeat in 2012, we can just go, right, the stuff on the left-hand side we build in - house with agile techniques. The stuff in the middle you use off the shelf products. The stuff on the right-hand side, you outsource to utility providers. And this is what James did and this got delivered where had a schedule, where to budget. NASA did a project with Planet Labs, did exactly the same thing. Again, same result. So what normally happens is organizations don't understand their landscape at all and they try to apply a one size fits all method across the lot. Let's agile everywhere or let's outsource everywhere. And that never, never works. And ignore the burning. The burning is because every time I go into conference and say to people, agile doesn't work everywhere.

(00:22:26):

They go burn in heretic. It's the same as when I go to a Six Sigma conference and say it doesn't work every burn inheritic. Everybody thinks I'm a heretic. But let me take James's original, one of these lots. This is the graph. There's lot one engineering, looks quite sensible. Engineeringy stuff, let's put it into a contract. Now let's overlay it on the map. I can tell you that contract's going to fail before we've even signed the paperwork because what we're actually doing is combining commodity and late product stage activities, which we can define with stuff like the land registry 3D visualization, which back in 2012 we couldn't define. And we're sticking this in one contract. So we are literally guaranteeing ourselves massive cost overruns. And this is one of the most common problems I see. I see people doing these contracts and it's not, by the way, a problem with government, it's across the private sector.

(00:23:22):

They don't understand the landscape and the environment. And they have these wonderful contracts based upon these things seem similar with no actual understanding of the context. And so what they're doing is they're combining things which can be defined and delivered with things which can't yet be defined and delivered and therefore sticking them together in a contract and being surprised that they get massive cost overruns. So the stuff on the right can be specified. The stuff on the left you can't. And I can guarantee this is where you'll get the cost overruns time and time again. Sorry about the interruption.

Bryon Kroger (00:23:56):

No, this is perfect. This problem is maybe one of the most frustrating problems I run into in government contracting is not being able to see what you just showed. And then you get people that they're converting to agile religion and they're like, oh, team topologies, value stream maps. We're going to organize our teams around value streams, but they'll do the lots that you showed instead of the value chain that you showed at the end. And so you'll see an infrastructure value stream. And it's like, hold on a minute, that's not a value stream. And I think I have a perfect example of this actually from the early days of Kestel Run. I got really frustrated with my team because we had built out the first over in, just say the Middle East, the first platform we built and delivered the first apps to it. And we had done it in 120 days, which was an unbelievable record to do anywhere in the government.

(00:24:48):

Everything takes five years. We got it fully deployed and operational in an active war zone in 120 days. And they said, "Hey, we want one of these in every theater." So we mapped out all the theaters and we said, "We should do Korea last." We said, "That's so much complexity. We have to share with our Korean partners, which aren't part of the FiveEye partner nations." And so there's just tons of complexity there. And we got a call. Things were actually popping off in Korea at that time. And military, very senior military leadership said, "We want you to install Korea next." The one we had just said we should do absolutely last. And this is kind of what happens when you start getting Agile folks at that time period, this is like 2018, 19, you started to see a lot more Agile software developers being pushed into the PAS development space, especially in the Cloud Foundry community and to great results.

(00:25:35):

They created really great products. But then when you asked them to go install them, they wanted to give me Agile pushback of like, "No, no, no, we can't give you a schedule for the install." So I took one of our... And to his credit, he had become like a, they say there's no Zellot like a convert. He had become a zealot for Agile, but he was a 15-year project manager and he

Simon Wardley (00:25:57):

Was

Bryon Kroger (00:25:57):

Really good at it. And I said, "Look, there are parts of this, it is not Agile to install a server rack. It's just a thing that we can put on a schedule and we know how long it takes. We know how long the wiring takes. We know how long shipping takes." And so we had to build out this project plan. But I always point back to that as an example of we ended up delivering that in 155 days. Our deadline was 180 days, which again, this thing should have in any other world taken two or three years in government.

Simon Wardley (00:26:24):

And

Bryon Kroger (00:26:24):

I credit him for being able to separate those components of the apps we're deploying out there are still in that custom-built phase. Yes, we accept that it's going to look very different than all of this stuff that has to get done underneath the infrastructure, the commodities and all of that. And so to his great credit, he was able to separate those two things into two separate contracts and manage those vendors separately and it was a great success. So it's a lesson for every government project manager everywhere that you've got to separate those.

Simon Wardley (00:26:55):

That's fantastic to hear because I do the example of project management, but it's also purchasing. So purchasing is very much when it's commodity, it's on unit value, utility pricing. But when it's in the more genesis, it's on the work done. I mean, then you may be able to be able to over time determine what the outcomes you're looking for so we can make it more outcome related. But what we have are multiple different contract structures we need to apply. Because when we talk about something like land registry in the case of HS2, land registry isn't a fixed thing. It evolves over time. In the same way that infrastructure is not a fixed thing, it has evolved. You go back to the 1940s, the Z3, 1943, then Leo Lines electronic office, that's a world of difference from utility provision with EC2. So the methods that you need change depending upon how evolved these components are.

(00:27:55):

And that seems to be a big thing which is missed too much. And it impacts purchasing, finance, it impacts project management methods as well. You are being a bit of a fanboy about John Boyd. I'm going to say I'm also a fanboy of John Boyd, but also Lieutenant Colonel Dan Ward as well. So it's another US Air Force as three. And the work on basically Fista Five, which later became the book Fire, which was all about fast and expensive, simple and tiny. And it's just that process of let's take these projects, let's think about the users and their needs, break them down into components and make sure we treat components in the right way and how we treat them will change over time as they evolve. Fabulous to hear, by the way. I'm big fan of the Kestle Run stuff as well.That's

Adam Furtado (00:28:46):

Great. Yeah, Dan Ward, certainly a friend of the family here. We actually had him work with one of our teams recently. He did a whole talk while juggling live in our office. So that was pretty cool. You also mentioned Kent Beck. I just want a quick plug here. Kent Beck is headlining Pudacity in August 25th, 27th. So get your take a stake. Get him to bring his

Simon Wardley (00:29:07):

Guitar.

Adam Furtado (00:29:08):

Yeah, we'll see. Yeah, there we go. We're off script anyway, so let's keep going. And one thing I've really been thinking about and a problem we're trying to solve here at Rise Aid is we have this goal. Our core goal is putting mission outcomes into production. So let's assume that a web app needs to be created to build a thing. And in most cases, in order for that piece of software to get to the user in need, that organization usually needs an entire path to production to be built platform through compliance. And so in order for that to happen, it's sort of like asking the need I have as a user is from getting from point A to point B, and I want an Uber to take me there, but we have to pave the road in front of the car every time we have to do it.

(00:29:46):

This is a thing that we're seeing over and over again in organizations throughout government, particularly in the DOW. I want to ask about abstraction levels, Simon. When you talk about what Poorly mapping, how do you think about abstraction levels? We live in the world's largest bureaucracy. There are programs within it that are worth billions of dollars and have all this pressure on them and these leaders who have real edicts to accomplish some of these things. How do we ensure that we are mapping and making those strategic decisions at the level that is most effective, like horizontally across our organization so we are not either duplicating efforts or we can find the most effective solution coming out of that work?

Simon Wardley (00:30:29):

Okay. So first of all, when we think about a map, each of those components can itself be a map and each of the components within that can be a map. So what you end up with is this idea of sort of high level maps and then you can literally... The map itself can extend downwards or you can extend into the map itself. So if I go back to something like the medicine healthcare map and there was telemedicine as one dot, well, if you want to expand that out, there's a whole bunch of other components involved in telemedicine. So what we've got is an Atlas you'll lose some granularity. It's a bit like if you look at a picture of the UK and you look at Leeds as a town, it's like a dot. Of course, if you expand it, then it's got houses and everything else and it's far more detailed.

(00:31:24):

So there are many, many levels of detail you can have within a map. So I do mapping often at nation state level. So I did a whole bunch of, for example, China versus USA. I did a whole bunch of research on that, which was in 2015, which was looking at value chains between the US and China and mapping those out. So often I'll do quite high level nation state competition. Then I'll get dragged into businesses, which are a subset of that, and then down into individual projects and even down to the person. I've done mapping myself, for example. So there's different levels of gray. Now, how do you know where to play which bits? Well, this is the downside. These maps are like Babylonian clay tablets. They are really primitive and really simple. We're used to looking at things like in the UK ordinance survey maps, which territorial maps, which have fine details and everything else.

(00:32:30):

But if I go back in history, our early maps of the UK were like earby dragons and probably didn't look anything much like the coastline of the UK. It took us a long, long time before we were able to find the right way of mapping territorial landscapes. Well, unfortunately, these maps and the maps I'm showing you are very early stage maps. Give it a couple of hundred years and people may have found the better way of doing it, but give them time to find the better way of doing it. All I can say is the only way we operate is we create a map like a healthcare map and we look at it. We ask the question, is it useful? And can we make it better? And we try and make the map better and we ask ourselves, is this a better map than the one we had previously?

(00:33:22):

And how do we know it's better? Because it helps us answer more questions. So unfortunately, what's the right level abstraction? It's fairly sort of like trial and error, I'm afraid. Simon, that's the way to do it.

Adam Furtado (00:33:39):

In our prep call on the topic of the duplication, you had talked about the work you did with the UK prison system and the amount of kind of duplicative efforts. Yeah. Would you mind telling that story?

Simon Wardley (00:33:50):

So it wasn't specifically with the UK prison system. It was actually with the MAG, Ministry of Justice. And what it was was I was looking at levels of duplication because I'd written something called the Better for Less Paper with Liam Maxwell and others. I was one of the co-authors of this paper. This paper supported the creation of something called Spend Control and supported the formation of something called GDS, Government Digital Services. So it was a supporting document for them. And I had got involved in various parts of UK government. They asked me to look at things because mapping's part of this. And one of the things that used to come up was that duplication was a problem. Well, the role of spend control was supposedly to challenge projects before they're done. And you do this by helping to generate a map and asking questions of the map to get over the politics of stories.

(00:34:50):

And once you've got enough maps, you can often find the same component exists in several different places. And so what you can do is you start to build a profile diagram. So for example, you'll find websites. We've got loads of websites here and there or call centers like the Department of Work and Pensions. We've got call centers almost for every different benefit type or did have in the past. Or we had the DEFRA, we had a pig tracking system, horse tracking system, cow tracking system. But they're all quadrupeds at the end of the day. So what happens is you can use the maps to identify commonly repeating components and duplication. Now, the worst example I was given of duplication was through the MOJ, which was 117th workflow systems doing basically the same thing, which I thought was like, oh, that's terrible. But then I started mapping a lot more with the private sector.

(00:35:52):

And I had one pharma company had 350 teams building enterprise content management systems, five global efforts building the global enterprise content management system. I had one bank where we stopped counting at a thousand risk management systems. So we know they had a thousand. We know it's more than a thousand, but we just give it up at that point. They were really good at building risk management systems over and over and over again. We had a defense company which had 2,000 accounting systems. So what I started to realize is that the level of duplication and waste in government, because ideally for reasons of systemic failure, you might have four, five or six, perfectly reasonable as long as consciously done. A hundred, that's a bit much, you want to reduce that. But the level of waste I found in the private sector far exceeds anything I've ever found in government.

Adam Furtado (00:36:48):

Well, that's good to hear. Yeah.

Simon Wardley (00:36:50):

Yeah. It's a shock. Well, the thing is, because government has things like the National Audit Office in the UK, GAO in the US, and they audit stuff and these audits are public. This is a really good duty. In private companies, they have the magic carpet. So you just lift it up, sweep it under and pretend it wasn't there to be blunt. I mean, I have not seen waste in government anywhere close to the level I've seen in the private sector.

Adam Furtado (00:37:20):

Interesting. Brian, we had a good question in the chat that came up from one of our Space Force folks. This was sort of talking about how we group things in the map that you showed Simon. But Brian, I wanted to ask you, JJ Homan wrote, "This hits home with the multiple bid to win proposals to RFPs where the prime has the processes, personnel, infrastructure, et cetera, et cetera, to deliver. What can the customer do to prevent or help this do our own worldly mapping of what is likely needed regardless of the contractor before the RFP?" And I think a lot of us, especially the bigger the contract, the more stuff we're stuffing in it. So how do you think about how the government should think about that sort of thing?

Bryon Kroger (00:38:04):

Yeah. Actually, I had a map I was going to share. Actually, I could share that now that fits in. And it kind of actually goes to the first question you asked Simon earlier about the path to prod and

Simon Wardley (00:38:15):

Levels of

Bryon Kroger (00:38:15):

Abstraction. So this is one of the first customers I ever had at Rise Eight. I have another example I can share as well maybe later, but everything in that left circle there is what we would traditionally call the path to production. And so we mapped out this organization and they were doing first of all, a bunch of things that probably shouldn't have been custom, but these were all control groups who exerted control over the path to production and getting your software in. And so what government will typically do, and this is probably something JJ and others are familiar with, is each one of those dots will get a labor contract. And so we'll put out a labor contract for data governance, for global readiness, for security, for disaster recovery, for SOX. Again, that's not the value stream. Those are individual pieces. And so if you don't do this first, you might be tempted to go get every one of those organizations, those control group support.

(00:39:09):

And it's like theoretically, if we get them support, they'll be able to do their jobs faster and we'll get through the control gates faster. And that never works in practice for the reason Simon showed on the lot diagram. And so first we want to decide what we want to evolve. And this is the way the organization's doing business today, but you see these blue arrows. These were all elements we decided we wanted to evolve. And based on where we were going to put them, we decided what kind of contract we needed to let to whom. And they ended up being separate contracts as Simon said they should be. And so JJ, to you, I would say the more you group all of these things together, the more you will get bid to win proposals where no single vendor can execute. Now, some vendors are better than others in that they will just still treat that work internally as separate and distinct.

(00:40:01):

And they might bring on a subcontractor who specializes in agile software development and somebody who does ops, but we almost never get that. So there's maybe one world where you could, for the sake of government, because procurement is hard, you do put that all in one contract, but you specify that you want it managed differently and by experts and you evaluate for that and make sure that it actually happens. But I would argue for actually segregating the contracts and then specifying contracts between those contracts in the form of APIs or SLAs to make sure that if there's a dependency between contractors, those are getting met or held accountable properly. That's especially the case in path to production. The other thing that I'll say here that's really important, somebody else asked a question about how does mapping process fit between initial delivery and continuous improvement? And there's maybe just one segment of that that I'll highlight.

(00:40:53):

There's way more we could go into and maybe Simon would, but one thing I see happen a lot is we go build a capability for a war fighter and it's agile software development. We don't know what needs to be built exactly. We go out, we build a piece of software using agile practices, but very quickly it's like you could always keep building and iterating on that app. So you could keep it in agile mode forever, but at some point you have to decide how do we want to allocate all of our resources? We have a budget of $50 million. D we want to keep iterating on this app or is it at a level where we should go invest in something else because the value proposition's greater on fixing another workflow issue than continuing to iterate on this one? And when that happens, that team that was building, you had an agile software development team, you don't need one anymore.

(00:41:39):

And so you probably either need to end or modify that contract to move it into a sustainment team that is more commodity oriented to operate that and run day two operations. It's going to be a lot cheaper. They're going to have a lot better reliability probably. They can probably manage multiple applications in your portfolio while you focus those more expensive agile software development efforts on the new things. So that's definitely something I would pay attention to is even in your own journey, you're evolving products left to right all the time. And if you don't pay attention to that and make the switch, the costs will eat your lunch.

Simon Wardley (00:42:13):

To ad onto that, I mean, one of the things I did in 2005, I created a structure based around those ideas. Back then I used to call it Pioneer Settlers Town Planners and later on Explorers Villages because unfortunately Pioneer Settler Town Planners has a bit of colonial overtone to it, which I didn't realize at the time. And so these days I call it Explorers, Villages, town planners. And what you need are, if you look at the map, you can group those areas, the map and create small cells full of all the right attitude. Because the attitude you need for Genesis and early custom is different from the product world, is different from the commodity world. And it doesn't matter whether we're talking about finance or operations or software development. Those are aptitudes as in skills. You also need different attitudes. And the way to replicate what was going on in the marketplace was through what I called the system of theft.

(00:43:14):

So my town planners would steal from my villages, my villages would steal from my explorers and that would force everything to continuously move through the system. There is a wonderful paper written by GCHQ, which is the UK Intelligence Services called Boiling Frogs, which has that basic structure. And I recommend people to find it. I know it's all being made public and everything else. It's a fantastic paper, I think. And it also talks about the Death Star projects that we tend to build, despite the fact they get blown up all the time. And then we go and build the next Death Star and that gets blown up. It's just a different way of operating.

Adam Furtado (00:43:57):

So many references from how we've built these programs and projects over the years. I just want to say to our audience, we're going to keep going. Go grab a coffee, maybe a tea for our UK folks. I'm getting notes in the chat that we're at 12. We're going to keep going because we have a lot still to talk about. So hopefully people are enjoying the conversation. I certainly am. And I want to shift a little bit into maybe evolving this conversation a bit. I think Simon, there's a lot of pressure, especially in government right now, to own your entire stack and this idea of keeping it on our own infrastructure,

Simon Wardley (00:44:34):

Our own

Adam Furtado (00:44:35):

Territory. In our prep call, you've kind of mentioned that this idea is total nonsense. So I want to give you the opportunity to make the case to government audience who's probably in this right now and thinking about this quite often. So feel free to make your case and we'll see what.

Simon Wardley (00:44:54):

Okay. Can I share some slides then as well?

Adam Furtado (00:44:57):

Yeah.

Simon Wardley (00:44:58):

Oh, fantastic. Real world. Okay. We're totally off script here. Excellent news. Share screen window. There we are. Can you see a map?

Adam Furtado (00:45:13):

We got it.

Simon Wardley (00:45:14):

Right. So normally when we talk about... So I said we compete over multiple different landscapes. One is territorial, one is economic, one is technological, one's political, one's social. But there's also legal landscapes as well. So territorial we often call environmental, that's the whole pestle terminology. But if we think about territorial landscapes, when we talk about sovereignty, we normally go something like this is our border. Inside the border, this is our society, our values, our behaviors. If you cross our border, we conflict with you or fight with you. So that's the form of competition we deal with. Outside it, we might collaborate, cooperate with you. And we can often, we'll collaborately cooperate or we might cooperate to conflict with others, whatever it happens to be. Some combination. But we use the landscape to describe where our border is and what it is we wish to protect.

(00:46:14):

So I was doing some stuff for the DVLA. This is back in 2015. So this is 11 years ago. And we were interested in the automotive industry. DVLA is a licensing authority for driver vehicle licensing. And so this was a graph of components involved in car manufacturing or associated with cars. Well, where's my border here? And what matters? I can't tell. So what we did is we first of all created a map using that. So we start off with user wants to go from A to B and it needs to be affordable, comfort, route management. You've got some sort of GPS or whatever or Atlas paper. Atlas car has some sort of entertainment system, information system. There's OEM assembly. So we've taken a simplified version because we can expand this out in much more detail if we wanted to, of the map of the supply chain for the automotive industry.

(00:47:20):

And this was 2015. And so we had this idea of there are intelligent agents who already had cars which could assist with parking and things like this as well. And one of the things you learn with maps are those climactic patterns, the heaven. So how things evolve. So you know if there's supply and demand competition, things will evolve. We have inertia to a change. It will create co-evolution of practice, all sorts of things. And so we were able to roll this forward to 2025. So this was our forecast. So this is from 2015. Our forecast for 2025 is cars would become much more commodity-like. Intelligent agents would become much more common heading towards being commodity accepted. And we sort of realized that car manufacturers would try to differentiate some way or another. And so what we though of is they'd probably differentiate with digital subscription models based around design features.

(00:48:19):

And I think it was BMW or Mercedes or somebody in 2018 came up with a, you could have a digital subscription to have a hot bottom seat or something. So a seat which warmed your bottom up or something like that. It was something daft. And we weren't really bothered about that.

(00:48:39):

What we were worried about was they would use status for route management. So the way to think about this is you've got a car coming along, increasingly cars are self-driving. You've all got digital subscription members. Here's gold member. What would happen? Well, everybody else's car will get out of the way if they're self-driving. So what we've done is embed social inequality into transport systems more than it was already. Well, what's the big issue with this? Well, the big issue is that if we have a flood, that means all the poor people's cars sit on the side of the road while the wealthy people get out. And what that means is next day we have pitchfolks because that's the sort of stuff which drives people very, very angry. And so we thought that's a really bad idea. But we also realized there was another problem and that problem was the trolley problem.

(00:49:32):

So your car's coming along, in this case a trolley, but we'll pretend it's a car and it can hit five people or one people. Who do you hit? Well, hopefully you hit the one person. What if the one person is a gold member? Well, hopefully you still hit the one person. What if you are not making the decision, but an AI system is making that decision for you because it's a self-driving car. So this is what we were talking about in 2015. So the problem now becomes is the values embedded within these AI systems will determine the action that is actually taken. And those values may not be the same values that your society shares. So what we realized going back to the map, and this was back in 2015, is used as a member of the society, society has values and those values are embedded in the simulation models which the intelligent agents are trained with.

(00:50:32):

Well, these days we don't call it this. We call simulation what we call the training data and the intelligent agents are now large language models, large multimodal models. But it's the same thing. So now what about sovereignty? So remember, this is 2015. So this is all before ChatGPT and everything else hit the scene. What we were realized is we needed borders around certain aspects of the Mac. So like training data of values which these large language models or what became large language models are trained with. We need control over that because that's where the values which matter for our society will be. Other areas we could collaborate and cooperate. So it's not so much owning the stack as in it's on our territory. It's understanding all the components in the stack and what are the bits that you need actual control over? So there's no point in somebody says, "Oh, we'll have sovereign AI." And I go, "What does that mean?

(00:51:37):

It's going to be an AI model created by somebody else, but it's in our data center." Well, okay, so that's like territorial sovereignty, but who controls the training day? Oh, they do. Well, their values are being embedded into your system and you have no control. So you're literally handing over that sovereignty whilst pretending you've got sovereignty in terms of you've got control of a data center. So this was the discussion back in 2015. And so a conversation that I hear these days, unfortunately, I don't think has improved. I think it's deteriorated. Particularly over the last year or a year and a half, it seems to become focused on territorial aspects of sovereignty and where things like the stack is and owning bits of the stack without any actual understanding of the technological economic landscape and what are the bits that you do need to protect.

(00:52:34):

So my question is always to counter with where are the maps, radars and situation rooms for the political, economic, social, technological and legal landscapes that we operate in, which is what we need for territorial sovereignty. And I would say mostly, except for in places like China where it's a different game, they don't exist.

Adam Furtado (00:52:55):

Yeah, thanks. The own your own stack conversation is giving me some form of PTSD right now in the past life. But Brian, I guess I'm curious if you can give a perspective on how that conversation framed some previous decisions that you've made or projects that you've been a part of.

Bryon Kroger (00:53:15):

Yeah. I mean, I feel like in government we always got this wrong in either direction. There was actually no consistency. Sometimes there's an over-rotation and sometimes an under rotation on protecting your border, so the parts that actually matter. I think the one I experienced was before AI, but we were having this debate around Kubernetes. It's like everybody wanted to Kubernetes all the things. There were memes about it all over the internet. And to me, the thing that we needed to own was our mission code. The Air Force's mission, and specifically we were in the Air Operation Center program office. We had an AOC mission. I was not in the platform business. I didn't need to be building platforms. I didn't really want to be managing them. They were fairly commoditized at that point in time in 2019. So 2017 to 2019, already fairly commoditized, but Kubernetes was early.

(00:54:15):

At that time it had just recently gone GA. It was still, you needed quite a team. So we actually did awardly map for this. And how I convinced the Air Force originally to let me not do Kubernetes, which everybody though was all the rage and stick with CloudFoundry, was just mapping out. Simon said you can go into the map. So I took each of those components I showed before and I was like, "If I use Kubernetes here, here's what it looks like. Today, I have an eight person operations team to manage my entire worldwide platform, plus two people per geographic node to follow the sun for support." And so I think at the time we had 15 total people. I was like, "If we switch to Kubernetes, it's still early product. We're going to have to stand up all of these teams around basically the API.

(00:55:07):

All the things that you have to integrate yourself. All of these custom sandbotch projects. CNCF hadn't even stood up yet, so there wasn't even a good way to evaluate it. And it was just like I needed an army of people, which was going to cost way more than my CloudFoundry licensing. And then I also now have to manage all of those people, which comes with organizational overhead and focus. And I was like, I'm trying to focus on how the heck do you build an AOC? And now you're trying to put me into the platform business. And so that argument won originally, but as part of the organization, the organization lost that battle to senior leadership. And just as a cautionary tale here, the PTSD that Adam experienced for the next few years after I left, they tried to replace that eight person central operations team again, two people per note.

(00:55:52):

So I think it was like 16 when I left and a pretty small budget in terms of licenses actually. I think my worldwide enterprise license agreement was like 15, $16 million. And

(00:56:06):

They embarked on this build your own platform. Over the next five years, it grew to over a hundred people, nearly 10X the budget. I think when I last checked in, they had spent somewhere north of $250 million. And in those five years, it never went to prod. Meanwhile, the small eight person team with the tiny license bill is still running all of the mission. And so it's just like a perfect illustration of if you choose the wrong borders, it can really cost you... The AI one's particularly concerning when we're talking about values, but even in this less consequential example, it costs the organization its focus, its budget and its mission. And arguably over that time period, I would say not only did the platform fail, but because of all that focus, the app or the core product, the mission failed.

Simon Wardley (00:56:54):

The interesting thing there is when you look at a map and you think about where your border is, what you're constantly doing is trade-offs between things because it's never a case you will entirely own the whole stack all the way through the system because you have collaborations and cooperations with other countries. Any nation, no nation currently stands alone. So it's always a question of trade-offs. What is it that you essentially need to protect and why do you need to protect it? So going back to the DBLA, it was we need to at least have control over what values are coming into our society. We might go, "That's fine. We'll take US values," for example. Fine. Okay. But that's a conscious choice to say we'll have those embedded in the system. We might say, "No, actually we want European values or whatever." But you have to make those conscious choices, those trade-offs.

(00:57:50):

And that's difficult to do if you can't see the environment that you're actually operating in. And so we tend to fall back on these things to let's own all the things. And that's the bit that terrifies me when I hear people talking about AI sovereignty. A lot of it confuses it with let's own the entire whole stack. And it's just like, okay, that's not sovereignty, but all right, fine.

Adam Furtado (00:58:22):

Simon, I want to put you on the spot here. So we're about 30% through the things I wanted to talk about in this call. What if we - No, you just have to invite me back. Yeah, that's what I was going to ask. We're going to bring you back. We're going to continue the conversation. Sounds good. But before we wrap up here, I'm just going to give you one more opportunity. Generally, the audience that we have here are people in the GovTech space, government program leaders. If they've never mapped a thing and this is the first time they're hearing this conversation, what's the first thing they can go take back to their office or their workspace and start to do?

Simon Wardley (00:58:56):

Well, talk to Brian. There we are.

Adam Furtado (00:59:00):

Perfect.

Simon Wardley (00:59:01):

I think because Brian's over in the US and I'm over in the UK, but I would start by one thing I have in the mapping world is this table called the doctoring table. And the doctoring table just basically explains simple principles that you should use. And at the very bottom, the most basic principles are, do you understand who your users are? Do you understand what your user needs are? Do you understand what components are in that supply chain? And do you understand how evolved those components are? I think it's actually worded as, do you understand what it means? I should say how evolved it'd be. I should tidy that English up. But I think just simply doing that and just having a go at trying to map a landscape and giving it to somebody else and ideally mapping, i.e. Mapping with several people. You're often You find that the answers to the problems that you're trying to solve are in the minds of many people.

(01:00:06):

You just need an effective way of communicating that. And that's one of the things I found maps useful at in a way that I don't find stories helpful at because stories are associate... We tell each other great leaders are great storytellers. So whenever you challenge somebody's story, you're challenging their leadership and this is why people get defensive. And so stories are actually a bad form of communication because they're not very encouraging to challenge. Whereas I can go, I think the map is wrong and I'm not blaming any person. I'm saying the map is a immaterial thing to some extent, but it's just the idea is I can point to the map and I say, I think the map is wrong. So I think that process of just thinking about who the users, what are their needs, what components are involved, how evolved are those components?

(01:00:57):

Getting on a map, getting a group people to create it, and then simply looking at it and asking, how does this help us?

Adam Furtado (01:01:05):

Yeah. Thanks. Brian, same question to you. What's the one thing that our audience can take from here?

Bryon Kroger (01:01:14):

Well, first I would say the first time you try to do a worldly map, it will be very difficult, partly because you got to learn the tool, but also because as Simon even points out about himself, the first time he was embarking on it is you actually don't have good strategy or the good components to create a good strategy. And so there's just a lot of work to do and it's easy to get discouraged. It's no different than folks that have tried OKRs, which should theoretically be even simpler than mapping out your organization's strategy, but somehow the first time you try to do OKRs with a large group of people, it's incredibly difficult and it takes several quarters to get into a good rhythm. And I would say, in fact, actually, let me see if I can share my screen really quick. I might not be able to because I've gotten jamped recently.

Adam Furtado (01:01:57):

CMMC, baby.

Bryon Kroger (01:01:59):

All right. Can you see it?

Adam Furtado (01:02:01):

Yep.

Bryon Kroger (01:02:02):

So this is an example of a Figma board that we use when we do wordly mapping, but one thing Simon said early on is taking a bunch of different people's perspectives and putting them together. So I'm not going to zoom in on this because I don't know what's on this particular board. I know none of it's sensitive, but I still want to be careful. But you can see each of our teammates did something from their perspective. And I see several engineers on here, a product manager, a UX designer, I see a security person. And taking all of those perspectives and putting them together is really going to help you because if you try to do it yourself, you will get something that is not comprehensive enough. This is another path to prod example actually as it turns out. And so it's really important I think to work through this with a team with a really good format.

(01:02:53):

If you're used to work shopping things or whatever, a Figma board can really help you. So that's just like a super practical tip. I'm going to stop sharing that. And then I'll just say this is more meta. This is like government thing that they should pay attention to. I love that Simon brought up the pioneers, settlers, town planners or explorers, villagers, town planners. Josh asked a question in the chat earlier that he said part of the dilemma is that most of government and much of industry is optimized for mass, not maneuver. And I would say a representation of that is a large population of town planners. And then what's interesting, I don't know how I'll cage maneuver here, but you see this in the military in particular where you have conventional forces and special operations forces. And I would put those at the two ends of the spectrum.

(01:03:42):

Conventional is very much town planner. Special forces is like the pioneer or explorer. What I see missing always are the settlers.

(01:03:52):

And in fact, the way we incentivize and the storytelling, we tell really great stories about those two groups and we forget that you need somebody to go from, if I use the special operations, they go in and do surgical position. Turning that into a military base is like its own art. The people that run bases can't make that transition happen, neither can the special operators. And so you need a separate set of people with, as Simon said, different skills and different attitudes. And if I look at the Kessel Run story, I very much view myself as that kind of person as a settler. And we had the person that kind of established it, the pioneer that was like Enrique Odi. And then Lieutenant Colonel Sanders was a great example of like, I would say a forward leaning, but nonetheless town planner. And it took all three of us to discover that new territory, settle it and turn it into something that the enterprise would accept.

(01:04:49):

And I think government would do well to look for more of those settlers and incentivize them.

Simon Wardley (01:04:55):

So back in 2005, my original name for the settlers was The Missing Middle because I'd organized myself into a cell-based structure and I had the innovators and commoditizers type grouping. And of course that just created more warfare within the organization, conflict within the organization because they would just pull poles apart. And by breaking the organization into those two sort of streams of innovators and commoditizers, I literally extinguished the all essential middle, which was doing the transition, which I wasn't aware of. So my first attempt at messing with organizational structure, well, most of my first attempts were disasters. And that one in particular was a disaster as in concentrating on the two extremes and distinguishing the middle by not naming it as a team. And that's where the setlers came from because I realized there was this missing middle which did the transition. And so that's where it became Pioneer Settles Town Planners or Explorers Villages town planners because I'm trying to be less colonial.

Adam Furtado (01:06:19):

It makes sense. I always say the key characteristic of a bureaucracy is its ability to withstand change. The whole point of the organizational structure is to be able to withstand things that are coming from the outside.That middle group is like the people who are doing the change management to go from one functional way of being set up to a new one. I think it's a missing skill I think for a lot of organizations. I forgot I was hosting a live stream right there. It has been really a fun conversation. I have a cool job. We got to wrap up. Simon, thanks for coming. We're going to have you back and get a little bit deeper in some other things. If you want more of Simon's thinking, follow my LinkedIn, please. Check out Worldly Mapping. We also referenced about a dozen papers or things that everybody should go read.

(01:07:07):

So we'll compile those and send it back out via LinkedIn and those of us who are following us there.

(01:07:16):

If you got something else out of today, go check out the Mission OS course, the live streams that are posted on our website. Brian walks through a full operating system for shipping outcomes to production inside government. And it's really the foundation for everything we talk about in this series. We'll drop that link too. And just a quick tie, four weeks ago maybe, Brian and I were on this same channel talking to Paul Rainer about domain driven design. Another sort of skill that helps you kind of navigate complexity in a way. So there are a lot of skills that we're trying to espouse here and we have some tools available. So utilize those resources, try to make your life a little bit easier. We'll see you on our next Mission OS live stream on Friday, July 24th. We're really excited about this one. **** Kirsten's joining us, who's a friend of ours as well.

(01:08:01):

And his new book, Output to Outcome and Operating Model in the Age of AI comes out next Tuesday, July 14th. Go pre-order. It really helps the authors out if we pre-order books before the release date. So go on Amazon or wherever you buy your books and do that. And then one last plug before we go. Prudacity is coming up August 25th through 27th in Nashville. If you are leading or part of a government software program, there's no other event like Prudacity. It's the annual gathering of experts and practitioners who care about one thing, getting mission outcomes into production. So you'll hear from those experts. You'll walk out with a literal playbook of the tactics and resources needed to navigate the uncharted terrain that we all find ourselves in. So please take a look at that on our website. We hope to see you there. We went long.

(01:08:47):

This was great. We're bringing Simon back. That was a lot of fun. Thanks everybody for coming.

Simon Wardley (01:08:51):

Pleasure.

‍