#124 - The Value Flywheel Effect - David Anderson

[00:01:06] Episode Introduction

Henry Suryawirawan: Hello again, my friends and my listeners. Welcome to the Tech Lead Journal podcast, the show where you can learn about technical leadership and excellence from my conversations with great thought leaders in the tech industry. It’s very great to be back here again with another new episode. If this is your first time listening to Tech Lead Journal, don’t forget to subscribe and follow the show on your podcast app and on LinkedIn, Twitter, and Instagram. And to support my journey creating this podcast, subscribe as a patron at techleadjournal.dev/patron.

My guest for today’s episode is David Anderson. David is the author of “The Value Flywheel Effect” and the co-creator of The Serverless Edge. In this episode, David described the value of flywheel effect concept and its four stages: the clarity of purpose, the challenge and landscape, the next best action, and the long-term value. David also explained the importance of Wardley Mapping and how we can use it to help improve the organization’s situational awareness within the value flywheel. During our discussion about the four stages, we also discussed several important concepts, such as the North Star Framework for clarity of purpose, understanding the team’s psychological safety and sociotechnical systems landscape, the serverless-first paradigm as one way for the next best action, and using the well-architected framework and sustainability as guidelines for ensuring long-term value.

I really enjoyed my conversation with David and learning about the value flywheel effect. I find that all the four stages, when used with discipline in any engineering organization, we can bring the transformation and the flywheel effect that David described in his book and this episode. And the great thing is David has successfully used this concept to bring technology transformation and cloud adoption at Liberty Mutual. So definitely there are a lot of practical things we can use within our engineering organization.

If you also enjoy listening to this episode, please help me by sharing it with others who can also benefit from listening to it. Also leave this podcast a five star rating and review on Apple Podcasts and Spotify. It will help me a lot to make this podcast easily discovered by other people. Let’s continue to the conversation with David after hearing a few words from our sponsors.

[00:04:35] Introduction

Henry Suryawirawan: Hi, everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I have a guest with me, named David Anderson. Or maybe I’ll call you Dave. So David is the author of the book titled “The Value Flywheel Effect”. So, in this book, this is a very interesting journey. He gave some principles of how he actually did a cloud transformation. But it’s not just cloud transformation. There are some principles that he also adopt which, to him, is a successful experience, which he shares that can be adopted by many other organizations as well, or teams in the world.

Specifically, David is also a fan of serverless architecture or paradigm. So he has done a large scale serverless deployment. Especially the experience that he went through for writing the book. And also he was the creator of the Serverless Edge. It’s a community that advocates serverless architecture and some principles and paradigms.

So, David, thank you so much for this opportunity. Looking forward to talk about your value flywheel effect and also the serverless.

David Anderson: Thank you, Henry, and thanks for having me on the podcast. I’m a big fan, so I’m looking forward to the conversation.

[00:05:39] Career Journey

Henry Suryawirawan: So, David, in the beginning, I always like to ask my guests to introduce themselves. So maybe if you can share a little bit of your background or turning points in your career.

David Anderson: Sure. So I’m based in Belfast. I’m from Derry, up in the very northwest of Ireland. I’ve always with computer science, always been a software engineer. I’ve spent the first probably 10 years of my career working in telecoms. Did a lot of kind of building big systems and working on big platforms. I then joined Liberty Mutual around 2007 as an architect building an e-commerce system. And I was lucky enough to get a CTO position in around 2013. And I was very lucky, cause I was kind of at the table at Liberty Mutual, started speaking to AWS about the public cloud journey.

So, my background being software, the first thing I thought about was, okay, as we move to the cloud, we’re going to have a lot of security, network, infrastructure, policy questions to answer. Who is answering the question around how do we write software in a cloud native way? So I kind of took on that challenge with my small team, and that led to a large kind of serverless first transformational liberty. Maybe we can touch on that through the book-like. That’s where myself and my two co-authors, Mark McCann and Michael O’Reilly, figure out this technique that we call the value flywheel effect.

Our vision was, can we make Liberty Mutual a serverless first enterprise? Which was a very bold statement, especially for a few architects sitting in Belfast. But I think we’ve seen a lot of successes in that journey. We’ve seen some fantastic things around modernizing applications, having like over 90% savings of run costs. Fantastic speed to market times. Seen massive satisfaction from engineers being able to reduce a lot of the operational burden around standing up big infrastructures, and really focus on the business problem. Deliver business value really quickly, which also created a fantastic cohesion between the business leaders. All of a sudden, IT wasn’t a bottleneck. Technology was now a differentiator. So it really was a lot bigger than me driving this, but there was a general wave of modernization and transformation in the enterprise and Liberty Mutual being a Fortune 100, one of the world’s leading insurance companies. It’s a pretty big company. It was an exciting time to be at Liberty and to be driving that story, and we can maybe touch on some of the stories as we go.

In 2021, I decided to kind of move on to new challenges. And it was Adrian Cockcroft who’s ex-Netflix, AWS, et cetera. He says, “Okay, you have to write a book cause this is too exciting”. I had no intention of being an author. So I thought, okay. I’ll try this author thing and see what happens. So I pulled together a book. I was absolutely delighted when IT Revolution and Gene Kim, authors of “Accelerate”, “DevOps Handbook”, “Phoenix Project”, “Team Topology”, etc decided to add “The Value Flywheel” to their fantastic portfolio of books. I was already in that kinda DevOps enterprise community, which is fantastic.

