Crafting Code Podcast

[00:00:15] Allan Stewart: Welcome to the Crafting Code Podcast, where we discuss the importance of doing the right thing at the right time with the right tools. I'm Allan Stewart, a software architect, and lately I've been thinking about whether and and how AI coding agents change the context of applicability for some patterns.

[00:00:34] Dave Adsit: I'm Dave Adsit, an engineering leader, and I have recently been thinking about the insidious nature of burnout and how to stay sharp when you are between jobs.

[00:00:43] Allan Stewart: Our topic for this episode is Wardley Maps. Wardley mapping is something that I was introduced to some years ago, maybe five-ish years ago, And I found it to be really helpful for me as I have thought about business strategy and thinking about how things evolve in the technology space.

[00:01:07] Dave Adsit: Yeah, I was also introduced to Wardley Mapping a while ago, and I spent some time with some of the concepts, but I didn't get nearly as deep into it as you have, despite my interest in strategy and having read a variety of other strategy books.

[00:01:24] Allan Stewart: So today we'll talk about Wardley Maps and some of the ideas that are supported or different from other strategy books. But just to kind of give an introduction, Simon Wardley kind of set out to answer the question, what is business strategy? He had this sense, and I have definitely noticed the same thing once I started reading his book, is like, "oh yeah, I resonate with what he's saying, that sometimes business strategy doesn't feel very well-defined." There's a lot of cargo culting that goes on. There's a lot of propping up like a SWAT diagram and say, "oh, well, this is our strategy." But when you compare that to strategy in something like military or a game, it feels pretty weak in comparison.

[00:02:15] Dave Adsit: Yeah, I will definitely agree with that. I have often experienced what I think of as very weak or non-strategy strategies at the executive level. And I've been asked for a technical strategy. And sometimes when I say, "well, this is my technical strategy, or this is my strategy for the engineering department," I've been told, "that's not even a strategy," when I'm pretty convinced that it is. And when I ask what they want instead, they describe something like goal setting or other non-strategy things that somehow fall under the category of strategy in some people's minds.

[00:02:53] Allan Stewart: Right. And so the other question that Wardley was wondering about is like, do business leaders even know what it means? Like what leads to success? Not sure. And he was struggling with it himself, right? It wasn't like he had the answer and nobody else did. It was very much the case that nobody seemed to have the answer, and he was desperately searching for it. So at some point in his quest to figure this out, he read Sun Tzu's The Art of War, or probably a translation of it. And in that, it talks about five competition factors. There's purpose, which is what you're doing and why. There's landscape, which is your environment. There's climate, which are the forces that act on the landscape. Doctrine are the principles you follow regardless of situation, and leadership is how to tackle the battle at hand. And as he read through this and he was thinking about it, one of the things that he realized is that having a map is very important, which is where we get to the Wardley maps. And one of the examples that I really liked to kind of kick off the idea of maps and maps relate to the landscape factor, especially. But one of the examples I really liked is what if you were playing chess without a map, right? You can't see the board. And so you say, "well, I'm just, I'm going to move upon." And, you know, some people get really good at visualizing the board, and we have notation for, you know, move the Bishop's pawn three to, you know, like you're giving the coordinates of what is going on, but the coordinates are part of the map. If you don't have the map and you don't have a visualization of where the pieces are on the board, you just have this kind of vague ideas. Like, "I've got some pawns, I've got some knights and a queen." And so then you start getting into these strategies, like the winning strategy is you move pawn, pawn, queen, checkmate. You just won the game. But if you, if you can't see the board you don't know why. You don't know why that happened. And so then somebody else comes along and says, "oh, well, I'm gonna be like them. I'm gonna move pawn, pawn, queen. Where's my checkmate? what What happened?" Because they're just playing completely without any context of where are things in position to each other and potentially even like which pawn are we even moving?

[00:05:40] Dave Adsit: Yeah, I've played quite a few strategy war games with Civil War soldiers or mechs or whatever. The terrain is very critical to your success. Sometimes the terrain helps you. Sometimes the terrain hinders you, but just ignoring it completely is going to lead to defeat in almost every case, which feels very similar to the types of things that you get in poorly defined leadership strategy sessions at the executive level.

