David Anderson

Okay, folks, thanks for coming to the talk. My name is Dave Anderson, and I am going to talk today about creating the Value Flywheel Effect. I am a technical fellow for Bazaarvoice.

I have a book coming out. I have been working on a book called The Value Flywheel Effect, published by IT Revolution. It will be out in about, I think, six weeks, and we are going to do a book signing this evening about, I think, 6:25.

For my background, the story of the Value Flywheel Effect is really the story, over the past few years, of my journey with my two co-authors, Mark McCann and Michael O'Reilly. I was really pleased that Adrian Cockcroft and Simon Wardley also wrote forewords for the book, which I was shocked by. I did not believe they would actually write them until they actually sent them to me. So that was a nice endorsement for the material.

I am based in Belfast, and to give you some context for the whole idea of creating the Value Flywheel Effect: I spent about 14 years working for Liberty Mutual before I took my current role. Back in about 2013, 2014, I took a CTO role at our organization in Ireland. We started like any big company: let's do our digital transformation. There were three goals that Liberty Mutual had. Liberty Mutual was a Fortune 75, I think $40 billion company, one of the largest global insurance companies in the world. The three goals at that time, maybe eight years ago, were customer centricity, cloud-native development, and agility. We often reflect: three big moves, so let's do them all at the same time. Perfect sense.

As an architect, my eyes lit up at cloud-native development. One of the things I knew as we started to move into public cloud, and as we tried PaaS and private cloud and went through that whole journey, which gave us a lot of learning, was that we could not just lift and shift our operations to public cloud. We needed a different way of writing software. I also knew that a lot of my peers in network, infrastructure, and security would do a lot of the hard policy stuff that we needed to do. So my team needed to focus on software: what would be the best way to create software in the cloud?

This idea of a serverless-first approach was a way of completely modernizing how we write software. What that would really do was give us that edge as we started to build natively in the cloud. Then, as we started to partner with AWS, the two things that we figured out were not planned. This was the way it worked out: we moved to the cloud, and we modernized. In reflection, I see a lot of people do the migration. It is the modernization that really gives you the benefit. One of the key messages in the book is: how do we do that modernization? I often use the phrase modern cloud versus legacy cloud. There is an awful lot of legacy cloud floating around the industry.

Let's break down what I mean by modern. A lot of struggles we see are: it is slow to write our software, maybe it takes months to release, we have poor predictability, it is really hard to hit a date, costs are always increasing month to month, scalability takes manual effort, teams get stuck and cannot scale something, and engineer confidence is hurt by a poor developer experience. So I started looking around: how do we solve this problem? I think it was 2014 when Lambda came out, and we started looking at that as a serious proposition. How do we work differently in this way?

To take it straight from one of the later slides, the benefits of serverless are speed to market. We deploy in hours over months. We build better applications by default. There is the idea of focusing on your total cost of ownership. My measure of a good software team is that they understand their TCO. They can talk about cost automation. You can ask an engineer, how much does that cost, and they can tell you. You improve scalability; you get some scalability for free, not all. And there is the idea of running your applications anywhere. So this was the serverless promise.

To fast-forward that to modernization, I should stress that serverless-first means you start off with the serverless option, then fall back to maybe containers and other ways. You do not start at the bottom and work your way up. It is not serverless-only as well. There are also lots of containerization solutions that are important.

The big aha moment for myself and my team was the Shared Responsibility Model from Amazon: where do you draw the line? With a lot of the services offered by Amazon, and the same for Google and Microsoft, when you migrate you hit that red line, which means you are offloading some infrastructure, maybe some availability, to the cloud provider. You have moved from your on-prem data center to a really fancy data center run by Amazon or Microsoft. That is not a bad move. There are benefits in that, but from my perspective, you will not get the full benefit of moving to the cloud.