Then really back to work. I kind of spent just over a year with Bazaarvoice as a Technical Fellow driving their kind of modernization. And I’m currently working for Globalization Partners or G-P, which is a very interesting company. The mission of the company is to kind of break down buyer of the global business, enable opportunities everywhere. A global employment platform that you can hire anyone anywhere in the world. So those are really exciting. We call it a serverless first well architected SaaS. So we’re building a higher employment platform. It’s fun. Again, for me what I find really exciting is practicing these techniques and working with both technology teams and business teams, and to really kind of drive that value. So it’s fun time. So I’d say I’m a practitioner who accidentally became an author.

Henry Suryawirawan: I think very rare people wrote a book with, you know, like a childhood dream. I want to become an author. Sometimes it’s because of an accident, right? Through experience. Then some people advise them to write the book and you become an author. I think that’s also one thing that I also found throughout my interviews, a few guests. Thanks for writing the book, by the way. It’s really a great journey, which I think is worth to share with everyone.

[00:09:48] Value Flywheel Effect

Henry Suryawirawan: So for people who read the title “Value Flywheel Effect”, some people may be confused. What do you mean by that? Do you have like, maybe one statement pitch of value proposition? What is value flywheel effect? And how do you get the inspirations from?

David Anderson: Yeah, well, it’s really around, the thing I noticed was the business technology divide. So that was apparent in many companies. And a lot of companies have got on this kind of wave of cloud, and moved to the cloud, and then the value maybe has not been there. Competition may be treating the cloud like someone else’s data center. It’s just a fancy data center. So to get that real value, you have to really join the business and technology strategy. So the idea of the value flywheel effect is when you join business goals with technology goals, you start to see this momentum, this flywheel effect. So it’s obviously influenced from the Jim Collins' Flywheel Effect concept which is brilliant from “Good to Great”. And then Jeff Bezos also had this Amazon’s virtuous cycle, which is a really nice kind of flywheel.

Really, with the value flywheel effect, what we found is there are four phases. The first being is clarity of purpose. It’s to start with why. If we need to be extremely clear that from technology and business, we know what our North Star is, and other techniques to help people figure that out.

The second phase is challenge. You need to create the right environment. That we can challenge each other in the team. We can challenge how are we going to achieve that North Star and set ourselves up for success.

The third phase is next best action. Once you’re pretty clear on where you’re going and you’ve got the right environment, you will execute quickly. And, for me, that’s bringing in some of the modernization techniques around serverless, etc, serverless first.

And then the fourth phase is long-term value. You can’t build a throwaway. You need to have a really solid understanding of what good looks like. So for me, that’s a problem prevention culture, which is running well-architected and sustainability. How can we build but build effectively for the long term and not just build quickly?

So that is a flywheel that will continue to turn. It’s not just one and done. Once you start that momentum and it builds very rapidly. It’s like a rocket ship. And then one of the things that you end up doing as you implement that is removing inertia, removing sticking points. What is slowing down that movement? Cause as you all know, the move to the cloud, it’s not one and done. You’re on an acceleration journey that gets faster, and you need to change how you think and how you act.

[00:12:09] Wardley Mapping Overview

Henry Suryawirawan: So if I can probably simplify a little bit for people. You take the concept from the flywheel effect from Jim Collins and also the Amazon virtuous cycle. So what I can relate is that it’s an iterative process. It’s not like one big bang journey where people now become transformed, right? Either moving the technology to the cloud or the business becomes digitalized or something like that. It’s a virtuous thing. It’s a flywheel, that’s why. And also, it’s like, a lot of things that you need to align. Alignment from business and technology. So it sounds like it’s very similar to some other techniques, which are also well known. Things like Agile software development or Agile business transformations, or it could be also DevOps or Dev-whatever-Ops these days, right? So what actually stands out from value flywheel effect that probably is different than the other techniques?

David Anderson: Well, there’s a mindset that, for me, is across the whole thing about being extremely collaborative. The main tool that I used as we created this value flywheel effect is a technique called Wardley Mapping. And Wardley Mapping, for me, it’s a complete game changer in technique. When you start to map these different phases, it gives you clarity on what you should do and what you shouldn’t do. I can explain what Wardley Mapping is. For me, it’s really about that idea of strategy and what should we do next. It’s not business strategy or technology strategy. It’s what do we as a team need to do next. And Wardley Mapping gives you that insight and creates that environment that you can build that alignment.

I discovered this probably around 10 years ago. There’s a researcher in the UK called Simon Wardley. The story was, he was a CEO of a technology company, and he realized when he got the position of a high growth technology company as CEO, that all the strategy was nonsense in his terms. He didn’t think it was deep enough. So he came up with this idea of Wardley Mapping, and it starts with the canvas. So the canvas has got an X and a Y axis. At the very top, there’s like a value chain. So at the very top of the value chain, you’ve got a customer. It always starts with the customer, and what’s that customer need. So then there’s a chain under the customer need for a component, which is customer might need, for example, something like a cup of tea. So the customer needs a cup of tea. So then, what does a cup of tea depend on? It could be like a kettle, hot water, some tea. You start to build out a value chain of what things are dependent to solve the customer needs.

So as you think in your head of a value chain, going from top to bottom, the Y-axis of the map is visibility. Things at the top of that chain are very visible to the customer. The customer is aware of the cup of tea, but they may not be aware of the kettle or electricity further down that value chain. But they’re very aware of, they can see the cup of tea. And then from left to right on the bottom, this is the kind of exciting part. That’s where the X-axis is. And this is really the evolutionary axis. For the evolutionary axis, there are four areas.

