David Anderson, Mark McCann, and Michael Reilly

David Anderson: Hi folks. Welcome to our talk. This is our talk called “Mapping the Value Flywheel Effect.” My name is Dave Anderson, author of The Value Flywheel Effect, and here are my two co-authors of the book, Mark McCann.

Mark McCann: Hello.

David Anderson: And Michael Reilly.

Michael Reilly: Hey, everyone.

David Anderson: So we are going to talk about, or actually live map, in this breakout session at DOES Virtual US 2022. We are super excited to do this, and it is slightly unscripted, so we will see how this goes.

First of all, I just want to mention the book, The Value Flywheel Effect. It should be out by now, published by IT Revolution. We have been working on what happens when you get to the modern cloud. We have all talked about big cloud migrations; what happens when you get there? Myself, Mark, and Michael have experience over the last few years of really modernizing large cloud implementations. The learnings we have had from that are called the Value Flywheel Effect that you can see here. It is really the idea of joining business and technology strategies together.

There are four phases that we talk about in the book. Clarity of purpose, which is having that real North Star and being very clear what you are doing. Challenge, creating the right environment, the idea of psychological safety in the organization. Next best action, which is really using the power of the cloud to create products really quickly. Long-term value, the idea of a problem-prevention culture.

We have used the technique Wardley Maps to create this, so we figured we would actually do a live mapping session and see how that goes.

For this map, it is in GitHub as well, so you can go and look at it yourself. For this mapping section, we are going to use Visual Studio Code, the Wardley Mapping plugin that we are using. You can also use a website called onlinewardleymaps.com. This is a technique called map-as-code, and we can explain this as we go.

For anyone who is not familiar with Wardley Mapping, I will explain the axes here. It always starts with a user. What is the customer? From here, we are really talking about a large cloud implementation for a company, so our anchor user here is a senior executive, maybe a CEO or C-suite. This is our key user, and this user has a primary need, which we will say for technology is operational efficiency. Then there is what that depends on. That depends on cost management, say your cloud cost management. That depends on having a problem-prevention culture, and the problem-prevention culture depends on enabling constraints. So we have a quick value chain here.

Along the bottom, we have the evolution axis, and there are four phases here. Genesis is like a concept, something brand new, never been done, and we are not quite sure if it works. Custom is maybe hypothesis; we think this might work. Product is customer need, and this is a theory that we know works well. Then commodity is accepted, like the cost of doing business. The y-axis here is the value chain, where things toward the top are visible and things toward the bottom are more invisible. In this example, the senior executive might be very clear on operational efficiency, something they see, but they may not know what the enabling constraints are that make that happen.

Market, Michael, is there anything you want to say for this map? We are pretty informal here. Anything we can open up in the conversation? Any comment you should make about this value chain, or what do you think?

Michael Reilly: Mark, I do not mind going first.

Mark McCann: No, it is good. I think even just mapping the components of the value chain, even though there are about five elements here, you can start to get your brain going. You are thinking about what are the components, why are they over in commodity, why are they not in product. Again, it starts to get you thinking about what it is that you actually need, what your users need, what those needs are made up of, and what the components of that value chain are. I think it is a super powerful technique, and it gets you thinking in every way.

Michael Reilly: I was just going to say the same thing. With mapping, it is all about position. Position has meaning. The fact that all of these things are right in the commodity space is telling me that these things exist and that the value chain is leveraging things that are already existent, already kind of well understood. They are not things that may necessarily be invented or created within that organization itself. Again, position has meaning.

David Anderson: Yeah. Often as we talk, these things will change. Position and movement: position is relative, top to bottom, and movement is things that go across. Your cost management actually could be over here. You may say, well, in order to drag cost management over, we will create a new component called something like a FinOps capability. Then we will say cost management depends on FinOps, and that might actually drag cost management over a bit. As we talk, you can figure these things out.

As I make a fool of myself trying to live map, you see this is just straight text here on the left-hand side. To save time, we have written down a few things. Once you have that fairly simple value chain, the next thing we thought about is how do you drag those things over to the right a bit? There are a few extra things we brought in here, the main thing being, can you tighten up those enabling constraints? What are some of the things that you need to create that problem-prevention culture? Enabling constraints sometimes are not quite enough, and certainly fast feedback is one of the main things there.

One of the big things that we have certainly seen as you move to cloud is the idea of a single team that does everything for you to a self-service model, something that I think teams have to move into. You can no longer have this ticketed or gated system to access infrastructure. There has to be a self-service model, which has impacts itself.