[00:06:13] Allan Stewart: Exactly. So Wardley thought about this, and he's like, "okay, well, there's definitely some analogies here, you know, some similarities. So how can I create a map?" Which got him thinking about, first of all, well, what even makes a map useful? Well, one thing is it's visual, right? We can look at it, and we're visual creatures, notwithstanding some people do not have that particular ability, but in general, humans can be very visual. You see it in words like sea. We have phrases like that that are visually oriented. And in addition to being visual, a map is context specific, specific which means that you've got the right kind of map for the kind of thing that you're trying to do. If you are trying to get directions of how to get to a particular location and you're given a heat map, that might not be super useful. But if you're given, if you're given a topological map, well, maybe it helps a little bit more. But the street map that shows traffic, that might be the one that you're actually after. It's the most useful. Position is also very important where where are things on the map? And then an anchor, which is your reference concept. So on physical maps, like if we're thinking about maps of areas, of territories, that's usually the compass rows. It gives you an anchoring concept so that you can position things relative to each other. So we can say that this building is north of this other building and a little bit west. And you can position things. And then once you can position things, then you can have movement. Things are changing position on the map. And then the things themselves are components, right? What belongs on the map? Are they buildings? Are they streets? Are they little fighting men that are on your map? Whatever the stuff is that is relevant to this map, those are the components.

[00:08:22] Dave Adsit: So one of the things that this makes me think about is in business strategy, if you are not talking about your competition, you do not actually even have a good strategy. You don't have a strategy. You have, at best, a bad strategy. And so as it relates to the map, I want to see who else is there. Not just my troops, not just what we're doing, but I want to see what else is there. So I think that's a super useful concept that Wardley is bringing to mind for me.

[00:08:52] Allan Stewart: Another aspect that's important to think about maps and definitely applies to Wardley maps is that the map is not the territory. And so there's going to be a certain amount of inaccuracy, and there's a degree to which we actually enjoy this. And we say, "this is actually a good thing." If the map that you need to get across the United States is as big as the United States, it's not very useful. If the map is very precise about certain things, it might actually hurt the utility of it, which is why when you look at subway or rail maps, they will often have things shown in straight lines. Like, "this goes off to the northeast and there are six stations all in a line." Well, if you overlaid that and looked where the actual stations are on like Google Maps, maps, for example, you'll probably find they're not in a straight line. The tracks actually curve. They turn. There are things that happen there, but it's close enough. You don't need that level of detail because you're just sitting in the car. It doesn't matter if you turn to bend or not, because you're going straight, quote unquote, straight towards your destination.

[00:10:09] Dave Adsit: Yeah. The critical thing about building a good map is knowing what information needs to be present and what information can be abstracted away or ignored entirely. I am reminded of the Mercator projection of the globe, which is how do you put a curved world onto a flat map? And then you end up with weird things like Greenland looking like it's bigger than all of South America. Greenland is actually quite small, but in the projection, it shows up far away. And the whole purpose of that kind of map is to make it easy to navigate a ship across the ocean. It shows your latitude and your longitude. That's very critical. If it didn't do that well, it would not be a good map for its purpose. And so, yes, maps have, they have to be fit for purpose, and they don't have to be fit for other purposes that, you know, would make them more complicated or, you know, hard to use. Yeah, exactly.