So the first is Genesis. So every component and tech will evolve in its capability. I’ll explain that in a second. So Genesis are things that are brand new. They’re like, wondrous. I’ve never seen this before. It’s fantastically new. I don’t even know I need this. I’ve never even thought of this. The next phase is Custom. Maybe we understand how we might be able to build them, but we’re not very good at it yet, and it’s still quite emerging. The third phase is Product. Things in the product phase are, we’re starting to get good at building these, and there’s a strong customer need. The customer are aware of these things and they want them. There’s customer demand. And then the fourth phase is Commodity. So things in commodity, we are very good at building these. We optimize them and they’re basically the cost of doing business. The customer may understand it, but it’s like, yeah, everyone has one of those.

The evolutionary axis is what’s really exciting. And the cup of tea sort of map. The kettle, maybe commodity. You know, a kettle is a kettle, it warms the water. The water is likely commodity. The cup, maybe product. Maybe give a nice cup, which adds to the experience. And the tea could either be something very bland, like a standard type of tea, or maybe something very kind of like a high-quality tea. That’s a real differentiator. So that could be more revolutionary. And then every single component will evolve from left to right.

So we think of computers. When computers start being used by business in the sixties, it was this thing of wonder. It was actually in the newspaper when a company got a computer. These photographs of a computer being delivered to a company. Custom is probably more like the seventies and eighties, where there were lots of different types of computers, but they were all kind of different and non-standard. And then as we moved into the PC era, it became product. Computers everywhere. They’re kind of standard, getting different features to solve the need. And now with cloud, they’ve moved in the commodity. It’s not a big deal. Everyone has a computer and you just rent one from somewhere. It’s not a really differentiator.

So using that technique to figure out cloud strategy, business strategy, engineering strategy, it gets really interesting to figure out what’s the customer need. And then what does that depend on? And we can figure out what are the things that we need to be really good at? The things that we can rent from elsewhere. Serverless been a great example, that we can actually rent a lot of the compute and services from a cloud provider and not have to build them ourselves.

Henry Suryawirawan: Thanks for sharing this high level overview about Wardley Mapping. I’m sure like for people, maybe the first time you hear it, you probably don’t get it. I would suggest looking at the canvas itself. It will definitely give you a much better picture and analogy, what David is talking about.

David Anderson: There’s a great site by a guy called Ben Mosior called LearnWardleyMapping.com. Ben’s got some great videos where he explains this, cause you kind of need to, as you say, you need to see the canvas. So I would look at LearnWardleyMapping.com.

Henry Suryawirawan: And I also have a previous episode as well about Wardley Mapping. So please do check it out. In that episode, we talked about Wardley Mapping, DDD, and some other stuffs. Please do checkout.

[00:18:04] Improving Situational Awareness

Henry Suryawirawan: So one thing about Wardley Mapping that I realize, especially when you look at these websites, they always say that you will improve your situational awareness within the organization, be it in the business and technology. First of all, how do you actually improve your situational awareness? And why it is important for an organization to do so?

David Anderson: That’s a great question, actually. One of the things that we started to realize with myself and some of the architects. If I was to sit and write a PowerPoint or a document about what I think we should do, I would go off by myself, write that and present that. Because I’ve maybe spent a week writing that or putting that together. If they give some feedback, it feels like they’re being critical of my work. So that becomes slightly awkward sometimes, especially if it’s a PowerPoint. Somebody is doing a presentation with a map. Several architects might sit down or several experts and start to map out in a collaborative manner. What do we think those things are? And as you’re performing the action of mapping, you start to build situational awareness. Cause people say, oh, we need X, and no, we don’t. We need X and Y. Why do we need that? So it becomes a more attune for conversation. You create the environment where you can challenge and build each other’s knowledge. It becomes less confrontational.

So this is the idea of building situational awareness. So what you’re really doing is having a structured conversation. Trying to find out what’s happening across the organization and what do we need to do? So it’s a great way of building trust within a team or a group of people and getting that situational awareness. Because you can’t have people sitting like writing documents all day and writing PowerPoint or writing loads of code. Cause what you’re not doing is exchanging information. So that idea of mapping is a great way to build situational awareness, cause you’re having more collaborative conversations about how do we need to solve this problem.

Henry Suryawirawan: So it is not just about notation or new techniques, modeling techniques where you come up with a different kind of ways of representing what you want to do, but it’s actually also the collaboration part, exchanging information, or what you also call maps, different maps. At the end, I think the deliverables will be a strategy for the organization to execute. So it could be for a short period of time, or it could be also for long-term period of time.

David Anderson: Yeah. The outcome is almost like, what shall we do next? Throw the map away. The map represents a story. You’re not creating a model. It’s a thinking tool. It’s a bit like the saying about plans. Planning is useful, but plans are useless. So the idea of the action of planning is very important. But once the plan’s on the effect, you got to think on your feet.

Henry Suryawirawan: Yep. I’ve heard about that phrase as well. I forget exactly the quote, but, yeah, I heard about that. So you will fail if you don’t plan, right? But once you plan, you can toss the plan, because in the real battlefield, so to speak, the plan doesn’t always work. So you always need to in adapt.

[00:20:51] Clarity of Purpose

Henry Suryawirawan: You mentioned about the four phases of the value flywheel. So before we start to the phases. Actually, what picks my interest is the sequence of the phases. And you kind of like tag along a persona to those phases. So the phase one is actually for the CEO. The phase one is actually clarity of purpose. The phase two, the challenge and the landscape, are for engineers. So you tag the engineer’s persona there. And then for the third phase, it’s about next best action. You tag product leaders here. And then the last one, which is about the long-term value. You tag CTO. I find this sequence is a little bit odd because normally you come from CEO and then you come to product maybe then to CTO and then to engineers. This is typically what happen in so many organizations. Why your sequencing is like CEO, and then engineers to product leaders, then CTO? Maybe a little bit of explanation on this part.

