Skip to content

June 7, 2022

Exclusive Excerpt from The Value Flywheel Effect

By IT Revolution

By David Anderson, with Mark McCann and Micheal O’Reilly

After twenty-five years in the technology industry, I can now look back and empathize with all the people I drove crazy—mostly IT managers. Let’s face it, software engineers are usually hired to build things quickly, not fix the sociotechnical issues of the larger organization. And yet that is what I have found myself drawn to time and time again. After all, I have always believed that if you fix the system then everyone can build quicker and the business can deliver value sooner. The power of the group is always greater than the power of one.

Whether I was working on improving security, introducing Agile working methods, creating good engineering principles, improving enterprise architecture, building an ML capability, modernizing systems, designing cloud platforms, fixing the developer experience, you name it, I always believed that improving the larger system would improve everything else.

Over the years I’ve lost count of the number of times a manager has asked me, “Why are you doing that task? I need you to write more code?” I would always be polite and point out that writing code is important, but improving the system is more important. Of course, plenty of code was written, but code is a liability. When we eliminate the burden of something like infrastructure concerns for software developers, it creates room for focus elsewhere, such as developing software assets.

I have been writing code since I was nine; therefore, you could say I’ve always been a coder. But being a software engineer is different. A software engineer should be hired to solve problems and create value for the business. Most software engineers code as a pastime, not as a job. Code written “on the job” should be part of a larger value creation effort, not an effort to write X lines of code in X hours.

Unfortunately, too many people in IT write code, build systems, and perform tasks without any idea why. They obsess over function and forget about purpose. And too many people from the business see software developers and engineers as nothing more than programmers who should just make the system do what the business says it should.

In my experience, I’ve taken huge risks by focusing on these larger sociotechnical systems. I’ve had to deal with a lot of pushback from middle management for not doing what I was supposed to (i.e., write more code). But I always had the conviction to push on. It was like I was in a poker game and sitting on a hand that would pay big. When you see that kind of opportunity, you just have to take it. Taking that risk, playing that hand, ended up paying off big.

Serverless Transformation at Liberty Mutual

In 2013, Liberty Mutual, the sixth-largest property and casualty insurance company, started to move its services to the cloud, and I was lucky enough to find myself part of the transformation.

I had joined the company back in 2007, spending a few years designing and building a large eCommerce platform with coauthors Mark McCann and Michael O’Reilly, as well as many other talented engineers and leaders. 

I was impressed with the quality of individual engineers at Liberty, but I could see there was still a significant opportunity to create value. I could see that the connection between the business and technology needed work. And (most importantly) I could see that the engineers were crying out for change. But, like many legacy enterprises, Liberty was similar to “a big oil tanker,” any attempt to steer it in a new direction was going to be difficult and very slow.

By 2013, I moved into a CTO position in Belfast. I had built a small team of architects and a pretty solid technical leadership community. Liberty Mutual had begun exploring solutions for security and test data in the cloud using AWS. This was a significant opportunity. I quickly realized that the cloud was not just another datacenter; it could offer a transformational way of working. I just didn’t quite know what that was yet.  I decided that my team and I would try and figure out a way to build better software for the cloud. The cloud was new to many of us and “application development” was our area of expertise. I could sense a paradigm shift and knew it was time to start exploring.

I wondered, “What does cloud application architecture look like in this brave new world?” I knew it would take a few years to be ready for the foundational capabilities (security, governance, infrastructure, processes) to be ready at scale, but I was certain which direction we should take. We had a window of opportunity. I needed a way to map a path, even if that map would change along the way.

Mark and I had begun following the work of Simon Wardley. We were enjoying his technique, called Wardley Mapping, which is a method for building situational awareness in order to map out a potential business strategy. We didn’t fully understand it yet, but it felt exciting and described the evolution we knew was coming. Mapping allowed us to ask questions about how things could evolve, it let us peek into the future and turn hunches into strategies that we could then either test or look for early signs. So, we decided to attempt to map out what we thought could happen with Liberty Mutual’s shift to the cloud.

We asked ourselves hard questions:

  • Will we still write thousands of lines of code in this new place?
  • Will infrastructure as code happen? What will it look like?
  • What happens when continuous delivery is in place?
  • How will the cloud providers like AWS evolve?
  • What things do we do now that we won’t do in the future?
  • What will be valuable for our business when all of this is complete?

We spent many hours writing lots of rubbish on dry erase boards. The architect team grew. And we experimented and worked with peers across the organization to try and better understand the cloud landscape. We didn’t know it, but we were building situational awareness and informing our maps.

Eventually, the team could sit in a small room and discuss the entire technology landscape of a Fortune 100 company, and use Wardley Mapping to predict what might happen in the next year, five years, etc. We had become a sense-making machine. This, fortuitously, coincided with the launch of AWS Lambda.

