This is a transcript of episode 252 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.
If you want to create a “value flywheel” where success breeds success, you need to start with clarity of purpose. Join Jeffrey and his guest David Anderson to learn how David uses the technique of Wardley Mapping to generate shared understanding. But don’t make the mistake of thinking the map is the point! David says throwing away the map is just as important as creating it in the first place.
Show links:
Listen to the episode on SoundCloud or Apple Podcasts.
Introduction
Listen to this section at 00:11
Jeffrey: Welcome back to Troubleshooting Agile. This is Jeff Frederick and once again, I’m unfortunately not joined with Douglas Squirrel. I am recording live from DevOps Enterprise Summit 2022. I’m here in Las Vegas and I’m joined by a guest today: David Anderson.
David: Thanks very much, Jeffrey. Nice of you to have me on, I appreciate it.
Jeffrey: So David and I are here because we’re both authors for I.T. Revolution who put on the DevOps Enterprise Summit. David, you’ll have your book coming out soon, The Value Flywheel Effect.
David: Yes, that’s right. It’s coming at the end of November, it was very exciting to have my hands on the first physical copy just this morning.
Jeffrey: I remember that. It’s quite a weird thing isn’t it, to have it in hand?
David: Yeah, I think I’m still in shock. It’s funny you spend so long working on it and all of a sudden you’re holding this thing, so it’s quite exciting.
Jeffrey: Fantastic. So tell me, how did you come to write it? What was your background that led you to do this?
Recognizing The Dynamic
Listen to this section at 01:13
David: So I’m a software engineer, is my background, and I currently work as a technical fellow with Bazaar Voice. Prior to that I worked in a CTO role with Liberty Mutual, and I spent a lot of years driving our move to the cloud, figuring out how to perform better in the cloud. One of the things that we figured out, myself and my two co-authors Mark McCowan and Michael Riley, was this idea of a service-first mindset, in order to build applications better in the cloud. As we started exploring that, a few people said “You need to write a book on this! This is such a good idea.” This particular agent just kept saying to me, “You have to write a book.” So I thought, okay! And really, as we went through the process of writing the book and distilling and synthesizing those ideas, this idea of the “value flywheel effect” just kept comming up. This iterative way of joining up your kind of business and technical strategy and letting them influence each other.
Jeffrey: So, the value flywheel effect then comes from a cycle with business and technical strategy cojoint.
David: Absolutely. Really there’s four phases that we’ve identified. The first is clarity of purpose. Really for any team or anyone building something, you need to have that clarity of purpose. That could be your engineering north star, your time-to-value metrics, just very clear clarity of purpose. The second phase is challenge, which is really to create that environment of success, the psychological safety such that people feel they’re in a good place so they can discuss the clarity of purpose and find out better ways of doing it. The third phase is “next best action,” which is really providing a good developer experience and a good cloud environment so teams can deliver quickly. And then the fourth is long-term value, which is really getting into the mindset of problem prevention, having a well-architected mindset. So even though you’re building quickly, you still care about your architecture and your long-term value, and that cycles back around to clarity of purpose. So we noticed that there were certain things that would create friction in that process, maybe organizational boundaries or bad technology, whatever. You could also see that when there’s momentum, things are really turning.
Jeffrey: That’s when you get that flywheel, right? So success breeds success is the idea here.
David: Absolutely. We’ve had lots of feedback over the past two years on the concept. People often ask “Why is it not like a waterfall?” Well, that’s not how the cloud works. It’s like a rocket ship: once you get onto this, it just keeps going. So you really it’s not projects starting and ending, you look for friction points or inertia that will slow you down.
Jeffrey: Right? The Serverless Edge is your website. How does that relate to the value flywheel effect? It sounds like that’s an important element.
Do You Know Your “Why?”
Listen to this section at 04:19
David: Yeah, well back to that digital transformation with Liberty Mutual which is around 2014. The charge I actually had was “We’re going cloud native, how do we build applications better in the cloud?”
Jeffrey: Which is interesting because it’s backwards in a sense. It’s technology-driven as opposed to clarity of purpose.
David: Absolutely. But it all kind of sits together because the purpose wasn’t “We’re moving to the cloud,” the purpose was “We need to embrace cloud native,” right? It wasn’t appropriate to do what we always did in the data center and just move that to the cloud, that wasn’t going to wash.
Jeffrey: I’m going to push on that. Why? Why not? Why do I want to go cloud native?
David: Because you want to be able to have a really tight feedback loop. That way we build products really quickly, get them in the hands of customers, and figure out what happened. To get that really tight feedback loop you can’t be releasing once a month or once a quarter.
Jeffrey: So Cloud native is a means to that end. It’s not the end in itself. That’s why you were saying if you operated the same way you always had but in the cloud, then why bother with the cloud?
David: Gregor Hope puts it really well: if you just migrate your existing practice to the cloud, you’ll have a really nice data center because it’s run by some of the best companies in the world. But all you have is a nice data center. Why not offload some of the operational burden to the cloud provider? So the phrase that we use for that would be “serverless” as in you shouldn’t be in creating servers, installing them, patching them, doing low-level network stuff. Let Amazon or Google or whoever do as much of that as possible, because unless you’re a competing cloud company, you shouldn’t be building cloud services.
Jeffrey: This is fantastic, we’ve kind of ended up then on the first step, clarity of purpose: “Why are we doing this transformation anyway?” It’s not just why, but also a bit of the decisions that you’re making here. Now, we were talking a bit before we started recording, and you were saying one of the tools you like to do this with is Wardley Mapping. Now, I don’t want this to be a Wardley Mapping podcast, link in the show notes to learn more about it, but if I’m in my organization and I’m trying to lead a transformation, what might be a sign that I need to have a Wardley Mapping discussion with people?
When Do I Use the Map?
Listen to this section at 07:15
David: Well, the premise of Wardley Mapping is that every technology and capability evolves. Things will start off in Genesis, it’s wonderful, novel, amazing. This it blows me away. Then the custom build, “We think we can build it,” and then it moves on to product, where there’s customer demand, and it becomes utility or commodity, the price of doing business. It becomes expected.
Jeffrey: Like water flowing out of the tap or plugging into electricity. You’re not building your own generator.
David: Yeah, absolutely. The symptom that clarity purpose is not understood is engineers building things but they don’t know why they’re building them, or they don’t make sense to your core business. One of the interesting tests I would have is if we sit and speak with the VP and we tell them that we’re building a logging framework and spending $1,000,000 on it, will they think that’s a good investment of our money? Will they think “Why are you doing that?” We are not a cloud company. Is there a dotted line from what you’re building to what the president of the business would expect the engineers should be working on? There’s always things you need to work on. So really it’s those two things: you’re building something that you shouldn’t be, or you don’t know why you’re building the thing that you’re building. If you’re building a business function, then you should talk to the customer or the business stakeholder to really understand the problem that that solves. Then as engineers, we can be more creative in how we build that.
Jeffrey: Now, with Wardley Mapping. It’s called that, not “Wardley Map.” In a sense, there’s a focus on the process rather than the artifact. Explain that to me. What’s the point of that?
David: The technique was created by Simon Wardley about 15 years ago, it’s the idea that if someone comes up and says, “We’re going to use Kubernetes to solve this problem,” it’s very difficult to challenge. But if you sat people through the process of mapping the “why” behind that, the decision points and what piece of technology may evolve, what may not evolve, then you start to get a clear picture. It’s just sitting down on a whiteboard or a virtual whiteboard, drawing out your axis, “Who’s our user? What is their need? What does that need depend on?” So you start working on that value chain and then over a matter of time you say, “Well, where does Kubernetes or whatever fit into that value chain?” If the engineer is on the money, it’ll quite clearly solve a problem the customer has. If it’s just a cool technology they want to try, it’ll be somewhere way, way down, like three other things can do that equally well. And usually what I find is the process of mapping that out on a whiteboard means the room will come to the agreement. Maybe “We shouldn’t be building this. This is not a good investment of our time.” Often engineers will say, “Well, there’s a vendor that does this, but we only use 95% of their features.”
Jeffrey: Yeah.
David: “Well, let’s just work out how we don’t need the extra 5%, rather than go in a rabbit hole building a whole new thing.” As engineers we love to build. This mindset is helping engineers build the right thing.
Jeffrey: Right. I want to play this back because we’ve got a couple of things there. One that stood out to me is, as you’re building your value chain here in the mapping process, the depth where thigs appear might be a sign of a misalignment, because for people who haven’t seen it, you start with vertical orientation where the client’s at the top and essentially what you’re saying is the closer they are to the client and their needs, then the more you’re in touch with the client’s real problems. The deeper I get down in the technology stack, the more questionable it is. The less necessary it seems to be for actually solving their needs. Did I understand that correctly?
David: Absolutely. If it’s quite low down on the value chain, it’s still probably really important-
Jeffrey: Like a log-in framework.
David: Yeah, exactly. You need a log-in framework, but do you need the best log-in framework in the world? Do you need to invent one? Or is the one that you can get off the shelf good enough? So you may find that the lower you are in the chain, the more commodity some of the things are.
Jeffrey: Right. So we might we might be inventing some things, we might be making things custom build. But hopefully those are things that are high on the value stream, close to the client and not supporting technologies deep down.
David: Yeah, because if you’re in the business media and you create some fantastic new service for streaming media, that’s going to be genesis or custom build, and because you want to get that into the hands of your customers early you don’t mind maybe taking on some technical debt, but at least it’s what I would call it’s intentional debt that you can then evolve as you learn more. But if you’re a media company and you happen to need something way low down which is not that important, don’t innovate in that. Just get off-the-shelf.
Jeffrey: This is something I’ve been hearing about for a while as “core versus context.” Make investments in your core, things that are context maybe buy rather than build.
David: Exactly. We used to have these conversations maybe 10 or 15 years ago and it was a harder conversation then because we needed to build more things. Right now with the way the cloud providers are putting these managed services, you can have them at the click of a button, pay as you go, and you can change your mind and use the free ones, so you don’t need to invest a huge amount. So really, build what is going to be a differentiator.
How Many Times Do You Map?
Listen to this section at 13:49
Jeffrey: I’ve got one or two more questions, one I really want to focus on is: it sounds like you’re potentially having this mapping conversation with different audiences. So maybe first you start it with your business counterpart and you might create a map and then later you’re doing it with the engineers, development teams. Is that right?
David: Yeah, it’s interesting because from my experience one of the ideas that I would frequently use with mapping is sense-making, trying to make sense of particular value chain. Once you map it out, you start to see patterns and inertia points that you wouldn’t have predicted.
Jeffrey: So we see that I start thinking David Snowden now instead of Simon Wardley when I hear “sense-making,” but maybe that’s just a learned response.
David: Yeah. Well actually they’re great friends and there’s a lot of similarity between their two tools. So I would often use both of them depending what the context is. But in my experience if you’re dealing with executives, sometimes they may not have the time to sit and spend an hour or two mapping a bunch of stuff out. You need to be careful telling a bunch of senior people “We’re going to do this weird mapping thing.” You need to get very good at mapping to invovle senior people because it does take time. With engineers you need to make it very accessible. One of the things wed did with the book to make it more accessible was we almost had grids based on the map. It almost say like we learn like A, B, C, and D, if A was close to the customer; then one, two, three, or four for the evolution. So you can straightaway see if someone is building a component, you could say, “Well, that sounds like it’s-“
Jeffrey: “B3.”
David: Exactly, or it’s maybe higher up, and that’s quite good. Something like D4, that’s commodity down low. You shouldn’t need to build that. So that mental model of “Am I building something that is far away from the customer and commodity, or close to the customer and more innovation or genesis?”
Jeffrey: This is a deliberately naive question: “Why am I building the same map twice? Why don’t I just take the one I made with business to plan things out and take it to engineers and say, ‘Here you go. We’ve mapped it all out.’”
David: “The map is not the territory.” The map is throwaway, you know what I mean? It’s the conversation.
Jeffrey: Say that again?
David: The map is throwaway.
Jeffrey: “But we just invested all this time. We had this expensive meeting with eight, ten people in here. We spent an hour and a half!”
David: It’s the observations from the map that are useful. It’ll be three, four, five key observations from the map. Sometimes what I find myself if we figure out some key observations, when you present them back to the executive team, you may just present the observations. So they may ask “Well, how did you come to that?” Then you can tell the story of why that will happen, and they go, “Oh yeah, of course. Right.” You can sit and speak to the narrative when you present it, you’ve already done the map so you’ve got the picture in your head for that work. Because the observation is key, maybe you don’t separately map both times, but you’re presenting the outputs. With the engineers it’s the mindset around what they have to build, what they don’t have to build. That’s the important concept, and the mapping conversation helps them understand that. I think with engineers, you know you’ve struck gold when you hear engineers as they talk with their teams going, “We shouldn’t build that, that’s commodity.” That’s bingo. You’ve got there. So it’s a different mindset, that engineers understand how their components will evolve, and they use appropriate methods at all points in that evolution. For me it’s the strategic conversation with the executives and the stakeholders, and then being conscious of evolution for the engineers.
Jeffrey: Fantastic. I think I have the title for the episode then, because you have to burn your maps, but you have to make them first.
David: Exactly.
Jeffrey: Well, thank you a lot, David, for being here. What’s the best way for people to get hold of you?
David: We’re all on Twitter at Serverless Age, but please reach out at our website where we collect a lot of our content. Of course the book is The Value Flywheel Effect, available at the end of November.
Jeffrey: Fantastic. Thanks, David.
David: Thank you.