[00:11:08] Allan Stewart: So that brings us to the Wardley maps themselves. A Wardley map, and our listeners should really go. If you're not already at least somewhat familiar with these, go and look at some, uh, just type in Wardley maps into your browser and, and find a bunch of examples, because this is an audio podcast, and maps are a very visual thing, but I'll describe it a little bit to give you some of the ideas, some of the concepts behind it. So first of all, they're visual, and a Wardley map, instead of being, you know, what land or water ocean is there, northeast, south and west. Instead, it's a grid that has two axes. Along the bottom usually is the axis of evolution so things moving from genesis into a custom built, to when it's a product or something you could rent, to where it becomes a commodity or a utility. That's one of the axes. And then the other axis is, how visible is this need? Is this something that you use directly, or is it something that is used indirectly? An example of that might be something like compute. If you In order to do your computations, do you have the computer right here on your desk, and that's a direct visible need? Or is it something that you're renting from a cloud provider, and you don't even know where the computer is, and it's virtualized? So that would be more invisible. The anchor that is your reference concept, like the compass rose, is the user. Typically in a Wardley map, you say, "hey, what are the needs according to my particular user, right?" The kind of customer that I am trying to build software for, if you're doing software like I do. The components on the map are things like, what are the customer's needs? What things do do they utilize directly, and the chain that goes from that visible need to all the invisible things that require it, right? So like if they have the computer on their desk, like I said before, then that's more visible. If they're using compute in the cloud, that might be more invisible, but there's still a chain from that, like going back to things like power, right? There has to to be electricity in order to run the computer, whether it's that you plugged it into the plug in the wall at your house or some data center somewhere that needs power. Then we have position. So the position is along those axes, right? How visible is it? How novel and new versus commodity is this need? And then finally, the movement. In a Wardley map, things always move from Genesis toward commodity. And we'll talk a little bit more about evolution in a minute. But that movement becomes important because then this gives you that ability to see where are things going. And once you place your components on there and you know where they are referenced anchored to your user, then you can start making some decisions about things like, are you going to build versus buy? Identify what kinds of strategies you want to start engaging in to meet the user's needs so that they will continue to pay you for the service or software that you're providing. So the next thing we should talk about then is the evolution, because the movement of these things along the map is probably the thing that was most useful to me. Like, I've got the most utility out of it. And competition is a driving force here, moving things from left to right. So at the left is your genesis. This is where something happens new for the first time. And when somebody creates something and you go through this from genesis into custom built, it's like, "okay, we're going to, so let's just take an example of something like databases, right?" There's initial idea of of creating a database and somebody created the first database somewhere. And if you wanted a database, like we probably didn't even have the word for what a database was yet. And so there wasn't really even a way to really communicate it. But as it grew, this idea started happening, but you couldn't just go get one. You couldn't ask somebody for one. You couldn't pay a company for one yet. You had to build your own. That's the custom built section as you're going from Genesis, and they're custom built. And then eventually people build some, they become reliable, and it becomes a product. And you can say, "oh, well, hey, we're willing to do the hard work of building a database so that you can have one, so that you can use one. And we'll rent it to you or we'll sell it to you. We'll put some licensing agreement around it, whatever." Now it's a product that other people can make use of. And eventually it becomes a commodity, right? Every cloud provider has some hosted database service these days. So you can just plug in and say, "hey, I need a database. Please give me one." And it's there. As things move further to the right, they become more available. They become more stable. We understand them better. We can make them more efficient and we can build upon those things. So when we have the very first database and it's just in the genesis, there's not very much that we're building upon there, right? Like, we're using it directly for a purpose, whatever reason that we had to create a database. But as it moves along that path towards commodity, we can start building on top of it. And we're no longer building the database for itself, but we're now renting or creating a virtual database in the cloud in order to do something else. Having the database allows us to create a SaaS application on top of it, for example, which is something new that we couldn't do before or we couldn't do in the same way. And so as things move to the right, it enables us to, like, it opens up the opportunity for us to build upon those things to create new value that we couldn't have before. And those commodities become less and less visible over time, right? So they move down the vertical axis away from visibility towards invisibility because you're not thinking about those. Those are just details. Just in the same way as if you buy a new phone, you don't think about, "oh, well, how am I going to power this phone?" The power is a utility and you're just going to plug it in somewhere in your house.

[00:18:22] Dave Adsit: Yeah, it makes me think about things like, "I don't need to buy an Oracle or MySQL database as a product. I just need relational data store. And I don't care which of the many technologies it's built on. In fact, I'm going to build my app." It changes your mindset of like, "this is an Oracle application. And Oracle is the heart of it, is the core of it." When you and I talk about data storage, we talk a lot about, like, being storage agnostic, being data store agnostic. It doesn't matter if I put my database in or my data, I care about the data, right? I don't care about the database. I don't care if it's Postgres or MySQL or MS SQL. It's just a relational data store. And the same could be said in your example of we need databases to enable SaaS. Well, we also need internet to enable SaaS. Early internet was AOL, and that was a product. And now, well, actually before that, it was like dial up a BBS, right? You custom built