Mark McCann: I think the problem-prevention culture really depends on the fast feedback loop. You cannot get ahead of the curve if your feedback on changes is months or years. Really using the power of cloud self-service to do things more rapidly, get better telemetry, get better observability, get better metrics, logs, traces, and alarms, enables you to start seeing where the problems are, start predicting where the problems may emerge, and put the techniques, mechanisms, and practices in place to start preventing those things.

Things like Well-Architected Framework and threat modeling come to the fore here, and they are all underpinned by these enabling constraints. In the cloud, there are lots of good enabling constraints that the cloud providers give you. It is policies, security policies, and even runtime enabling constraints that will give your teams and developers good feedback on whether they are on the right path or not.

David Anderson: Yeah, I like that. This is a good one that you can follow. The obvious one I clearly see is the fast feedback with the dependency on observability. We have to be able to measure where we are at and how we are doing, react to that, and create those feedback loops. That does have a hard dependency on observability.

Enabling constraints is probably one we see where it is maybe not as considered in a lot of orgs moving into the cloud. You do not typically see it in there, but really what we are talking about are things put in place to make the environment safe for teams to operate. How do we remove the risk from leveraging cloud-based services? How do we make sure teams are leveraging things with proper configurations and things like that? Again, that all ties back up into the problem-prevention culture, and we should be leveraging commodities, not having to custom-build certain things.

It is no mistake that security is down at the bottom there, because it is absolutely foundational. It is not less important; it is absolutely foundational. Obviously with public cloud, security is job number one, so that is underpinning a lot of the stuff we want to enable and empower teams with. But we want to make sure they have those guardrails and security fundamentals baked into everything they are doing.

In this little part here, you could go nuts. You could have 50 components here. There is a huge bottom here, and we have done that, but we will keep it fairly high level for this conversation. Again, with visibility, your senior executive will not have visibility of all these lower-level things, but they are needed for some of the higher-up things. That is the whole point here.

The next part is where we will be slightly biased, which is that the thing we have used a lot is Wardley Mapping, and this technique, to figure out what those enabling constraints are and what we need to do from a security perspective. It is not necessarily the cybersecurity techniques themselves as well. What things do we need to have? What capabilities do we need to have in place to make that work? We have certainly found that mapping, and that environment for success, is a great way to challenge the organization.

Look at how these open conversations about how well we design our developer platform, how well our platform team works. A lot of this stuff is around the platform-team domain.

Mark McCann: I think mapping gives you awareness so that you can start to have a bias for action and start making these changes. You can start enabling that problem-prevention culture, which impacts your cost management and impacts your operational efficiency. Mapping underpins pretty much a lot of everything we do. But you can see that depends on that environment for success and has elements like psychological safety. Getting that safe environment is critical so that you can start these things in a way that does not terrify people and that brings teams along with you on the journey. It is a nice way that things depend on each other.

David Anderson: And the running as well, I think. There is usually a line of visibility in these maps. That is usually around here, I would say, just guessing, about a quarter of the way down. The user probably gets away maybe two or three levels; they do not really see much. If you think of any senior executive, all they probably know about the cloud in this space is whether it is efficient and what the cost is. There is an invisible line here, and the stuff that makes operational efficiency possible is quite hidden.

This is really what I would call bottom-line technology. If you get into more top-line stuff, once your operation is good, your CEO is thinking, okay, we are efficient, let us talk about other things. The second user need we have here is business growth. You want technology to drive growth, obviously, and that depends on these things. The first is customer need, or customer obsession, as they call it at Amazon. You have to figure out your customer need and make sure you are actually meeting it. That is the most important thing.

Sometimes, in order to meet that and grow your business, you need secure and rapid experimentation. We purposely put secure on there because you could do your experimentation and break a lot of things, so you need big security in that space in the cloud. The idea is that if there are ideas for features or new areas of your product, you can quickly experiment. Secure rapid experimentation depends on that problem-prevention culture and fast feedback, which is really the product focus. Now you are starting to connect cloud infrastructure to your product mindset.

Michael Reilly: The secure rapid experimentation is really about your time to value. Can you actually meet the needs of your users in a rapid fashion? That can really drive your business growth.

David Anderson: We talk a lot about time to value in the book. A lot of people think, what is the big metric for the cloud? Is it the number of containers or the number of serverless functions? It is time to value. Go back to the DORA metrics. Throughput and stability are absolutely key. When you move to the cloud, you want that rapid throughput. That is a big win for going to the cloud because you make it really simple. You are not ordering servers off the truck anymore; you are instantly spinning up compute and storage, et cetera.

Michael Reilly: Absolutely. You have autonomous, empowered teams that can leverage the cloud in the way we just described down below.