AWS Lambda was a significant innovation in cloud technology and provided the opportunity for a huge mindset shift for developers. Previously, organizations in the cloud still had to manage the infrastructure (costing hours and hours of developer time). But with Lambda, there was now the option to leave the infrastructure management to the cloud vendor! This could move the cloud from a product to a commodity the business consumed like electricity. This would give our teams more time to focus on creativity and innovation, including operational constraints, performance constraints, the total cost of the solution, and user experience, instead of just keeping the lights on. Teams starting to write systems rather than simply applications. And there were clear cost savings for the business as well.

This was the beginning of what came to be known as serverless computing, where companies no longer managed their cloud operations themselves but gave that toil over to the cloud vendors. With this model, an organization could run an application when needed, shut it down when needed, and pay only when it was being used. 

We had a problem (how to use the cloud to create business value  ), and the answer had presented itself (serverless). The technology was very raw, but we could see the potential. My team and I believed we had a map for the future of technology. We could see the trends that would disappear. We could see the capabilities that would be critical in the future and we could guess how the cloud providers might evolve. We had that winner poker hand I alluded to earlier. We decided to take the plunge and experiment in this new serverless world. Our experiments quickly accelerated our engineering team’s ability to focus on things other than infrastructure management. And the more we experimented in this space, the more we started to see a flywheel effect, small wins accumulating over time to drive momentum. We were delivering more value into the hand of our business partners faster. And we started to see that the cloud was more than just another datacenter. It provided a transformational way of working.

We tried to map out what we were experiencing. First, we had a clear purpose (Phase 1). Next, we had the right environment in which to thrive (Phase 2). And serverless-first architecture provided us with the next best action (Phase 3) we could take to create long-term value (Phase 4) for our organization.

We deployed this same pattern many times, spinning the flywheel again and again, creating more and more momentum and less and less inertia, and the success was evident. Engineers were moving faster, creating lower-cost solutions and more innovative approaches with a better connection between technology and the business.

As was reported by TechRepublic, a single web application at Liberty Mutual was rewritten as serverless and resulted in reduced maintenance costs of 99.98%, from $50,000 a year to $10 a year. That small savings is hugely powerful when you have hundreds or thousands of similar applications running. I’ve seen this type of successful pattern repeated at Liberty Mutual and across different industries.

Thanks to serverless and our flywheel, we were also able to release applications quicker, which meant getting feedback from users and customers sooner. This in turn gave us an advantage in the market to more rapidly respond to customer demands and changes. Serverless also opened up new possibilities that seemed too costly or difficult before, such as integration with AI and data services or event streaming services.

This new mindset shifted our perspective of code as well. Instead of an asset, we began to see that more code was a liability. The less code we wrote, the better. And the code we did write must have demonstrable business value. And surprisingly, our software engineers loved this shift to writing less code. Many didn’t want to go back to “the old ways” of doing things.

We started to adopt what came to be known as serverless-first architecture. In other words, a team’s first implementation choice should be serverless, and if that’s not a good fit, then you work backward (i.e. introduce more infrastructure, like containers). By 2019–2020, things on the cloud front had progressed significantly. At one point, I had four AWS Heroes (Individuals recognized as AWS community experts and who enjoy legendary status!) in my extended team, which was unheard of at the time. Many of the engineers on my team were giving talks and keynotes about our successes at major AWS and technology conferences. And, the business metrics delivered became simply unbelievable: 95%+ runtime cost-savings, new functionality delivered months ahead of schedule, global rollout in weeks instead of years, innovative features leading the market and deploying multiple times a day.

Also, we created a software accelerator using the AWS Cloud Development Kit (AWS CDK), an open-source software development framework in which engineers can use familiar programming languages to define cloud application resources, to help deploy new applications quickly. These acted like code templates that could be used by software engineers to rapidly build projects rather than writing the code from scratch.

I was frequently challenged at external events as these metrics seemed far-fetched (for example, cost savings of 99.5% and similar). Amazon CTO Werner Vogels even started to praise Liberty Mutual and our serverless-first architecture, calling it organizational nirvana. Our “Serverless First Enterprise” concept was starting to take hold.

In a global organization with thousands of people, the sociotechnical element of driving a paradigm shift like this is significant, moving to the cloud and embracing a new way to write software might only happen once in your career. It’s not enough to have some cool tech. Winning hearts and minds is the real challenge.

By this time, we had been evolving our methods and practices for ten years, so we decided to encapsulate them in a set of principles we referred to as the “Serverless First Organization Strategy.” The running joke I had with the tech leads was that it was impossible to measure if the principle was true, but blindingly obvious when it was not! We tried to paint a picture of our ideal software development team:

