The Flywheel Effect Creates Space for Innovation
Creating confidence in the technology team is critical at every company. The flywheel effect occurs when we balance business strategy (via Wardley mapping) with technology strategy (via Modern cloud).
As a preview of the upcoming IT Revolution book, Dave creates a Wardley Map to show how to use the value flywheel to build confidence, improve your cloud stance and create space for innovation. Many business leaders ask for Innovation and speed, but it’s really Problem Prevention (Well-Architected), Modern Cloud and good Developer Experience that unlock higher value capability.
Bazaarvoice, Technical Fellow
Software Architect, Globalization Partners
Thank you, Brody and Jane. Okay. For at least three years, I've heard so much about some amazing work being done by a bunch of Renegade engineers at Liberty mutual, a large American mutually held insurance company. By all accounts, these engineers who are based in Ireland were among the first in the organization to get real applications running in the cloud, using technologies very different than one typically found in a risk averse enterprise those days, but they eventually would help elevate the productivity of over 6,000 technologists at the firm. Not only did they help modernize the technical practices across the organization, starting with their e-commerce site. They also helped create the AWS cloud development kit, serverless patterns, which is widely adopted, not just within the company, but across the industry. Even being heavily promoted by AWS themselves <laugh> it was made popular because it made writing serverless applications so easy and understandable for developers. So last year I finally got to meet some of the people behind this effort who were leading a team of over 500 engineers in Belfast, Ireland. I was so excited to finally meet him, especially since he was introduced to me by none other than Adrian Cockcroft who wrote this amazing gushing introduction letter. And I am so delighted that they will be codifying their learnings into a book that will be published next year, called the flywheel effect. So here is David and Michael.
Thanks Jean. Um, so my name's Dave Anderson. I'm a technical fellow for bizarre voice. The story I want to tell you is really about space for renovation, why we made that journey over the last few years, till today, I'd like to use my colleague here,
Everyone. I'm Michael, O'Reilly an architect with globalization partners.
So, uh, myself Michael, under third, amigo mark McCann working together probably for about 13, 14 years ago. And, um, back in Liberty mutual at the time we were working a lot of kinda eCommerce sites, big systems, but OnPrem and we, we were really lucky to be in a position in Liberty mutual where the move to the cloud was starting. And this was back maybe in 2013. I just took a CTO role in Belfast and had a small team of architects. And, uh, we started the look at the landscape and we could see there was opportunity for a huge change in a fortune hundred company. This is an opportunity don't get every day. So we Wordly mapped out what we think might happen. And it was clear that there was a different cloud application architecture approach that we could take huge risk. It turned out to be serverless.
We didn't know that's what it was. We didn't really know if this was actually made sense, massive personal risk with any big risk, like a lot of middle management push back, say, why are you doing this? We had the conviction to press on. It was almost like a poker game where you can see there's one hand, that's going to pay off big, but you have to play it. So we started to bring in some of these practices like, uh, serverless while architected engineering secured by design all these things that were bit to become very, you know, good practice. But at the time we didn't really know this diagram was something we drew out at the time to try and make sense of this kinda this thing we were trying to do this, this sort of almost like a system we were trying to create within a huge organization to basically reimagine engineering for the whole enterprise.
A massive ask from like a, what I would call a, a small office sitting in Belfast about 20 19, 20 20. We had achieved a huge amount of, um, uh, success with this service first strategy. We actually started to corner it, a service first enterprise. The network effects that we were starting to see were starting to come true. And we all the weak signals that we had seen back in 2013 were starting to kick in and like anything, the numbers didn't lie. We were starting to see massive returns on some of the risks that we had that we played off maybe back in 20 14, 15, 16. And we, I, I put this diagram together to try and explain what we had actually achieved. Cause it was so difficult, you know, because, uh, cloud application architecture is, is so hard to describe. And once I drew this diagram, I actually called, um, Adrian Coro, AWS.
I showed him this diagram says, you know, do you think this, this, this approach makes sense? Cause I haven't seen it anywhere else. And he said, no, this is absolutely brilliant. You're you're leading the way with the way you're thinking here. And they said that he, that was shocked. So we described it in four layers, foundational. Those are basically our key engineering approaches, which are kind of bread and butter stuff. Then we wanted to layer in our, our cloud kind of expertise, security, uh, infrastructures, code and certification. Then have an opinion be opinioned about architecture service first to be well architected focus on cost, have an organization strategy, have a clear north star business metric and then organization, team te be organized for success and then find acceleration. How do we scale that across 6,000 engineers with CD architecture patterns, specific innovation practices, English strategy, encourage teams to pay their own way code is liability, try and get engineers to write less code and then English architecture, try and get the concept into the business that we are always changing these systems, which is quite difficult. There's lots of really good stories out there about Liberty mutual. I would actually Google Liberty mutual serverless. There's a whole bunch of case studies. Uh, Michael, you were there those years. I mean, what, what stands out for you in this picture?
Yeah, no, thanks Dave. I mean, I, I love this, I love this. Um, I love this diagram. It brings back some awesome kinda memories. Um, but certainly like for me, I was kind of go back to the, the foundational because I think that was that really, you know, set us up for a lot of the success that we went on to achieve. Um, you know, working with the teams, helping the teams really become data driven, you know, and by that, like understand what measures were important to them, both from a business perspective, also from a technical perspective, how they able to add value. So when you kind of enable your teams, understand their, their mission and their purpose through the data, it then makes a lot of these other things easier to kinda integrate and, and, and, and drive within within the organization. You know, for example, I know we're gonna look at, uh, serverless first org strategy.
So this is a build and block that was within the, the diagram. And really we coined this because obviously we were operating a scale. You know, we're a large organization, we've got dozens and dozens of squads, product squads, different types of squads, but we try to distill that down into something that would fit into, into team's heads. Um, but really summoning it up. You know, this is kind of the, the metrics that we use to help create teams that maybe didn't understand their purpose or their mission, and maybe working on non differentiating type work or work. They didn't understand to become teams that really understood their mission and purpose had good situational awareness and were able to kind of make good decisions in terms of the products and features that they were able to then go and build and develop, leveraging that serverless first, uh, organizational strategy.
Yeah. And Robert serverless first, that was important cuz you have engineers at an insurance company, their focus should be insurance. You know, that it's it's the business. So we I'm so proud of some of the outcomes that we kind of drove. One of the ones that I thought was, was amazing was a call transaction cost. We ended up building a complete sort of, um, cloud call center using service technology using kind of, uh, on AWS, like connect and Lambda and a bunch of other kind services. And we reduced the cost of a call from $20 down to 4 cent. And by about a year and a half ago, I think they were taking something like a quarter of a million calls per month on that there was a purely serverless kind of automated, um, call center. Um,
Yeah, and for me, you know, um, I we've got a call out here the second point, but the rapid delivery, there was a, there was a scenario. I remember just at the, when the pandemic kicked in and effectively, we had a business use case in south America where our, where our agents had to go and visit the homes of potential customers. You know, if they were trying to ensure their car, they needed a manual inspection. And obviously with the pandemic that became much more difficult. And, um, obviously there was issues with that, but leveraging our serverless first org strategy, we were able to kind of assemble an application that was leveraging artificial intelligence to, to kinda automate that process and build a product that, you know, could protect both our agents and our customers and, and, and move that, that, that process digital, um, also that became, that was an innovation in a sense. And we were able to then rule that out to subsequent countries over the, the, the next three to four months. And I think that's, we ruled that from south America, six countries wide, and then we moved that into Europe. So a hugely successful story with that one.
And then, and like the digitization of the business is really what you're talking about here. And one of my favorite stories that I'm also super proud of is the fact that we had, we had won an insurance is thousands of applications for a big company. We had one small application that was sitting on WebSphere. I think it was costing maybe $50,000 a year to run. Um, one of the teams seen that as an opportunity, refactor it to service solution and reduced the cost from $50,000 a year down to $20 a year. I mean, and think of the sense of empowerment that those engineers have by a nice kind of project like that.
Absolutely phenomenal, phenomenal. And I think even on the smaller scale, we, you know, it was really successful, but even again, on the larger scale, you know, like we, we applied this strategy to some of our largest insurance platforms. You know, I remember our global insurance platform that we roll out in the Europe and it was kind of driven a large part by our Seus first org strategy was able to kinda, you know, help the org move its scale as well, try scale into the business, which was fantastic, um, really, really successful.
And then there's also a whole big story about the, in the journey the engineers went on to kinda, you know, work through this kinda system that we created and, and really kind of Excel. Uh, at one point I think I had four AWS heroes on, on, on my sort of extended team. I mean, very few companies, even with four heroes, uh, with like Jillian McCann, Jillian and Armstrong, Matt culture and Tom McLaughlin, then there's a whole bunch of people as community builders as well. So these are engineers that have done fantastic pieces of work, you know, doing keynotes big presentation for AWS. Uh, Jill BCAN took a work grid as, as a project and spun that out into a complete startup its own separate company. I mean, massive success stories here. The people focusing on the business outcome and using serverless to go fast at high, at quality and at scale, it's so proud of the work we did there.
What we almost seen then was like Lester to take notice of the success we were having. And, uh, back in 2020, there was a serverless first function, uh, event where, um, and I didn't, I didn't know this ner Vogels, the CTO of Amazon actually described Liberty mutual as organizational Nirvana because of our serverless first cloud application architecture approach. I almost fell off my chair watching this at home. Um, and then six months ago it reinvented Matt colder. Um, one of the architects, he, um, did the keynote with wearing a robs. They tell the Liberty mutual story, which was an unbelievable, uh, presentation. I was so proud watching Matt. I was, I was in the front row cheering him along and he, he told this brilliant story about the whole evolution for, for Liberty mutual, becoming like a service first end enterprise. And, um, one of the things that we did was we codified a lot of our patterns and created this, um, CDK pattern, um, kind of library to help developers, uh, create their kind of applications really fast.
And now that's been open sourced and that's its own kind of, um, open source project itself. And Matt has been fantastic and kinda leading that community with CDK day and a whole bunch of other stuff. So not only have we created building blocks to build applications that they had been shared out, and I think there's something like 5,000 people on that get home repository. It's absolutely absolutely huge, phenomenal story. Yeah. Yeah. So that creates a flywheel effect where engineers start to see the success and start to learn more and, and see the, the, the, the feedback of in their community getting, getting really good, good, um, kudos with all engineers. So then we kinda stop back and says, we we've we've stumbled across something here. That's a fantastic technique. That's trying to still all this thinking and do a book, which we're publishing with it revolution, uh, this November called the flywheel effect with myself, uh, Mike and mark, uh, putting this book together and really it's about how do you take your business strategy with worldly mapping and your kind of technology strategy with modern cloud and combine them together.
And what does that flywheel effect look like? So we talk about this in the book and get into the thinking and some of the theory about how we and the practice and the success stories, how we actually made this happen and how to do this yourself. So really one of the questions that I I find was fascinating as I, as I think with other companies, is what happens after the transformation know we've had the Hulu around where we're going to the cloud digital transformation. What happens when all the consultants have been paid? We've did their three or four years, the big bonus pot's been E update, everyone's go out and bought their cars and boats, et cetera. Everyone's got cloud socks. They've come back from the conference. We're all, highfiving each other. Mm-hmm <affirmative> at some point the board of the CEO goes, okay, we've spent a whole bunch of money going to the cloud.
Why are we not delivering faster? It's a great question. And I mean, and, and really the question is, is technology really driving your business? Cause there is a culture change required. And I mean, in this event, we've, we've talked with the DevOps culture for, for, for many years. And that is the, that is that cultural change that needs to happen. Just lift and shift into the cloud, just gives you a nicer data center. You not really benefit from the cloud. And one of the ways we sort of started to describe this is this idea of modern cloud versus legacy cloud. If you just lift and shift what you have, you've good legacy cloud, you, you maybe still have a mono in the cloud. Maybe still have a lot of EC, two S virtual images. Maybe you're logging in change stuff. You don't have that automation with modern cloud you're thinking and behaving differently. You're very, you have a very small time of value. You can prove value quickly. You can use the latest techniques and you've got that empowerment and really strong develop experience. We think this, this way of acting differently is, is the, is, is the actual massive success factor for modern cloud.
Yep. Dave, and you know, when we talk about the, the flywheel and the flywheel, as we've described it here is, you know, how do we, how do we create a flywheel? How do we create that movement and progression, uh, within our organization? And this is the flywheel that we talk about within the book. So we start off with really trying to understand our purpose. Um, we set ourselves, we, we create an environment that supports challenge and psychological safety around challenge, um, in terms of really getting to understand that purpose, um, then we can leverage, you know, situational awareness to decide on next best action. You know, what's the next best action for us to take. And then also, you know, regardless of what the next best action is, we've always, we've Al always gotta keep an eye on the long term value. And they have taken us back into Wordly mapping. Wordly mapping helps us always have those conversations. It helps with the challenge. It helps with that situational awareness. It helps us always keep an eye on what what's our purpose, but it also, you know, can help us drive and, and, and make sure that we're working towards that, that long term value. So we're gonna get into that. I think in our, our worldly map in session.
Yeah. So some of you may not be aware of Wordly map, but so we're gonna take you through how we, as, as an architecture team have used this technique to actually visualize some of the things we're trying to do in this value flywheel to kinda drive that change. We, we had talked about earlier, so let's, so anytime we're starting a Wordly map, the best way to start, this is with the value chain. So we've picked up a persona here as the anchor, as a senior leader, this is likely a CEO, or maybe someone on the board, a very senior leader in your organization. And for me, there's, there's two main value streams that that senior leader is looking at when they think about technology first, the time the value, right? It's not lead time, time to value. Um, so which depends on good architecture, I would say, well, architect is, and what good architecture depends on technical leadership. These are just straight dependencies within your organization. And then a second kind of, um, say customer need for that senior leader is innovation. So for me, innovation depends on modern cloud and modern cloud depends on a strong team environment. So it's, it's how is your engineering environment set up? Like, if anything, anything you want to kinda add about these value chance?
Well, the thing is, is, I mean, why I would ask the question is how do we know they're right? And the answer is, well, we don't, but it helps us get out of that analysis paralysis and helps us really get into that, that conversation. But then I think applying mapping and they approach the mapping helps us get a wee bit more, probably a bit more meaning and a bit more understanding to that, that conversation.
So, I mean, if I was doing a Wordly map, I would do these pretty quickly. I would just have something fairly simple and just lay them out, just like a five, 10 minute exercise. So here, we've got the shape of the map here, as you can see, we've kind of got business growth from top left there, we architected on the right and the environment for success is that kind of key enabler. So let's go back to the start and actually draw this map already again. And I think what's important here is as an architecture team, you need to know what you invest in and what we don't invest in. What do we need to improve as an architecture team? And what else do we not touch? So something like operational excellence, we know how to do operational excellence as a senior leader, there is a specific need there it's understood job done. Like, what do you think about this for
Yeah, a hundred percent agree. And if it's, if we are following practices and standards during operational excellence, that aren't commodities, what are they and why are we doing them? You know, so that's a good conversation,
Pretty simple. So the DOR to time, the value is probably more, we understand it well, and we understand there's key things like observability and customer, customer obsession that are important there for business growth. It's a bit more kind of, uh, you know, hypothesis. Uh, we, we're still trying to understand better about how you actually get that business growth.
Yeah. It should always be custom. It should always be custom. And then I love here out in the left, you know, you've got sustainability in coming in, in the Genesis space. How's that gonna affect what we do? You know, uh, sustainability's impact industry in a big way, cloud providers are allowing us to, uh, measure our carbon footprint. It is gonna have an impact. What, what is that impact? Let's have a conversation and what could that be?
And again, as architects, we want to figure out that were, were being most effective. And for me, I thought when definitely through this it's around that developer enablement developer experience, how can we have a modern kind of, um, tech stack that we can experiment and learn, which includes the, and the, the foundational block here is modern cloud.
Absolutely. Um, so you can see in here that, uh, developer enable is a huge component of, uh, our ability to modernize. And it does feedback up into, into type of value. So really what are we doing as a, as a technical leadership squad to really enable our teams and, and focus on developer experience and developer enablement. So that's a huge factor in our map.
When you think of the major cloud providers, this is where they're focused on right now. And there's good reason for that other things like, well, architected, both Amazon, uh, Google and Azure have really, really solid well architected frameworks that are maybe 8, 9, 10 years old. We know what good architecture looks like, just follow the guidelines. Don't there, there's no custom good architecture practices. They're very well understood. And then we can codify those cloud architecture patterns.
Absolutely. And well, architected gives us that a commoditized set of architectural standards that allows us to create patterns consistently across the whole organization. So when we do enable our engineers, by putting it into that, that cloud self-service portal, they're all really consistent. They're all working to the cm set of enabling constraints. So as an architect, I love that stuff.
Yeah. And adopt the standard. Don't write your own. Like you are not different <laugh> and then finally, growth mindset. If you go down this route, you need to have technical leaders who are willing to change experiment and engineers who are willing to try new things. So that growth mindset is so important for us. Wordly mapping is that hypothesis that we could maybe map things out and understand what we need to do, what we need, not what we don't need to do. And then psychological safety, that idea of it's our role to try and create that for the teams, give the teams space to learn
Completely agree. And, you know, in a, in a diverse sort of cultural environment, such as a big corporation, extremely important, how do you get everyone's ideas? How do you get them involved in that modernization process? Um, how do you create a space where people want to come and be creative, super important part of the map.
So you see how complicated this, this whole picture is like, but by, but what, what we have found is drawn us out, like a map, enables our conversation and challenge to try and get everyone on the same page, but let's shrink this back down and really see the shape of it. Again, again, you want to tie the senior leader needs right down what the architecture team can do, do what we need to do within the engineering teams. That's the kinda chain here that we're trying to, uh, reflect here on the end from a modern cloud. This is probably the unknown piece that we need to move to the right, the modernize.
Absolutely. Dave. And, you know, we talked about CDK patterns as being really a massive part of that serverless first org strategy, you know, so we were investing quite heavily in embracing modern cloud. How do we get modern cloud into all, every part of the, the organization? Well, our strategy is evolving around developer enablement, that cloud self service, those patterns that are built on well architected, we plan to shift that from a custom, you know, being built as a, as, as a custom component and one part of the org, but make it the, the defecto, that's our modern cloud strategy for the whole organization. So that again, important part of movement. And we also talked about sustainability as being a climatic pattern that has beginning to penetrate the map there in terms of the, the business growth area. So you can see you're already starting to see movement within the, within the map and having to deal with that movement
Mm-hmm <affirmative>. And then that text, as we talk about the book, the flywheel effect, we start to see the value flywheel, um, reflective here in the map. And number one was the, the customer need there, which for clarity, purpose is not first part of the flywheel. Um, number four, as architecture as architects we've got well, architected is that's kinda long term value, but the, the, the difficult things to do are number two and three are two parts of the fly with how do we create a, an environment for success. We can challenge thinking and how do we introduce like a next best action kinda mindset that we can act quickly? And can it go that modern cloud, which will get you, does that can work attack the long term value?
Absolutely. And this was through the flywheel effect in action for us, we've kind of talked about briefly already, but, you know, even we look at that challenge in landscape area, you know, type of things that we were doing was looking at replication and, you know, across all our squads and our, our environments and our teams, what could we do to address that? How could we reduce our costs? What is our next best action? How could we, you know, um, uh, take actions and apply strategies to move that, that, that modern cloud practice from, from custom build to that product for, for our organization. So again, the, the flywheel in fact is very, very real in, in this, this scenario.
And remember the map drives conversation. So really the four, the four phases there, again, we've got them here in, in the value fly within the book for clarity purpose, which is that north star not time, the value challenge, that environment next best action, your developer experience and server us first, your modern cloud strategy, and then long term value, which is your problem prevention, culture architect, sustainability. This is concept of joining your business strategy with your technology strategy. And again, this is what we're talking about, uh, in the book. And we explore this with great detail and examples in the book. So thanks very much for listening. Um, here's the help we're looking for as, as a gene has asked us to kinda give our call out, um, the, the book is there for, um, pre-order on Amazon and you can see there, it's, it it's built in, in November, what I'm really interested in, and I'm very happy to continue discussion on slack or on Twitter.
Are you seeing this modern versus legacy cloud split? I see a lot of both modern legacy cloud, but I haven't seen it really be named in this way yet. Do you see this flywheel organization? I've seen this in lots of organizations, but I'm looking for more examples that we can, you know, really kind of, um, understand this and help people through this. Have you looked at well, architect and sustainability for me, the well architect, the frameworks are absolute gold, but I don't see the adoption that I think there should be there. Have you tried worldly mapping in sense, making and technical discovery within your, a architecture teams and technical leadership teams? A lot of people are afraid of worldly mapping, but a lot of people have got massive success. How can we lower the bar entry and help help leaders actually map out their landscape and, and, and drive forward?
Um, I know what you like, but I mean, we great to kinda hear people's opinions and, and continue the discussion. Yeah, that'd be awesome. Brilliant. So that's us. Um, so we have more, uh, like I said, the book's coming out on, uh, November and it revolution, and it's been a great experience right in the book. Uh, we also have a blog email@example.com and we have, um, um, our serverless crack channel podcast. Uh, look us on Twitter there. And, um, please research us on slack on the DevOps enterprise, uh, channel. I'm happy to keep the conversation going. So thank you, Eugene, for the candid introduction. Thank you. Thanks.