David Anderson: Sure. We can walk through each of the phases and definitely touch on the persona. And, I mean, I don’t think these are necessarily sequential, but there is definitely an important order there.

For clarity of purpose, I think the CEO needs to be crystal clear on where we are heading as an organization. For me, the CEO is responsible for that vision and mission. That’s where the buck stops. And then be sure that they can’t be changing direction for the boat. One of the techniques we’ve used that’s been great. There’s two different areas that are important here. One, idea of the North Star. I’ve been using the North Star Framework from Amplitude for many years, and it’s a great exercise about asking teams, okay, I understand you’re doing this work. Do you know what that North Star metric is? Can you connect the work to the metric? Like, the CEO was talking about, we’re going to the moon. Is the piece of work you’re doing going to help us get to the moon? And the answer needs to be yes. And if so, how? It’s like there’s maybe one, two or three steps. If it’s like, no, I’m not doing that. What I’m doing is different. Well, is that useful?

The other thing is about time the value. A big part of the North Star framework is leading and lagging metrics. And I think an innovation is a lagging metric. The leading metric is something different. Maybe it’s time to value, fast feedback loops, being able to deploy quickly, be able to have those conversations. So once you’ve got good clarity of purpose, you’re very clear in direction, then you want to obsess over time to value, which is how can we create value quickly and test if it actually is value. Test our assumptions. This sort of idea of like a technical bet. We think there’s a bet that this feature will be useful to our customers. Let’s get in their hands as quick as possible and start the feedback loop. So, really, that clarity purpose is understanding what are we doing and why. It’s very difficult as you know in a software team, if the team doesn’t really understand why we’re doing the work, the work will not be good.

[00:23:33] North Star Framework

Henry Suryawirawan: So yeah, it’s always great to start with clarity of purpose, right? So, for example, Simon Sinek always says, “start with the why”. I think we all understand you need to start with the vision, with the mission, the problem statement to solve for the customer. At the end, we solve for our users, our customers, it’s not for something else. And you mentioned about this North Star framework from Amplitude. So for some people who may not be familiar, what is North Star Framework here? Maybe you can explain a little bit how it works.

David Anderson: Yeah, I mean it’s worth looking it up or just googling North Star framework. John Cutler was the product evangelist with Amplitude for many years. I think he’s moved on now, but he has a lot of great talks about the North Star framework.

It’s kind of like a V shape. You start off with the work, which is your kind of leading metric, and then the project or the piece of work you’re doing might have a measure of success. That measure of success will have an input into maybe an objective, and then that objective will link into a North Star metric. Spotify. They had a nice example about number of minutes listened to by customers. So how many minutes of music are customers listening to? So that was a North Star metric.

And then after the North Star metric, there’s like a long-term value metric, which may be three years out, which can be something like a three to five-year vision. So you always want to be tying your work to that. You know, so you can look at your project and say, well, for Spotify, will this piece of work help increase listening time on the Spotify platform? So if you have a project around fixing up the debug statements in a bunch of classes, and maybe it will, or maybe it won’t, but it’s a nice question to really kind of frame the work you do? And there’s also a nice thing here about mapping. Is the North Star going to differentiate it in the market? Are you just creating a better mousetrap? Are you creating something that’s going to genuinely be different? So there’s a whole idea here of, from a business and product perspective, are we building something that’s going to meet a market need?

Henry Suryawirawan: There are few other techniques as well, which I have heard in the industry. Another one is OKR, or you can just list down a few metrics. So, maybe the differentiator here maybe is just like the way it is being mapped, if I understand correctly.

David Anderson: There’s a theme through the book that this is a collaborative exercise. So it’s not like someone shows you the picture and says, “Here it is. This is the answer”. It’s the team will work through and actually figure out how their work maps to the North Star. And you may have like, it’s a bit like impact mapping. You may have like 10 ideas. It’s like, let’s go after this one, cause we think this one will be best. So again, for me, there’s something deep-rooted in kind of Agile software development. It’s not like you’ve just been handed a piece of work, say, go do that now. You’re figuring out what type of work you can do to meet a goal. So, you know, make sure you really focus on the problem, not so much being handed a solution.

Henry Suryawirawan: Yeah. Focus on the problem, not handing in the solution. So the CEO or the leaders, their job is to actually pick the problem, what they want to solve, right? But then the how, how people will solve it, it’s not something that is defined by the founders or the leaders in the company. So I really like that.

[00:26:36] Obsess Over Time to Value

Henry Suryawirawan: Once you have this clarity of purpose, which is your North Star, let’s say, assume we use the North Star framework. So once we have the North Star, the next step that you mentioned is actually to obsess over time to value. I think this is very, very important as well. If you can touch on like, how can actually people start to think about time to value? Obsess about time to value?

David Anderson: There’s a thing around, what are the metrics that matter? I mean, the idea of having a dashboard, celebrating some kinda metrics. A lot of the work done by the DORA, the DevOps Research Assessment around the four key metrics. You’ve got deployment frequency and lead time. I think there are other metrics, but, really, I think it’s important to understand what do we mean by value? Can we clarify that? Can we be very clear on what is the metric that we’re going to measure value by? Is it minutes to listen to music, or what is that? And then how are we meeting that need? And really, if you have a modern cloud or if you’re in the cloud, you should be deploying very frequently. It shouldn’t be every six months. You should be able to get features into the hands of customers quite quickly.

So I think there’s something about being very clear about the metrics that matter and being quite transparent about those metrics. Kind of celebrating those and creating the right culture that we’re trying to actually improve this metrics and that contains improvement mindset. And they’re not kind of hidden away in some secret report somewhere, or we’re not kind comparing teams with each other. So I think there is definitely a healthy obsession over those metrics that matter.

