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 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:08] 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. I'm going to start with 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, I was 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:16] 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 tackle. 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:54] Allan Stewart: Right. And so the other question that Wardley was talking about. And I think he 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? Like 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 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, you 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, somebody else comes along and says, oh, well, I'm going to be like them. I'm going to move. Pawn, pawn, queen. Well, where's my checkmate? 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 what the terrain is very critical to your success. Sometimes the terrain helps you. Sometimes the train 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. Yeah. At the executive level.

[00:06:12] Allan Stewart: Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. 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 very visual creatures. Not, you know, notwithstanding some people do not have that particular ability, but in general, humans can be very visual. We, you see it in words like see, we have phrases like that that are visually oriented. And in addition to being visual, a map is context 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 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 are things on the map? And then an anchor, which is your reference concept. So on physical maps, like if we're thinking about like maps of areas, of territories, that's usually the compass rows, right? 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 whatever the stuff is that is relevant to this map, those are the components.

[00:08:21] 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. This goes off to the Northeast and there are six stations all in a line. Well, if you overlaid that and looked where on like Google 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

[00:10:08] Dave Adsit: destination. Yeah. The critical thing about building a good map is knowing what 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. So that brings us to

[00:11:10] Allan Stewart: the Ward's And a Wardly 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. So 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, right? So that would be more invisible. The anchor that is your reference concept, like the compass rose, is the user. Typically in a Wardly 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 they utilize directly? And the chain that goes from that visible need to all the invisible things that require it, right? So 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, going back to things like power, right? There has 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 Wardly 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 to, anchored to your user, then you can start making some decisions about things like, are you going to build versus buy? Are you going to build versus buy? 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, like, okay, we're going to, so let's just take an example of something like databases, right? There's initial idea 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, now you'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. Every cloud provider has some hosted database service these days. So you can just plug in and 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. We're using it directly 06.03 for a purpose. 06.03 Whatever 06.03 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. 06.04 Having the database allows us to create a SAS 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

[00:18:21] Dave Adsit: somewhere in your house. 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 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 your own

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

[00:19:36] Dave Adsit: Yeah. And so AOL, that's a product. You get an AOL disk, 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 Wi-Fi

[00:19:56] Allan Stewart: as opposed to internet connectivity. Yeah. And everything just continues to build upon each other. And like every technology that I've thought about follows the, same things, right? You could even say something like, oh, the wheel. And I don't know if we have a lot of early history understanding of the wheel, but we see these progressions, right? 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 then over time, it starts becoming a product. It was like, there's somebody who's, 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 a 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.

[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 like there are very specific things about, you know, the rims and how many lug nuts and all these things that, that happened to it because we, we understand that space much more than, than we did in the past. There's other, you know, lots of different examples, right? Electricity, you go from like 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 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:45] Dave Adsit: I think 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. I don't think about cloud in terms of VMs and OSs and 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. You're 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 Wordly Maps is that practices co-evolve with activities. So the Wordly 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 it. 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 problem. That didn't make sense in the days when you were running your own servers in the Kolo. 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 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 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 there's tons of products now right you can use cloud code you can use 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

[00:27:01] Dave Adsit: energy 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 and that highlights

[00:27:22] Allan Stewart: this concept uh in a worldly 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 uh and if you're looking at a worldly 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 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 of places because they're a commodity well and specifically you know you're 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, 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 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, as the thing that they were doing as a product becomes commoditized. And this is as we, as we talk through this portion of it, you can start to see where these things start to play into strategy, right? If you, if you are building something let's just say that you're building a mobile app or a SAS 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, a photo photo sharing apps were a product and you would go and you'd, you'd get this. This is what I'm going to store your photos. It might be able to print off your photos. Like there's, 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 worldly 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 you know, somebody displaced. Welcome Welcome Welcome Welcome Welcome Welcome Welcome Welcome Welcome Welcome Welcome Welcome Welcome Welcome Welcome Welcome Welcome Welcome Welcome Welcome Welcome Welcome Welcome Welcome Welcome Welcome Welcome 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 know, 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 Claude script. 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? 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 us? And what actions are we going to specifically 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 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 us 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 the leap into a more robust, scalable product. You can make money as an ISP, right? 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, right? Like 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. The question is, where do I work? On the map. So people working in the kind of the top left of a Wordly 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. Wordly refers to these people as your pioneers, right? They're the people who need a skunkworks because just give us a bunch of money and we're going to create it for the first time. 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 really need is a Kanban board as they're figuring out, hey, what is the next thing that we're going to build? How 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 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. Right. 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? Right. 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 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've come up with new battery trains and new 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? 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, 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, we've just got a couple things on some kind of 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:53] 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 trade offs. If you ask the LLM, write me a new, write me this algorithm, or, you know, go figure it out, figure out 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 becomes a challenge. Like, yes, 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, 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. Like 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? 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 a, 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, I thought about how, 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, you know, reasons and, you know, politics around it. But suffice to say, if you take a dependency on somebody else, it'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, you know, I think it's a good one way or another, there's, 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, like left pad, right? That'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, we can just incorporate that. Instead of using left, left pad, the, the product, you know, 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 add 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, or characters, right? Like you can zero, put zeros or something, but yeah, it broke the internet for a couple of days.

[00:44:03] Dave Adsit: Yeah. And it forced a full policy change for NPM. They decided that you can not 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. map, it helps me understand, okay, these things are going to get more and more productized. It's where they're going to go. It's a war. They become more of a commodity and we're going to build new stuff based on those. I've 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

[00:45:58] Dave Adsit: in the money for the company? 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 as a strategy or defining your plan as a strategy 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. What are we going to actually do about it? And so that, that can become the heart of your strategy. You know, it's 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, 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. 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, 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

[00:48:38] Allan Stewart: not have even thought about it. 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 You've got a 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. And that's a strategic decision But it's not likely to be very innovative. Ultimately, then, Wordly mapping is just a tool.

[00:49:27] Allan Stewart: If you go and read up about it, you'll learn a lot more about strategy. You can learn about some of 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 get the right information. And I think that's a great way to give yourself a language and a new way of looking at these kinds of problems that you're facing in your business.