If you draw the line further up, with the green line, then you are offloading things like platform management, compute, storage, database, et cetera, to the cloud provider. The thing my team and I always talked about was: we are not in the business of competing with Amazon over how to build a database. That is not our core. We are insurance software. We should not be competing against cloud providers. So we started to think, mentally: where do we draw the line? And higher is better.

One of the things we started to talk about was how much serverless is being adopted. What is the adoption curve like for serverless? It is seen as a bad word. I do not like the term. I do not like a lot of the press associated with it. But the secret is, and this is a survey by Datadog from just a month or two ago, more than 50% of organizations in the cloud are using some type of serverless services. That is much higher adoption than you think across the three main providers. You can see there are lots of different services that you would class as a serverless or managed-service option.

Then some of the myths. I hear all the time: we are different, we do not need to do this. Well, if you are trying to build a better cloud than Amazon, then you probably are different, but that is not everyone's core business. The fear of vendor lock-in is a very popular myth here. We will be locked into Microsoft or Amazon. Well, guess what? You are already locked in. So you had better be faster in business than flexible in another business.

The consultants do not like it. I hear this quite a lot, and apologies to consultants. The big push for consultancy is migration. There is a lot of time and materials in migration. It is not a good migration path to go serverless, because it is not as much work. It is immature: maybe in 2016 serverless was immature, but not now. A lot of services are rolling on this technology.

Our engineers are not ready. Serverless is the cloud. The serverless principles are the same as the cloud principles. If your engineers do not understand those, you need to train them. The definition of the cloud probably changes every year too, so you need to constantly invest in keeping your engineers up to date. If your engineers cannot do serverless, then you need to think about what their cloud expertise is like.

The financial question: it is pay as you go, the cost will shoot up. Not really, because if you are using the cloud properly, you should have a FinOps function. You should be tracking the value, not just the trends, and be clear in what you are spending and what you are going to spend. It is the old OpEx over CapEx argument. And finally, security tools will not work. I have spoken to a lot of CISOs who say we cannot do serverless because our tools will not work. That is the wrong answer. It means you are using a legacy set of tools. Security principles that work with serverless are the ones that will protect you in the cloud. So for me, there are very few myths. There are very few reasons why taking a modern approach like this would not work.

I wanted to level-set on the serverless stuff. What I really wanted to get into was: how do we get to the Value Flywheel Effect from the work we did over the past 10 years? Some of the benefits we have seen were massive cost reductions, massive speed increases, global deployments of software, and very innovative solutions. But how do we get to that? Rather than bore you to death with slides, I am going to talk through a couple of maps that are interesting.

This is one of the first maps that myself and my team looked at. This is a Wardley Map, and I will explain a little bit of this. Simon Wardley started mapping in this way probably maybe 15 years ago. This idea from his map of where do you draw the line, this idea of being below the line, was incredibly impactful for us as a team. Simon would always put this out on Twitter. It is a little bit confrontational, or at least he is trying to get up an argument.

The way you can read this is: visibility is from the top, more visible, to the bottom, invisible. The evolutionary axis in a Wardley Map goes along the bottom. Genesis is something brand new. It is wondrous. We have never seen it before. It is magic. Custom-built is: we know what this thing is, we can build it, but we are not really good at building it very well. Product: there is now customer demand for this. This is a thing where we understand the value, we are getting better at building it, and we should rent this. Commodity or utility: that is something that is just the price of doing business. We just need this.

The interesting way of reading this map: to the bottom left there is high MTTR. With high MTTR, you are likely using legacy architecture best practices, you are probably building your own components, your cloud strategy is maybe a bit vast, and you may be focused on best coding practice. You will be stuck over to the right there. If you look at the left, if you can evolve your MTTR to have cloud MTTR, a better response for the cloud providers, you might look at good architecture practice, which would be DevOps getting into the software, as talked about at this event. Then you might look at offloading the operating system and some of the platform elements of serverless to the provider, and that opens up an emerging architecture practice.