Henry Suryawirawan: I really like the way you mention it, the metrics that matter. Because sometimes in any organization, you have so many metrics. Do they all really matter in one unison? So that’s also one thing. Are they contributing to the same North Star? And the other thing that you touched on earlier, is that most of the metrics, like, for example, innovation or time to market and things like that, those are actually lagging indicators. So I think in this phase, what you also suggest is that we have to improve the leading metrics that we can control. For example, Spotify’s case, minutes of songs listened, sometimes we cannot really drive people to just play the music, right? But what are the leading indicators that we can drive within our control to improve that lagging metrics? So I really like these two steps.

[00:28:44] Challenge and Landscape: Psychological Safety

Henry Suryawirawan: So maybe if we can go to the next phase about challenge and landscape. The persona tagged to this space is engineers. And you mentioned about two things, which I find really fascinating these days. These are the psychological safety and the sociotechnical aspect of the organization. Let’s start with psychological safety. Why do you think this is very important in your value flywheel effect?

David Anderson: I think the massive piece around being team first. Like the team is the unit of delivery. Teams deliver software, not individuals. Teams deliver software. So it’s really important. Like, a soccer team will win the game. An individual player may contribute, but the team wins the game. There’s no point having a great striker, if you don’t have a defense. So, for me, it’s always been the same in software.

For teams to survive and thrive, you need to create that psychological safety. When you work through a North Star exercise, people are empowered to say, “I don’t understand that metric. Is that really the right metric? It can’t be correct because the CEO said so”. There needs to be some rationale. People may just not understand the thinking behind the metric, which is okay. You need to be in a safe environment. You can say, “Can you please explain to me what that means?” And they should also be able to say, “Well, I disagree with that”, and you can maybe have a conversation. There’s very smart people in software teams, so create the right environment to allow those people to ask questions. So, for me, having that team first environment, the way a team gels, and trusting the team to go after a problem and not have that kind of command-and-control type environment where they’re just told what to do and they’re told not to think.

That’s also part of how we Wardley map as well when we’re figuring out what we need to do. The people are allowed to respectfully challenge the thinking or is that really the right thing we need to do? So that whole idea of psychological safety in how we work is about having that creative kind of environment where we can figure out the best thing to do, and it’s okay to disagree respectfully or by the piece of work. I think that’s massive. Again, keep going back to this, especially in the modern cloud environment. Cause there’s so much technology, there’s so much choice. Someone may have a much better way of doing something that someone else just may not have thought about. You have to create that environment that engineers are allowed to challenge each other and find the best way of doing something. So again, for me, that’s a team first environment every time.

Henry Suryawirawan: I really like that. So team first is always the unit of delivery, right? So again, you touch on it’s not about individual and it’s not only about the leaders who set the direction, set the goals, and also even the how. But it’s always the team. The team comes first. And whenever the team has this psychological safety. Almost kind of like translate to people’s engagement and productivity. They can produce the best quality product or deliverables, simply because they are motivated, they understand, they can challenge. They are also okay to say, “I don’t know”. And also less about blame, right? So if some mistakes happen, people are safe to say, okay, I did make a mistake, and we rectify it together as a team. I really love that. One question, maybe from your journey, maybe in Liberty Mutual, how do you actually gauge a team’s psychological safety?

David Anderson: There’s a number of ways. I mean, I don’t think it just depends on a single person. It’s an organizational measure. And I mean, one thing that I like is I always would look at the retro and agile techniques. Is there an idea of improvement? For me, just personally, that was one of the measures I would use. I would look to see, do I see continuous improvement in a team? Not forced continuous improvement. Do I see the team genuinely trying to make things better? We’re trying things, failing, trying to gel.

So there’s a number of things that I had put in place to try and kind of probe for things. We used to talk about engineering demos that do like kind of engineering excellence. Look at metrics for teams, discuss what they’d like to improve, and then almost like there’s a say-do gap. If the teams say they’re really unhappy with their deployment pipeline, then you know, create the environment or capacity that they can fix it. Could they fix it? Or did they just say no, we didn’t have time? When you go to the team and say, what would you like to fix? And the team says, well, this here is really annoying us. And then you create the environment where they have space to fix it. They should actually fix it. If they have this long list of things that are kind of annoying them and they never get to fix them, that’s a bit of a smell that maybe there’s something else happening. Teams deliver the work. It’s not the managers, the leaders. They create the environment. They help the work happen. So I think there’s a number of things like that, and there’s also something about how the leadership behaves around those teams as well. That’s another very important dynamic.

Henry Suryawirawan: For sure. I mean, there are many topics this day talking about psychological safety. But I really like the way you kind of like pick as an example how to gauge by looking at the, how many kind of improvements the team has done, especially out of their initiatives. It’s not like being told from the top that they need to improve something. Because this means that the team also does a lot of retrospection within themselves. They’re okay to say, yeah, we still do bad in this area and always continuously improve. There are always improvement. I would also be probably concerned if, let’s say, the team doesn’t have any backlog of improvements that they want to do, right? Because that also means maybe they don’t dare to speak up about what things are lacking.

David Anderson: And they might be busy. They might have a lot of delivery ahead of them, which is also okay, and the improvements can drop a bit, but that’s all part of the balance and flow in the team.

[00:33:54] Sociotechnical Systems View

Henry Suryawirawan: The second aspect is actually you mentioned the system is the asset, and you bring up the point about sociotechnical systems view. So tell us what is this system about and what is the sociotechnical aspect of this view?