David Anderson: I could be cheeky and say if it takes a quarter to do something, you are not leveraging the cloud properly, but maybe not. Maybe slightly unfair.

The next thing is, sometimes when we get into a map around this size, we try to put an overlay on it. We often do pioneers, settlers, town planners, or maybe different phases, or even different teams if you are doing Team Topologies around the value stream, enabling, and platform. There are a couple of nice lenses you can put on this. For this one, we are going to be biased toward the book.

You can almost take the phases of the flywheel and overlay them. You have got clarity of purpose, then challenge being foundational, next best action here, and long-term value. These top three phases can link into the innovate, leverage, commoditize cycle, which is a well-known innovation cycle: you innovate on something, leverage the value of it, then move it to the right and commoditize it, which gives you space to innovate again. There is a nice cyclic effect here.

Again, that environment for success is the foundation of that. A lot of the cloud infrastructure is in this commoditized, long-term value phase, and that is not by accident. You start to see patterns in maps, and you will see a lot of this stuff over to the right. If you have a lot of this stuff over at custom-built, it is problematic, because there are a lot of things the cloud providers should give to you. It is best to leverage those, so these things should be over on the right.

Mark McCann: If you are trying to build your own cloud, you would be way over to the left here. That was genesis maybe 20 years ago, but not now.

David Anderson: Right. That is us. The next bit really is, now we have operational efficiency and business growth, there is space on the left here for something else. Once we drag these things to the right, what does that leave space for on the left? You always want to think about, once you evolve your things across, you want to make space for new innovation.

Mark McCann: Your flywheel is starting to turn now.

David Anderson: It is good. Yes, your flywheel is turning. Now you have the space for new innovative things. You have time to even think about it, because you are not fighting fires the whole time. If you have embraced the way we have outlined here, then you have capacity, time, and energy for the new innovative stuff that can really drive your growth.

A lot of companies talk about product innovation. Maybe you have a product that is going well, but there is another product or adjacent category that you want to move into. What is that product innovation? If you think of your user need here, you have got stable technology infrastructure, good business growth, and you are meeting a customer need. What is that adjacent innovative thing? It could be a category next to yours or a brand-new product.

We certainly find one of the things that depends on this is the idea of modern application development. Of course we are biased: we prefer serverless-first, but this also could be containerization. Really what this means is using the latest and greatest public-cloud techniques to build your applications quickly. It is the idea of building on the abstraction of the cloud. If you are sitting at a workstation in the shells and configuring servers, you are doing the wrong thing here. You want to be high up using the services that the providers give you.

That is where we have got developer building blocks here. That could be anything. It could be CDK. It could be Terraform. Whatever that is, you are building on something more abstract, which lets engineers go faster and be higher up the value chain, which again depends on that environment for success.

I think this is something that we see a lot. Once you start moving these things to the right, this kind of innovation will come in on the left, which is quite common.

Mark McCann: With modern application development, because teams are leveraging the latest and greatest capabilities, techniques, and services, they have more capacity and more time for product innovation. They are more interested in the product outcomes, the users, and their needs. They are not just going code; they are delivering business value and business impact.

David Anderson: Innovation velocity. That is pretty much us. We have a final note here of some annotations on the map. We rarely connect this top level straight through to the mid-level. This value line is really important because a lot of stuff at the bottom is often not connected to stuff at the top. It is nice to see that all fall through. There are some key messages here: obviously the Value Flywheel Effect, the idea that reliability should be building on the cloud provider, the whole idea of service-first, and of course engineering excellence. Having good engineers with that problem-prevention mindset is absolutely critical. We have certainly found that a map annotated in this way is super useful.

Do you have any final comments, Mark or Michael, before we close?

Mark McCann: No, I think it is a really clean map. If you follow it, you can see the emergence of modern organizations and their modern product platforms. It definitely connects very well.

Michael Reilly: This is not something that stands still. Like we mentioned, there is a flywheel effect here. Things on the left will continue to iterate and move across to the right. The things you have in that next best action over time will become commodities, and then they make space for the next thing that comes in, the next enabling thing, the next best action that you can apply to your organization. Once you get this loop and get this flywheel turning, you can get faster and faster, which is phenomenal to see once it starts to take hold.

David Anderson: Yeah. Mark and I probably first drew this map five years ago, and we have been evolving it for many years, so it is constantly changing. But the shape of it has remained for many years. Again, that is captured in the book and a few more things on Serverless Edge as well. That is pretty much us. Have a look at The Value Flywheel Effect. It is out now from IT Revolution. This map is up on our GitHub repo on ServerlessEdge/WardleyMaps. Hope that made sense. We will be on the Slack channels if you want to reach out and ask us a question. Thanks very much.