I will not really read this all out, but to me, I could sit and just look at these maps for hours. Every single component you can read in multiple different ways. You have got another kind of path in the middle, which is load balancing. Maybe if you are sitting there worrying about your load balancer, you are building your own components that you should not really be focused on. On the right-hand side is Lambda. Maybe, okay, you have got your serverless architecture, but there are serverless anti-patterns. Even when you think you are using the right technology, you can still evolve your architecture practices.

I should really say: this is not saying that you must use serverless. It is saying that you need to be aware of where your technology is, in terms of the maturity, and pick the right solution for where you are and what you are trying to do.

The other thing I found from these maps was the idea of starting with the need. That is super important in these maps. The customer is at the top. The customer has the need, and the map is drawn from that need. These maps force you to start there. If you are an architect or an engineer, the trap is that you start at the bottom with the technologies you like. The map pushes you back up to ask what the user need is and how the components underneath support it.

Then we started joining the dots. We drew the business expectation at the top and connected it down through product, architecture, engineering practices, and cloud infrastructure. We could see how decisions about the cloud and infrastructure had impacts right back up the chain. For us to join the dots from what was expected of us by the business, right down to engineering practices and cloud infrastructure, was a very powerful way of mapping that out and spotting the interesting points.

The next thing, and this is really important in the book, is trying to make mapping more accessible. I am under no illusion that Wardley mapping is difficult to do. I think it took me and my team, Mark and Mike, about seven years to learn it. We say seven years of scratching your head and the last month of actually figuring it out. One of the things we did to make it more accessible was create a grid around the map, because I knew that if we spoke to a team and started mapping, we would lose them instantly.

This is from a whiteboard sketch from a few years ago. We draw the map and axes and stick out one, two, three, four across the bottom, and A, B, C, and D down the side. That was a way for us to quickly almost categorize, or plot, where teams were. As we would map out all the teams in the portfolio or in a line of business, you could see where different teams were. The customer was a business stakeholder, fairly generic, and we mapped where we thought teams were.

The sweet spot there, I would say, is kind of A3, around killer product. That is where you want your teams to be, over towards the left to be maybe more innovative. Any teams in the custom-built column, you want to think: if this team is really important, we should try to move them across, maybe upgrading their engineering or other technology. If teams are quite low down, maybe in that bottom row, either in two or over in four, you need to question: should we build this, or should we modernize? This became a great way to map out a whole bunch of teams and see where teams and products actually were. It became a way of speaking almost in shorthand: that team is A2, they are killing it, or they are D4, like Battleships. This became a really effective way of discussing the idea of mapping with teams without being too complex.

We then stepped back as architects and technical leads and looked at what some of the things were that our engineers needed to do. As we started speaking about these things more, we started to map out: are they aware of their business goal? What are the enabling constraints? What knowledge is there around that? For the business goal, as you start to build on these value chains, you start to see things like alignment, rapid feedback loops, and your DORA metrics.

One of the things we thought was really interesting about this map was that, as we started to play with these value chains, we started to spot what thing we needed to move. This map is cleaned up for the book, but it is an old map from a few years ago. We thought that DORA metrics were something we could move the needle on, and obviously architectural patterns. One of the things we invested in was, when the Accelerate book came out, it was brilliant because now you could say: here is a book, read this; this is what we are talking about. Let's start talking about our DORA metrics and moving the needle on that. And let's start creating architecture patterns, which we ended up using CDK patterns for: having a CDK pattern that can quickly create reusable building blocks. Those two constraints around rapid feedback loops and enabling constraints, architecture patterns, started to move a lot of the other capabilities across. This is a super powerful way, because you cannot solve every problem in this map.

Next up was the idea of sense-making, and this was probably the thing I found most useful. This was a map I probably drew around 2015, and as you can see, it is super messy. Myself and a few of the architects were sitting asking: what is our value proposition? What do we need to be able to do? Where do we need to move the needle? We hit this idea of a team that affects outcomes via delivery. What are all the things that need to happen? We started to figure out there was a value chain doing that, but it was custom-built. That was interesting but far too custom. So one of the things we started to do was: given that value chain is custom, how do we move those things to the right? This was an example of a map that was super impactful. It got us on the same page about the things we needed to do.