A high-performing, serverless-first team will:

  1. chase a business outcome (KPI)
  2. be secure by design
  3. keep high throughput of work
  4. reliably run a high stability system
  5. rent/reuse with build as the final option
  6. continuously optimize the total cost
  7. build event-driven via strong APIs
  8. build solutions that fit in their heads

We had learned that our ideal Dev team would epitomize these principles of engineering excellence. We knew from experience that a successful team needed to know what they were doing and should be able to recite the business metrics from memory (principle #1). We knew that security and threat modeling were table stakes; it’s everyone’s job (principle #2). DORA’s metrics for high-performing teams (as illustrated in the book Accelerate by Dr. Nicole Forsgren, Jez Humble, and Gene Kim), provided clear standards for code quality (principles 3 & 4). We worked to spread the attitude of the evolution of technology and the idea that code is a liability (principle #5). Trying to encourage builders that you don’t always need to build is a significant challenge. The great cloud principle and mindset change needed is cost and OpEx. Teams need to be aware of the cost, not to save the company money, but to think frugally and efficiently (principle #6). We set the bar high for integration patterns and encourage clean design (principle #7). And finally, borrowed from our friend and mentor, Dan North, we held that software should fit in your head. It shouldn’t be over-complicated (principle #8).

We often joke that it took ten years to write these eight bullet points, but in reality, it took longer. But the principles landed well, and after considerable risk, many engineers learned in this environment, contributed, and succeeded. Even today, Serverless is still not widely accepted. Learning a brand new way of writing code could set an engineer’s career back considerably, especially if the technology doesn’t “win”. It’s always a leap of faith when moving to a new technology.

The Value Flywheel Effect Materializes

Of course, lockdown changed everything, and we all retired to our home offices and conference calls in early 2020. The “Serverless First Organization Strategy” still stood up. It gave the engineering teams a clear focus, which was build well for engineering value. The collaboration continued, if in a different way. But it was clear that the flywheel we had discovered (having a clarity of purpose, the right environment, a clear next best action, and creating long-term value) was fully in effect now. Not even a pandemic could stop the flywheel from spinning.

As I made sense of this “value flywheel effect” approach that we had worked out, I knew I needed to stress test the thinking with true industry thought leaders—people I respected and who I had followed for years. Life is full of gambles, but I figured that in lockdown, people might have more time on their hands. I (honestly) had only two names on my list—Simon Wardley, who had created Wardley Mapping, and Adrian Cockcroft, VP of Cloud Architecture at AWS (at that time).

I had been listening to and reading the work of both of these leaders for over ten years, but I didn’t have a personal relationship with either of them. After a bit of effort, I tracked them down and asked for their feedback.

My question was simple: I think this idea of the value flywheel effect is good, but why is no one else doing this? What am I missing? Both (who I later learned are friends) separately told me: “No, you’re not mad. This is good stuff. Let’s talk more.”

That positive response and the invitation to collaborate had not been on my map. I sat in Belfast deciding what to do next. Two of my heroes had just told me I’d hit proverbial gold. Well, this book is the result.

In this book, I’ve distilled this set of practices (what I’ve termed the Value Flywheel Effect) learned from people “not doing what they were supposed to.” The practices are all real. They are derived from real experiences, real scars, real success. This is not a book about technology (even if there’s a healthy dose in it). And it’s not a book about job functions. This is a book for all the business leaders, at any level, who aren’t afraid of not doing what they’re supposed to. This is a book for leaders of the future who will forge a clearer alliance between the business and technology in order to navigate the unknown waters ahead of us.

But before we go any further, I must ask you to forget everything you know about the IT department and technology teams you’ve worked in or with in the past. In order to succeed on our journey, we must get away from the mental and physical image of IT as a separate entity or department. Instead, we must create a shared, ambitious goal for technology and the business, as they are increasingly the same. Today, every leader is a technology leader.

The inherent need for IT and the business to unite has been accelerating at breakneck speed for more than a decade, fueled by advances in technology and drastic changes in the way people work. In fact, many have dubbed this the Fourth Industrial Revolution. Unlike the Third Industrial Revolution, which used electronics and information technology to automate production, this new revolution is characterized “by a fusion of technologies that is blurring the lines between the physical, digital, and biological spheres.”

In fact, it’s becoming increasingly clear from the “velocity, scope, and systems impact” of technologies today that we’re in a wholly different era. According to the World Economic Forum, “the speed of current breakthroughs has no historical precedent…evolving at an exponential rather than a linear pace. Moreover, it is disrupting almost every industry in every country. And the breadth and depth of these changes herald the transformation of entire systems of production, management, and governance.”

It should come as no surprise, then, to anyone reading this book that the technological advances of today have a significant impact on businesses. My own story of exploring serverless technologies at Liberty Mutual is but one example. Global leaders and business executives say that “the acceleration of innovation and the velocity of disruption are hard to comprehend or anticipate and that these drivers constitute a source of constant surprise, even for the best connected and most well informed.”

This digital revolution is: “significantly disrupt[ing] existing industry value chains…[and] flowing from agile, innovative competitors who, thanks to access to [global talent and] global digital platforms for research, development, marketing, sales, and distribution, can oust well-established incumbents faster than ever by improving the quality, speed, or price at which value is delivered….Overall, the inexorable shift from simple digitization (the Third Industrial Revolution) to innovation based on combinations of technologies (the Fourth Industrial Revolution) is forcing companies to reexamine the way they do business.”

As we enter this new era of business and technology, it is irresponsible for modern organizations to ignore or waste the potential that effective technology brings to the business, in particular, the power and potential of serverless and the modern cloud—both represent software in it’s purest form, without hardware. Executives must learn to harness today’s technology to drive innovation and power change. They must challenge their own assumptions, continuously innovate, and adapt to their changing environment.

But even with this evidence, some leaders continue to ask if technology is genuinely driving their business forward. Honestly? I imagine if you asked Jeff Bezos or Elon Musk that question, they’d probably reply, “Yes, but we could be doing better.” If digital-native unicorns like Amazon and Tesla think they can do even better, what hope is there for the rest of us?

The question every business leader must ask themselves is this: Is technology really driving your business? There is a significant culture change required to truly achieve this. Just lifting and shifting into the cloud will only give you a nicer datacenter. Simply writing more code only increases your organization’s liability, it doesn’t guarantee you’ll win in the marketplace. You won’t really be benefitting from what these technologies have to offer your business unless you embrace a deeper mindset shift.

The organizations of today and tomorrow need a mechanism to accelerate the business and technology evolution. They must move away from the siloization of IT from the business, which creates an inherent lack of focus. IT departments are valuable parts of the company and have huge potential to create value. They are not costs to be squeezed. Integration of the departments—technology with the rest of the business—is fundamental to the success of the whole organization.

The organizations that recognize this will create a space for innovation. Small successes will breed larger success and spread through the organization like wildfire. This power and momentum will increase, and the path forward will become smoother. This is the Value Flywheel Effect, when the business and technology strategies power and drive each other, turning the organization into a sense-making machine with the ability to easily pivot to the challenges of today and to whatever the next great transformation will be.

Organizations that achieve true alignment between the business and technology will find themselves riding this wave of continuous momentum that the Value Flywheel Effect affords them. To achieve continuous momentum means to be in the lead, to break new boundaries. In the mechanical world, when a power source is inconsistent, a flywheel is used to absorb energy and evenly distribute it so the machine runs smoothly. I believe that both business and technology drivers must merge in this same way to ensure smooth progress forward.

As business technology leaders, the next wave of technology will not worry about servers, instances, and traditional models—it will be serverless. When we free ourselves of the operational burden of managing infrastructure and think about capability more abstractly, the organization can move more quickly. When we let go of the constraints from yesteryear and forget about IaaS, PaaS, and FaaS, we accelerate. We know we need to consume capabilities and assemble systems that will drive our business forward.

The Value Flywheel Effect exists in every organization, but it will turn very slowly if you lock all your engineers in the basement and demand that they crank out code. There is a better way. I have seen it, experienced it, and now I am sharing it with all of you.

I hope you enjoy it and learn from it. Mark, Michael, and I have worked very hard to learn these lessons and distill them into this book. We are so pleased that you are taking the time to read it, challenge it, and (hopefully) evolve it.

The Value Flywheel Effect: Power the Future and Accelerate Your Organization in the Modern Cloud will be released in November 2022. Learn more and preorder your copy here.

- About The Authors
Avatar photo

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

No comments found

Leave a Comment

Your email address will not be published.

Jump to Section

    More Like This

    Lanyards, Icebergs, and Mario: Lightning Talks from DOES Las Vegas 2022
    By Lucy Softich

    One of our favorite events at DevOps Enterprise Summit is the Lightning Talks. In…

    An Automated Governance Superhighway: A Story of Changing the Game to Achieve Your Goals
    By IT Revolution , Michael Edenzon , John Rzeszotarski

    It's okay not to be a perfect steward of DevOps, especially in highly regulated…

    The Frictionless Dev Experience
    By David Anderson , Mark McCann , Michael O’Reilly

    This post is excerpted from The Value Flywheel Effect: Power the Future and Accelerate…

    Sustainability in Software
    By David Anderson , Mark McCann , Michael O’Reilly

    This post is excerpted from The Value Flywheel Effect: Power the Future and Accelerate…