David Anderson: Yeah. There’s an interesting phrase around sociotechnical, which is a very old phrase. I think it’s still evolving. You can’t think of the system as just a software system, cause there’s also what are the teams that are connected to those components. Massive link here with domain-driven design and, like, what is the organizational structure? Or you can think of Conway’s Law, where your organizational structure is related to your software architecture. There’s a piece here about what is that entire system looks like? Teams and software and that is the asset. That’s the thing you have to design. You see some companies moving people and teams around kind of willynilly, trying to fix the code, and that never really works out too well. So there’s definitely a piece here around thinking holistically around the teams, the organization and the software which it combines to solve that business problem.

It’s a massive note here to Team Topologies, the work from Matthew Skelton and Manuel Pais, which is also a book released on IT Revolution. They talked about four different team types: stream-aligned, complex, platform, enabling teams. So there’s a big piece here around ensuring teams are set up for success of the right goals and are working on the right parts of the system. So I think that’s certainly a combination between kind of engineering management and kind of architectural technical management to ensure that there is a more holistic system at work here, which I think is very interesting. And once you create that environment where teams have a clear goal, then you’re setting them for success. You’re not giving them like 10 goals that they’re just completely overwhelmed.

Henry Suryawirawan: So, thanks for explaining that. Because I think you also mentioned in the book that we need to build or enable empowered engineers within the teams. Being able to analyze not just from the technology point of view or people’s point of view, but the interactions between the technology and the people. And, hence, this term sociotechnical, right? It’s not just about the people, it’s not just about the technology, but the interaction between people and technology. That’s why you bring up things like Conway’s Law, Team Topologies. All this goes into this research area. How do we actually optimize the sociotechnical aspects of any organization? So thanks for sharing that.

[00:36:11] The Next Best Action: Serverless-First Mindset

Henry Suryawirawan: So let’s move to the next phase, which is phase three. You mentioned as the next best action. So once we know the clarity of purpose, once we know the challenge and the landscape that we have, the empowered teams or engineers that we have. The third phase is to choose the next best action. So tell us about this, because it seems very interesting, right? The next best action.

David Anderson: There’re two parts of this. There’re two high-level parts. There’s a piece around developer enablement, creating the right environment for the engineers to move at speed, and that is linked directly to that serverless first strategy. It doesn’t have to be serverless first. It’s more like a modern application strategy. But I use the term serverless first at Liberty, which is very successful.

And, really, the idea is that what serverless first means. So first of all, any kind of serverless technology, it’s something that’s more likely to be a managed solution by the cloud provider. It’s likely to be pay as you go. So you pay for what you consume, and then when there’s zero traffic, there’s zero charge. So things will scale up if there’s a load of demand and scale right back to zero when you’re done. You know, it’s not infrastructure as code or even people talk about function as a service. It’s not really this concept where everything is a lambda or everything is a function. You’re really using services to solve the need. If you need a database, can you get a database behind an API? If you need an eventing system, can you get an eventing system behind an API?

Really, the concept of serverless first is that the first selection when you’re selecting architectural components will be a serverless service. So, on Amazon that could be like Lambda, Event Bridge, Step Functions, even S3, where you’re minimizing the amount of infrastructure that you deal with from a software perspective. Serverless first meaning if for some reason those services don’t work, you may then fall back to something like Kubernetes or a container solution. When we started this thinking back six or seven years ago, there was some things like cold starts, etc. There were some features that weren’t quite there yet. There were more reasons to fall back. Today, in the 2023, there are a lot less reasons to fall back. A lot of the serverless solutions are very robust across all the major public cloud providers.

So once engineers get into that thinking that they don’t have to spend time writing thousands of lines of Terraform to create all this complex kind of, you know, EC2s, they can focus on the problem that they’re trying to solve for their business. Serverless by its very nature is event driven. So you start working more on event-driven systems. That is a nice link back to the stuff we talked about teams, and what the purpose of the team is. Now you get into teams emit events to each other using serverless technology and start to move and think in a different way. This can be sometimes challenging. If you’ve spent the last 10 years working on traditional enterprise Java, this is quite a leap to make. But if you’ve been immersed in cloud or you’re maybe even starting your cloud journey, this is the way. These are the primitives of the cloud, in my opinion. I think there’s a massive shift towards here and there’s lots of really good examples out there of how you build a serverless architecture very quickly.

But again, that idea of developer enablement is a big part of this because you need to create the right enabling constraint for the engineers. One being infrastructure as code. A second being maybe a single path to production around your deployments. A third maybe being a good account strategy or some good kind of cloud infrastructure set up. You think about how security may be slightly different than traditional security. So there’s lots of really exciting thinking in this space, but it’s, for me, I can see this major kind of foundation of how companies are modernizing the cloud.

Henry Suryawirawan: Thanks for explaining that. So if I can understand. You are not just saying everyone should adopt serverless technologies, things like Lambda and things like that. But it’s more about doing the simplest thing you can do to deliver value. So as engineers, we should not be thinking about doing Terraform, creating infrastructure, managing networks, and things like that, but it’s more about doing the simplest thing that we can do. I mean, these days in cloud technologies, there are so many available technologies. You can just choose not just maybe as function as a service only, but they are container as a service this day. There are platforms that enable you to do that. Last time people used to do maybe Heroku or things like that. So I think that’s also another some kind of like a serverless first paradigm, right? The key point here is to do the simplest thing you can do to actually deliver value.

[00:40:33] Code is a Liability

Henry Suryawirawan: And you also mentioned a very interesting thing. You said that code is a liability. So as engineers, our job is not to write the code, but our job is actually to deliver value for the business. So I think this is also very interesting because when people hire software engineer, they don’t just see how they deliver the value, but actually the technical competency. How they write code? How many programs they can create? So I think this is also another important aspect in my view.