That very early map turned into the map that is the Value Flywheel Effect. We eventually distilled that down to three things. If you are a CEO, the most important thing is clarity of purpose: create clarity of purpose in the organization, maybe through a North Star or responsiveness. Bookended with that is the idea of challenge: an environment for success, or psychological safety. The idea of being able to map out your problems and what you are trying to do creates a nice environment, because when you draw a map and discuss where you can put things, it creates a nice environment of conversation in the room. If I had put this in a bunch of slides and presented them, it is very hard for people to challenge the slides. It is much easier to challenge the map that you are co-creating as a team.

Once you bookend these two business goals of clarity of purpose and an environment for success, the two technology goals are next best action, which is creating an environment where your engineers can move quickly, with that serverless-first strategy and a really good developer experience; and the idea of long-term value, which we ended up calling problem prevention, really using Well-Architected and having a culture of removing problems before they happen. We also talked about sustainable practice: good cloud choices could be more sustainable cloud choices, but that is a different talk. We found that we could standardize on best architecture practice of the industry on the right, then use our efforts to move across next best action and improve the efficiency of our serverless-first environment. That is what became the Value Flywheel Effect.

One of the things I have been doing as part of the learning experience yesterday and today is using a really simple value chain to support a board member. When you are starting to do a Wardley Map for yourself, and I would encourage you to sit and do this, the big thing for me is to make these very simple. You can overcomplicate these maps, but it is better to make them super simple.

One of the really simple value chains is: you have someone like a board member. I would always pick someone away from engineering. What is their need? Let's say their need is business value. It depends on leadership within the organization, which potentially depends on technical leadership, maybe good architecture or good senior engineers. That depends on engineering cloud skills, which depends on having modern cloud operations, which is a more up-to-date way of looking at your infrastructure. By drawing out this value chain in the learning sprints, we have been experimenting with what else you would add to this.

I would certainly encourage you to look at LearnWardleyMapping.com by a guy called Ben Mosior. It is probably the best resource for learning how to map. We have been using that little canvas there.

Once you map out that value chain, you can then think about what forces of movement you could put in to try to move those things from the left to the right. Starting from the top, we find this idea of an engineering North Star. Once you are aware of your business value, it is incredibly effective to sit with the team and say: what is your North Star? I often use the North Star framework from Amplitude for this. It is a bit like impact mapping. There is a nice exercise where you can map through: what is your North Star? What is your long-term North Star? What are the things that will move the needle on that? What are your key metrics? What are your key initiatives that will change that? North Star can build up the capability of business value.

Leadership: I think once you start to create psychological safety, and start to discuss that as a concept and as something you want in your organization, you can see that leadership starts to move across. By using the Well-Architected standard, by using the Well-Architected framework, you can start to build better confidence in your architects that they are doing the right thing with your cloud. Then with engineering cloud skills, create that learning environment to give your engineers the resources to learn about the cloud. For me, it is not about a classroom. It is really about labs, things like A Cloud Guru, workshops, game days, events like this. What is a more cloud way of learning? Finally, with your modern cloud operations, look at your vendor's best practice and go with that. Do not try to reinvent the wheel.

Here is the key illustration from the book. You have just seen it later in the map. The concept is the joint business and technology strategies. You have clarity of purpose and challenge on the right, with the North Star and time to value, and psychological safety and the environment for success. On the left, you get next best action, which is developer experience and serverless-first strategy, and then problem prevention with Well-Architected. Once you start to get that flywheel turning, and I would say get that turning pretty fast, then you start seeing the benefits, which is the approach we took over the last couple of years.

That is me. The book will be out in about six weeks' time. The blog is there and a couple of other things. We are doing that learning sprint in about 15 minutes. We are going to go through that same exercise, and I am super keen to hear any feedback on the book. Please reach out on Twitter and say hello. Thank you.