[00:19:24] Allan Stewart: your own internet. And before that, there's genesis of, you know, some guys at, where was it? UC Berkeley playing around with how they can connect computers up, and how can we build this

[00:19:35] Dave Adsit: ARPANET thing? Yeah. And so AOL, that's a product. You get an AOL disc, and now you have the AOL product. And now we're at the point where internet connectivity is commodity, maybe utility. I don't think about it unless it stops working. In fact, we don't even call it by its correct name. We call it the wifi as opposed to internet connectivity.

[00:19:59] Allan Stewart: Yeah. And everything just continues to build upon each other. And like every technology that I've thought about follows these same, same things, right? Like you could even say something like, "oh, the wheel." And I don't know if we have a lot of early history, like understanding of, of the wheel, but we see these progressions, right? Like, you know, you don't have to make your own tire for your car anymore. At some point in history where you couldn't buy a cart or a wagon, you would have to fashion your own if you were going to have that. And over time, it starts becoming a product. It's like, there's somebody who's out there, right? You know, you have somebody who knows how to build wagon wheels, And they build a whole bunch of them for wagons. And eventually they become utility, you know, or commodity where you can just hop on Amazon and say, "hey, I need some tires." And I'm sure they'll deliver them to you.

[00:20:56] Dave Adsit: Well, and we're moving to a point where moving from point to point or transportation is becoming commodity. You don't even need to buy a car anymore. You just call a Waymo or an Uber. Exactly. And it moves you and you're good. Right.

[00:21:09] Allan Stewart: Right. And the wheels become more invisible as they go along. And also as things become more commoditized, we understand them a lot better. We have a very good understanding of what is required. If you were going to create a custom wagon wheel, well, then you have to answer some questions about like, well, how big does it need to be? How many spokes are they going to be, et cetera. But now tires are built towards specifications. And there are different sizes, but there are very specific things about the rims and how many lug nuts and all these things that happen to it because we understand that space much more than we did in the past. There's lots of different examples, right? Electricity, you go from your Parthian battery until it's finally something you get from the power company. It's gone all the way from, here's this novel thing that we don't know what to do with, to everybody does that. And then that enables computing, and computing goes from the first computers that were built, and they needed electricity. And then we were building these custom, huge machines that take up an entire warehouse. And then IBM is shipping personal computers, and you can buy your Apple II computer. And then eventually you just say, "hey, I don't even want the computer anymore. I just want computation to happen. And I'm just going to rent the computer." And then that enables your databases and going through that whole flow that we've been talking about as we're building up more and more on these technologies.

[00:22:44] Dave Adsit: I think it becomes, it's interesting that as things evolve from originating from Genesis through commodity, the closer it gets to commodity, the less you think about the actual thing and the more you think about the capabilities that it grants you. Like, I don't think about cloud in terms of VMs and OSs and, you know, patching things and whatever. I think about it in terms of compute and network and storage. That's what I'm buying from a cloud is the ability or the opportunity to not think about the details anymore and only focus on the thing that I'm getting from it. Absolutely. Oh, and also, you don't tend to notice your commodities until they're unavailable for some unknown reason, because it is unlikely that they will become unavailable. You know, they're just ubiquitous. They're there all the time. Exactly.