David Anderson: Just very quickly, there’s something about engineers understanding what they’ve been asked to do. And sometimes when you have a problem, what you need to do is I need to notify another software component that something’s happened. The problem you have to solve is a communication problem between A and B. Some engineers will say that, okay, I need to stand up a Kafka eventing system and they start building this huge platform. And it’s like, well, that may be the answer, but the problem you have to solve is, how do I get an event from A to B?

Now, what’s the simplest way I can make that happen? Maybe it’s even SQS, to start with that. And then, as things start to get complex, then you can think about, okay, how do I scale that? Don’t move to that high scale infrastructure solution first.

Henry Suryawirawan: And also it depends on the context of the organization, right? Some organization may have capability in Kafka, maybe they have a platform team, so you can just tap on that expertise. But some organizations may not. So don’t just introduce new technology simply because it’s the fancy and the latest hype out there. Do it in a simplest way to bring the value fast. So I think that’s the next best action.

[00:42:03] Long-Term Value: Problem Prevention Culture

Henry Suryawirawan: So let’s move on to the next one, which is about long-term value. So this one you mentioned about problem prevention culture. Maybe a little bit of explanation how we can actually do this problem prevention culture.

David Anderson: One thing that used to sort of worry me slightly is that there’s this idea that we don’t need architects anymore, and architecture is becoming less important. Architecture is very important. You know, if you’re sitting in a house, you should hope that it’s been well architected.

It was always problematic for me that how do we communicate this to all of the organization, sometimes, like, this feature has to scale, so we need to spend several weeks figuring out how to scale this. So it’s working, but it’s not ready. You want to reward teams for doing the work upfront to make sure that scales. You can’t reward individuals who, when a system doesn’t scale and falls over on a Saturday, to jump in and fix it. So let’s try and reward the people who prevent the problem rather than the people who fix the problem. Cause that’s the sign of good engineering. People can predict where these things are. And, for me, we’ve spent a lot of time trying to communicate this. A big fan of the well-architected framework that AWS uses.

Well-architected is a phrase that AWS, Google, and Azure all use, and they all have their own versions of well-architected. So whatever cloud platform you’re in, I would go and look at the well-architected framework for that provider. But the experience I have as an AWS where the well-architected pillar framework has six pillars. So it’s security, cost optimization, reliability, operational excellence, performance, and sustainability, which is the new one was added just about two years ago. And, really, each of those pillars has usually around 12 or 13 questions with a lot of best practice. What I did in the past was instead of having that as a service where an AWS architect comes in and assesses your workload, teams could assess their own workload and turn that into a continuous improvement practice. So the team could say, well let’s spend Friday morning doing the operational excellence pillar, and they may spot that the runbooks are out of date. So let’s add a story to our backlog around continuous improvement to update runbooks. Cause it doesn’t seem that important now, but when the system falls over on Saturday night, it’s going to be really important that every runbooks are correct.

And that, for me, is a good problem prevention culture cause the team may go through a checklist and realize it doesn’t apply and that’s okay. But the team has the context and expertise to understand what will be problematic. And they’re getting advice from the collective wisdom of all the cloud vendor architects. Here are all the things that we have seen gone wrong, distilled into good practice. Now you would be a fool not to read that good practice and see if it applies to your workload. So, that’s the idea of a problem prevention culture. And I think if in an organization there’s a modern cloud capability, should be empowering your teams to do that work and really harden the system because the cloud fails all the time. Distributed systems fail all the time. So we need to ensure our teams have the capacity to prevent these problems from happening.

Henry Suryawirawan: So yeah, I’ve seen these well-architected frameworks from different cloud providers. They are really good. I would also highly suggest people reading those frameworks because they touch on many things, not just one aspect. So from AWS, you mentioned there are six pillars now.

[00:45:26] Well-Architected Framework

Henry Suryawirawan: One question from me is that those things seem to be specific to cloud, right? So does the organization also need to create their own version of well-architected framework? Maybe span not just from cloud perspective, but also maybe application development or some other aspects within the organization?

David Anderson: That’s a good question. Do you remember when people talk about non-functional requirement and the -ilities. No one could remember what all the -ilities are cause there’s so many: scalability, observability, reliability. What I think is nice about well-architected is you’re saying we’re going to look at these six things. I have done well architected reviews on on-prem systems. Cause you can still ask a question about a runbook, about the cost of the system, about security, about authorization, authentication, you know, rules. All the same questions apply. The answer may be slightly different because, sometimes, an AWS will say you should look at ControlTower, for example. You need to think, what’s behind that? So you can still use the same approach for regular workloads. They don’t have to be cloud workloads.

But again, for me, it’s a way of standardizing on those non-functional requirements that apply to every team. Cause one thing I used to notice is that team should say, oh, we’re different. We have a high amount of transactions. And we’re different cause we have low transactions, but they’re high value. So every team is completely different. So I’ve been able to say, okay, let’s assess reliability across all our teams. The answer is different for your application. But you can still say, do you have any critical risks in liability, reliability, or do you only have low risks? So, really, a good architecture is about managing risk. So you need to educate your teams on what are the pillars, and help them assess their own level of risk, cause they understand their own context.

Henry Suryawirawan: That’s a very good point. So when we talk about long-term value, it’s not just about the fanciness of the framework we use, but it’s actually to prevent problems from cropping up in the future, especially when scale or when the load comes suddenly. Your system should be able to kind of like withstand that pressure. And, definitely, well-architected framework. The name itself is like, well-architected, right? That means there are so many experience or design patterns or best practices that people have come up with, so you don’t always need to reinvent the wheel and come up with your own version.