[00:23:45] Allan Stewart: Another key concept with Wardley maps is that practices co-evolve with activities. So the Wardley map helps us understand and predict what practices we should use over time as we see things change. And as technologies move toward the right, we change our practices. A good example of this is that it used to be that the old best practice for hosting your website was to scale up your hardware in a custom built data center, right? You're buying more RAM, more storage, better your CPU, because that was the thing that made sense at that time. If you wanted a server, it had to be in a rack somewhere. You were maintaining that. You had to do it. It was custom built. You had to create this yourself. But cheaper hardware allowed us to start scaling out these changes as components for computers progressed. And we got better at creating them. And you could buy a cheaper machine. Well, we'll scale out. Until finally we get to the point where we're at cloud computing and we've commoditized all the computing resources. And so now horizontal scaling becomes the new practice. That didn't make sense in the days when you were running your own servers in the colo, right? But it becomes practical and the practices shift and change as things move towards the right. And then that in turn enables new innovations, right? So like once, once all this computing was a utility and you didn't have to buy all these servers, then we start coming up with these concepts like serverless. And when you have serverless and you're just saying, "hey, I don't actually have to own the computer. I'm not, at this point I'm not even paying for a virtual machine. I'm just paying for, uh, functions or lambdas or compute seconds, compute seconds." And then now all all of a sudden we have new practices, right? Like there were practices around how we paid for our hardware in the past that don't make sense anymore. Now we're paying based on usage instead of paying for dedicated machines. And so these things evolve and change. Recently, I've been thinking about this a lot with AI. AI is moving into the product space rapidly, right? Like this, LLMs are a technology that are just desperate to get over to the commodity space, it seems like. And as they move through, you know, and there's tons of products now, right? You can use Claude Code, you can use the Codex, you can use Copilot. There's lots of different ones in this competing area of all these products that are opening up new possibilities. Things that you could not consider before are now possible because you can rent or at some point maybe even have a, you know, a utility for these LLMs as opposed to before when they were just in Genesis, you can't really build on that because building the thing consumes all of your time and energy.

[00:27:01] Dave Adsit: Well, and that's really interesting, because one of the things that characterizes commodity is that the margins are low. And so there is effort sometimes put in to continuously innovate in order to stay in that higher margin product space. Absolutely.

[00:27:21] Allan Stewart: And that highlights this concept in a Wardley map is that as things are evolving, there's always inertia and war at the boundary from product to commodity. And that's basically representing, and if you're looking at a Wardley map, it's usually drawn as like a thick black box, like a wall that's preventing a thing from leaving the product space and going into the commodity space. Because of exactly that, businesses are invested in these products, and especially the product creators are very invested in. They want you to use their thing. They're all about differentiation and why you should use their product instead of somebody else's product, and they, they don't want to let go of it and have it become a commodity that is well understood and that you can pick up at any old place, right? They want you to come to them, not just to any cloud provider, right? Like, where can you buy batteries? I mean, you can get them at the 7-eleven down the, down the street, right? You can get them at grocery stores. You can get them at all kinds kinds of places because they're a commodity.

[00:28:30] Dave Adsit: Well, and specifically, I can get the three batteries that I use the most of, double A's, triple A's and CR 2032s or whatever they are. The little button cell batteries. I can get all of those anywhere I go. Any retail establishment

[00:28:44] Allan Stewart: has those. Right. And I don't have to think about it. So there's all this war that happens there because people want it to be a product, and they want you to use their product. And so there's this fighting. There's also inertia where people think, "hey, this is how things work. This is how we've always done it." And as new things start appearing, being built upon the old, there's inertia. People don't want to change, right? So when cloud computing first came out, there's a lot of people who were sticking by their data centers and their co-locations, saying, it's like, "oh, oh, I don't know about this fad about cloud computing." And even once it was a thing, like there's still a lot of laggards that, because of this inertia, we're still operating in old ways, using their co-locations and not evolving to new practices as they go. And a lot of businesses that depended on, it's like, "oh, well, we're co-location. That is our service. That's what we do." They have a ton of inertia inertia because they don't want to go out of business. And so they have to either pivot and become something else, or they die as the thing that they were doing as a product becomes commoditized. And this is, as we talk through this portion of it, you can start to see where these things start to play into strategy, right? If you are building something, let's just say that you're building a mobile app or a SaaS product. And the thing that you provide is becoming commoditized, right? There's lots of other products that are in your same space, and everybody wants to do it, right? It used to be that, you know, photo sharing apps were a product, and you would go and you'd get this. I'm going to store your photos. I might be able to print off your photos. Like, there's these things that happen. And now we just kind of dump all the photos in the cloud, right? It's become it's become much more commoditized. And so that starts playing into strategy, business strategy. What are you going to do? If you notice that the things that you're doing are moving further and further to the right, it incentivizes you to think, how can we pivot? Is there something we can build upon that is new, that is novel, that other people don't have so that we can continue to provide value to the customers, continue to be bringing in money for something that we do that you can't just pick up at the 7-Eleven.