[00:47:42] Sustainability

Henry Suryawirawan: So one aspect, which I think is really important, you mentioned in this long-term value as well, is about sustainability. I know it’s trendy topics as well these days, but how can all the organizations or all teams think about sustainability aspect? Because some people might think, yeah, I’m just a small company or a small team. I don’t have a big impact on this. So maybe you can have an explanation on this part.

David Anderson: Yeah. So I think this is a great measure of good architecture. I think sustainability is hugely important and there’re lots of different aspects, but specifically for software. If you have a software system, one of the things that we used in the past to measure how efficient that software was cost. You could look at the actual cloud bill, and lower cost is more efficient. But then sometimes the cloud providers will give like cost savings plans and different discounts. So maybe hide some of the lack of utilization. Now what a lot of the cloud providers are doing is giving you a carbon score for how much carbon that workload is using. So it’ll be an actual measure. Now, it’s very hard to be very specific on this measure. It’s calculated by the cloud provider. You could pretty much say that a lower carbon score or carbon burn is a more efficient architecture. And even though there’s a lower carbon usage, there’s likely going to be a lower cost, and it’s likely going to be a simpler or a less complex system. It’s probably designed or architected slightly better than one that’s very wasteful and burning a lot of extra cycles it doesn’t need.

So it’s a nice kind of measure to think as a goal. How do we write sustainable software? So it’s really about being efficient and writing well designed software. Because you think about it, if you think of a Lambda function, you know, it’s API call, it spins up, it runs for maybe 500 milliseconds and disappears versus an EC2, which is running 24/7 with the API open. One call serves that in 500 milliseconds, but it keeps running and waiting, you know, the amount of compute used between Lambda and EC2, it’s way different. So, really, it’s that idea of can we start to think of our carbon usage measured by the cloud provider as a nice measure for good architecture. And as AWS say, they take care of sustainability of the cloud. They’ll make sure the data center is sustainable. You have to make sure that your workload is sustainable, i.e. efficient. So I think that’s a really nice kind of measure with how we can build good systems.

Henry Suryawirawan: You touched on a very good point, I would say, that a good architecture is efficient, and probably also gives a very low carbon footprint. Now these days there’s so many technologies that can just easily spin up, spin down. You don’t always have to have a VM running all the time. Or maybe except your database, I guess, right? People don’t want to have database being spinned up and spinned down. But yeah, apart from that, I think for many backends we can touch on a more carbon friendly technologies. Things like containers or serverless paradigm, serverless technologies. And I think everyone has the responsibility, I would say, to play our part in sustainability, because the world is also changing because of this climate change and things related to sustainability. We all have our responsibility to save the world, so to speak.

[00:50:45] 3 Tech Lead Wisdom

Henry Suryawirawan: So David, it’s been a very exciting conversation. Unfortunately, we have to wrap up pretty soon. But I have one last question that I would like to ask you, which I call the three technical leadership wisdom. So you can think of it like advice for listeners out there, maybe from your experience or from your journey or from your book. So what will be your three tech leadership wisdom?

David Anderson: Oh, that’s a good question. First one, I think, is probably around your writing ability, concise writing. I think writing, the same as coding, whatever language you use, you should be a master of that language and be able to write in a concise manner. As engineers, we often learn mathematics and programming, and we don’t really learn how to write, but it’s very important to be able to communicate to a lot of people to write well. And writing is also a thinking tool, so it helps gather your thoughts. It’s a lifetime practice. You can always get better. So I think it’s good to focus on concise writing.

The second one’s probably emotional intelligence, which I think is an interesting one. I think as you’re a tech leader working with a lot of engineers, I think you need to understand the dynamic in different conversations and where people are coming from. You can’t just assume that you’re correct all the time, and everyone else is wrong. You need to consider, you know, different roles, different experience. So it’s really important to at least understand emotional intelligence and understand different signs, etc, and just be a good human being.

And then the third is probably a funny one. It’s okay not to know the answer. People often assume that the technical lead knows all the answers, but, often, they just know how they ask a question, or they’re brave enough to say, I don’t know the answer. You create a good environment.

So you probably find that all three of those, they’ve not really much through with technology, they’re more to do with communicating with people. I think being a technical lead is more about how you can work with other people in your teams. You still need to know the technical knowledge. You still need to build the code. That’s all still really important, but you need to have those really strong communication techniques. So I would say writing, emotional intelligence, and it’s okay not to know the answer.

Henry Suryawirawan: I really like the last one because many people think by being leaders, you need to have all the answers. You need to be able on the spot give some suggestions or fix the problems. But many things in software technology these days are really hard and they’re always new, right? So I don’t think anyone could ever master everything. So it’s okay to be vulnerable and say, I don’t know, or I’ll try to figure out next time. So, yeah, it’s a very good and beautiful message for leaders out there, especially the engineering leaders.

So, David, if people want to connect with you, they want to find out more about your books or your writings. Is there a place where they can find you online?

David Anderson: Yeah, we’ve got the Serverless Edge, which is ServerlessEdge.com. So that’s where we’ll have a lot of our blogs, and we have a podcast called Serverless Craic, which is Craic that’s spelled C-R-A-I-C, which is kind of an Irish word for kind of good fun. So myself, Mike, we do a very short podcast. We just have a bit of fun talking about these concepts. And, obviously, the value flywheel effect is available for all good book sellers from IT Revolutions. So it’s on Amazon, on Kindle and Audible and Paperback.

Henry Suryawirawan: Thanks. I’ll make sure to put all of them in the show notes. So thank you so much for your time, David. I really enjoy our conversation.

David Anderson: Thank you, Henry. It’s been a pleasure.

– End –