[00:31:15] Dave Adsit: Yeah. One of the things that I am thinking about a lot is how other strategy frameworks apply to Wardley Maps. And I think more than anything, they talk about what is happening on the map, and how is the map changing, and what can you do to affect the way the map is changing for you, right? Do you want to move into a commodity space and get commodity? I mean, commodities are stable. And so you're going to get that two or 3% return every year until somebody displaces your commodity. Or do you want to do something different? Do you want to play in that more innovative product space? Do you want to be closer to a custom build? Your strategy might be, where do you want to play along this evolution space? Do you want to build something and ride it out from Genesis to Commodity? Or do you want to be continually jumping to the next thing as something that you're doing that's a custom build becomes a product? Do you get out of that space and decide to create the next custom build? Or are you building products that you scale your organization up to operate in a product space until the thing you're doing becomes commodity? Recently, I was introduced to a fairly snarky website that asks the question, "is your SaaS business actually just a Claude script?" And it reads all your marketing material and then makes the decision about whether or not a user of Claude could replace your entire SaaS product for their own personal use with a ClaudeScript. And it's pretty snarky, but it's a legitimate question of, like, do you think you're playing in the custom build space or the product space when really what you're doing has become commodity? Commodity and so, you know, it's an interesting question to ask as someone who is guiding a team like, where do we want to play? How do we want to play? What, what is the, in another model, like, what is our diagnosis of the current state of things, and what is our guiding policy for how we want to approach the challenge we see in front of us, and what actions are we going to specifically take take either to push something from the, you know, the Genesis through its custom build phase into product. And then we might get out of it. Or if it goes all the way to commodity, we might get out of it when it becomes a commodity. You know, those are all questions you have to ask yourself about your business strategy and your technical strategy. A lot of times when it comes to a technical strategy, I want us to be consuming things that are in the commodity space and building a product that we can scale, or perhaps doing a custom build for a few customers in the hopes that we can make the leap into a more robust, scalable product.

[00:34:25] Allan Stewart: And there are viable strategies for many different ways that you can go, right? You can make money as an ISP. They are a utility at this point. And if you're a good one, you can make money off that business. Or you can try to make money creating the next Wi-Fi standard. There are choices that you can make. And you can decide which way do you want to go. Do you want to be in the utility commodity space? Because there's money to be made there. But you have to operate differently. And related are workers. The kind of workers we need might depend on where that work exists on the map. So people working in the top left of a Wardley map, where things are very visible, and this is the genesis, this is the custom built area where, "hey, we're creating it for the first time." Wardley refers to these people as your pioneers, Pioneers, right? They're the people who need a Skunk Works because, "just give us a bunch of money and we're going to create something new that you've never even seen. We don't even know what it's going to do or how we're going to productize it, why people would pay money for it, but it's cool and it's neat and we're building it." In more of the middle of the map are the people who Wardley refers to as the settlers. And a lot of these are in the product space where what they they really need is a Kanban board as, as they're figuring out, "hey, what is the next thing that we're going to build? How are we going to differentiate ourselves?" What we've got a product that we're selling. And so it's understandable enough now that people say, "oh yeah, I want one of those, or I would like to be able to do that thing. I need that service." And we're building it out. We're not at the pioneer level of inventing something for the the first time, but we're still, we're still settling the area. We don't know. We're not to the point where we're building city infrastructure because that's, that's more of the bottom right of the map. Things that are more hidden that are commodities, utilities. This is where you've got your town planners. They need specification documents, right? They need to know how much load can be on the grid at every given juncture or how wide do the roads need to be in between the buildings? What zoning things are we going to put up? Which the settlers didn't care about, and the pioneers were just like, "what's a road? We've followed deer trails here. I don't know." And this helps us with build versus buy decisions. If something is a commodity, then you look at buying it. Why build a new one, your own? You want to build the, the custom built stuff should be new novel ideas, because if you're, and that's not to say there's not space for evolution of these things, right? If you, if you've come up with new battery technology and it's way better than the lithium ion ones that we have now, well, then you could make some serious money. But if you're just going to build another lithium ion battery, like, why are you doing that custom? Unless you want to be in the battery making business. Meanwhile, things that are in the product space, they're the kind of the tricky ones where you have to look at, where is it positioned between custom built and commodity? How close are we getting to the war zone? What kind of inertia is there going to be? Is this something that we expect is going to fall apart in a few years? And so building this as a product doesn't make sense because it's rapidly becoming a commodity? Or is it something that is going to be around for a while? And we have our own novel take on it, and we can differentiate ourselves well in that product space. So looking at where things are at and where things are heading, and not just the thing you're building, but the components that chain back from your user need, and looking at how they are moving can help you make these decisions. In a much better way than, you know, we've just got a couple things on like some kind of like architecture diagram. But you don't necessarily have a sense for, well, why would we build this one or why would we buy that one?

[00:38:52] Dave Adsit: This is really interesting to me because I recently had a conversation with a developer who was saying that the new AI code generators, the LLMs, are going to completely disrupt open source coding. Because I don't have to go find the right open source library and pull it down with all of its dependencies anymore. I can just ask the LLM to write a function that does the one thing that I needed out of that library. And as I think about it, you're making tradeoffs. Mm-hmm. If you ask the LLM, "write me a new, write me this algorithm or, you know, go figure out the, the Raft algorithm and write it for my applications." Like, "okay, that's possible." Or you can say, "hey, I want cryptography in this app. Go figure it out from scratch." And that, that becomes a challenge. Like, yes, you, you have chosen to move into the custom build space. Custom build has some advantages. Things are very narrowly tailored to exactly the problem in front of you. However, they're not necessarily battle tested. They're not necessarily super robust or reliable. And so maybe I would rather use an open source library that's more of a product that's been tested by 100,000 developers or 100,000 users or whatever. Or maybe for my data storage, I want to use an open source database that has been used by huge companies for the last 20 years to store all kinds of data and has proven itself to be reliable to the level of commodity. And so, again, this is like, can I do it? Yes. Should I do it? Depends. Where does my company want to take on risk? Do I want to take on the risk of rewriting the functionality of an open source library myself, or do I want to leverage something that's been looked at, tested, validated by many, many, many, many users? And so maybe for part of my application, I'm going to do custom build. If I'm building custom software, if I'm building software, some of it should be custom build. If it's all commodity off the shelf, then why does my, why does my company exist? Right. But at least the way I put things together is unique to us and how we want to approach a problem. And some of this stuff I'm going to pull in is going to be productized. It's going to be effectively a product, even if it's an open source product. And some of it is going to be so routine that it's reached the level of full commodity. And so it does. It's interesting. To use that as part of build versus buy and apply that to the new capabilities that we are getting from the LLMs as they become productized as code generators. Exactly.

[00:41:54] Allan Stewart: As you were talking about that, I thought about how useful it is to have a good battle-tested solution. But I also put in mind of the left pad debacle of some years ago where this NPM package that a bunch of people relied on went away one day. And there's a whole bunch of reasons and politics around it. But suffice to say, if you take a dependency on somebody else, that's a different trade-off, right? So being dependent on the battle hardened package might be a good trade-off in some cases, but not necessarily all cases, and something that is as trivial as left pad. Well, maybe it's just better to let the AI write that for you as part of the work that it's doing, because then you're not beholden to anyone. You don't have a supply chain attack risk. You can just create the thing yourself. And so one way or another, there's a risk trade-off that you have to make there. And understanding where things are at in the Wardley map can help you make some of those decisions. As you look at, like, left pad, right? It's very low in the visibility space. Like, people don't really think too much about it. But it's also not very complex. The spec is easy to understand, and we can just incorporate that. Instead of using left pad, the product out of NPM, we've kind of commoditized it through the AI of, just write that functionality for us.

[00:43:36] Dave Adsit: And to be clear, for those who are unfamiliar, left pad is a JavaScript function that takes text and adds spaces on the left side to pad it out to a certain length. That's the functionality that broke the internet for a day.

[00:43:53] Allan Stewart: Or characters, right? Like, you can put zeros or something. But yeah, it broke the internet for a couple of days.

[00:44:03] Dave Adsit: Yeah. Yeah. And it forced a full policy change for NPM. They decided that you cannot unpublish your open source project once you've put it out.

[00:44:15] Allan Stewart: So that's the basics of the map part of Wardley mapping. There are a bunch of other things that we won't go into here where he talks about things like climate, how things move, the doctrines and practices that you follow as a company, the, what he calls the why of purpose versus the why of movement. There's different categories of of business strategies that you can, that you can use, and he, he discusses them, and he talks about where things fall on the map, when this makes sense to use a particular strategy. He talks about diffusion and evolution curves, the Red Queen hypothesis, predicting and anticipating change. There's just a whole bunch of other things in Wardley mapping. But in short, being able to look at one of these maps and read it, for me, has brought a lot of value in being able to judge where things are at. So when I think about technologies, right, I look at what's going on in the AI space, and using the lens of a Wardley map, it helps me understand, okay, these things are going to get more and more productized. It's going to go to war. They become more of a commodity, and we're going to build new stuff based on those. I found it very valuable. I've built a couple maps to help me understand the companies that I've worked at. And I feel like it's given me a perspective to help me understand what kinds of decisions should I make inside of my company? Where can we differentiate? Where can we provide value to a user, which ultimately is the thing that brings in the money for the company?

[00:45:59] Dave Adsit: One of the things I really like about this is that it plays very nicely with other strategy research that I've done. For example, the strategy books that I've read recently make the assumption that you understand the landscape, including the competition that you are working against. They also talk about extensively about what is bad strategy, and wardley maps do not seem to have any of the characteristics of bad strategy, things like defining your vision or your as a strategy or defining your plan as a strategy or looking or including a bunch of fluff. Wardley is very precise and technical. It does not have room for a lot of fluff. The text states, "gibberish masquerading as strategic concepts." There's none of that in Wardley. Also, a bad strategy will fail to face a challenge. Wardley puts the challenge right in front of you. "This is evolving. Deal with it." One of the very common ones that I've seen, experienced, been part of is mistaking your goals for strategy. "We're going to grow ARR 10%." That's not a strategy. That's an aspiration. Preparation, what are we going to actually do about it? And so that, that can become the heart of your strategy, you know, things like, diagnose the problem, set your guiding policy, and then create a set of coherent actions that you're going to take. That's the kernel of a good strategy according to some authors on strategy. Deciding where we're going to play, how we're going to win, in what capabilities do we have, and what are we going to do with them? That becomes the core of a good strategy, according to another author. And all of those are encompassed in the concept of the Wardley map. I do think that most of the other strategy authors that I've read have focused more on the evolution phase, making the assumption that you understand the landscape and the competition and what else is out there, all of the pieces on the battlefield. Field. And the reality is you probably don't until you sit down and create your Wardley map. Like, what is, what do we do? What is it? How visible is it? What are we relying on? Imagine if you're building a technical strategy and one of the things that you rely on is in its Genesis phase. Things in Genesis phase, they don't always make it to commodity. Sometimes they just die. And if you're taking on that level of risk, that could be problematic for your organization. And you may not have even thought about it.

[00:48:39] Allan Stewart: Right. Or you might look at it and say, hey, you know, this is going to require a whole lot of custom built stuff and not recognize that you're over your skis on the stuff that you got to custom build and you're not relying enough on things that you could purchase.

[00:48:56] Dave Adsit: Yeah. There's a technical book on software craftsmanship that was written probably 25 years ago now that talks about how software professionals should not rely on anything that's less than 10 years old, which is an interesting strategy, right? That's a strategic decision. That's a strategic decision to only use commodity components. And that is going to result in a certain type of system. It's likely to be very reliable, but it's not likely to be very innovative.

[00:49:24] Allan Stewart: Ultimately then, Wardley mapping is just a tool. If you go and read up about it, you'll learn a lot more about strategy. You can learn about some of and these other things beyond just the map itself. I've found the maps very helpful in understanding and creating technical strategies and seeing where the industry seems to be heading. They're not perfect, but it is a useful tool in your tool belt to be able to give yourself a language and a new way of looking at these kinds of problems that you're facing in your business.