Episode #128: Serverless-First Engineers and the Flywheel Effect with David Anderson
March 14, 2022 • 52 minutes
On this episode, Jeremy and Rebecca chat with David Anderson about the importance of being Well-Architected, what companies must do to embrace a serverless transformation, the evolution of Serverless-First engineers, how to accelerate your organization to the "modern cloud" with his new book "The Flywheel Effect", and much more.
Dave Anderson is currently a Technical Fellow with Bazaarvoice, where he focuses on product development, and technical and strategic leadership. He also is a contributor at The Serverless Edge, a blog for engineers, architects, and leaders interested in serverless, where he explores the narrative building on the new ways to create business value through software and technology.
Prior to these roles, Dave has led transformation, technical excellence, cloud adoption, fintech/insurtech strategies, technical community activity, and both participated and led several enterprise/organizational transformation efforts. His experience also includes frequent collaboration with senior executives, engineers and business sponsors. With Liberty Mutual, he designed and implemented large scale internet eCommerce systems and distributed web platforms. Operating as a tech startup within a Fortune 100 company, Dave led a period of digital disruption that put the organization ahead of the competition.
Hi everyone. I'm Jeremy Daly. Rebecca:
And I'm Rebecca Marshburn. Jeremy:
And this is Serverless Chats. Hey Rebecca, what's going on? Rebecca:
Hey, Jeremy. You know, not a lot. Just having breakfast drinking some coffee. What about you? What are you up to? Jeremy:
Well, I actually have been on a bit of a health kick recently. Rebecca:
I have lost 14 pounds in the last couple of weeks. I went to re:Invent and I was just, I think I was breathing too heavy. So this is part of my, I'm trying to reduce my carbon footprint by weighing less and needing less oxygen. So that's, that's my goal, but I also have a vacation coming up, so there might be some vanity in this as well, but let's go with the sustainability. Let's go with that first. Rebecca:
Yeah. And how you, I think my biggest health kick is that like, you know, I eat salad for breakfast. What are, what are you up to, how are you feeling about it? Jeremy:
So I am doing the keto stuff, which I've done in the past. And the first couple of days get, you know, you kind of run down or whatever. But then once you get into the, you know, the groove of it, you know, it's like bread and all that kind of stuff yeah, you know, I can do without it. So, but I've been exercising a little bit as well. but actually speaking of healthy living our guests today is a marathon runner or a marathon level runner. And from what I hear an avid mountain biker, but he's also a brilliant mind when it comes to technical and strategic leadership. He's a huge advocate of serverless, or the serverless first approach I should say. And a Wardley mapping expert. Would you like me to introduce him? Rebecca:
Yes, please do. Edge of my seat.Jeremy:
All right. So our guest today is a contributor at the serverless edge, a co-host of the Serverless Craic podcast, a technical fellow at Bazaarvoice. He is our friend from Norn Iron, Dave Anderson. Hey Dave, thanks for being here.Dave:
Thank you very much. I thought you were talking about someone else there with all your kind introduction. You're too nice. Thank you.Jeremy:
Well, I have, my first question is, have you run any marathons lately? Dave:
I ran Belfast a few months ago and I'm planning on running Belfast again though, on the start of may. Just did a long run last night, so I'm kind of sleepy here. Rebecca:
A long run last night. Well, I can't say I did the same, but I'm very proud of you.Dave:
Yeah, it was tough. It was tough.Jeremy:
I try to get like three miles in every once in a while, and that's pretty much enough for me. I just, I can't do the marathon thing. My body is not built for marathon running. Dave:
Oh, it's a thinking time. That's the way I think about it. Thinking time. Good time to listen to a few podcasts.Jeremy:
Oh, that's true. That's true.Rebecca:
That also is perfect because it leads us into our first question. I'm curious if you could, you know, tell, well, this doesn't really lead in to the first question, but I'm going to make it. We're gonna shoehorn this. When you think about things, what in your mind, what would you say, like how would you tell the audience a bit about what you're doing and your role at Bazaarvoice and what led you there?Dave:
So, Bazaarvoice is a really interesting company. They're about 15 years old based in Austin and they supply a lot of the user generated content for e-commerce and online retailers. So something like 65% of the top brands use Bazaarvoice for reviews, questions and answers and a kind of social commerce content, which is like, has something like 12,000 brands and retailers. So really my role there as technical fellow is really looking at the technical strategy of the company and how we can move forward. It's kinda like a startup that's 15 years old. So it's been, it's been really exciting joining there. I've been there for about the last four months or five months. And it's a really exciting industry to be in. You know, retail. It's new to me. So lots to learn. But definitely it's really fast moving and a lot of really, really great engineers. So it's an exciting kind of growth area for cloud. And we're, we're all in on AWS, which is, which is cool as well. Lots of stuff to play with. Jeremy:
Yeah. So you have a little quote or whatever on the serverless edge site, where you talk about being passionate about driving technical strategy and helping others with the transformation journey. And then, you know just that you've done this you've led several enterprise slash organizational change efforts over the course of your career.And one of those places which we have to mention is Liberty Mutual or Liberty Information Technology. You were there for 14 years. And you were a major part of that serverless transformation and the effort there. I'd just love it ifyou could tell the audience a little bit more about that. Dave:
Yeah, that was a fantastic journey over the past few years. And really I was looking off, I took it like a CTO role with Liberty IT back in 2013. And that was just with the time that we were starting to talk to AWS. So I was at the table when we had these initial conversations with AWS.
And the thing I noticed was the conversation was almost security-led. It was all about security and policy and stuff. And I can, I had a small team at the time with a few architects. There's only three or four of us, and I can realize there is potential here to reinvent how we write applications. It's like, while everyone's figuring out, you know, network security, governance, all that, all that good stuff that needs to happen first, we need to figure out how do we build applications in the cloud? And we were lucky enough. We had a few people at re:Invent in 2014 where, hey, Lambda was launched. So in 2015, we started planning on Lambda, as you know, is this a potential direction we could go in.
And we started thinking of things like, how do we get rid of the operational burden and build functionality quickly? And that became serverless first. And we use the points of things like Wardley map and et cetera. And we just started to create this approach, to form this idea of serverless first in a big enterprise.
And we just, we just kept going. We kept getting quick wins and a little win and making massive impact and we'd take applications that were like $50,000 a year to run. And we'd turn it back to $10 a year, and people were just blown away by some of the changes we were driving and just created this almost like a movement around the organization about this different way of building.
And sometimes it's not about the detailed explanation of why. It's just like, this is faster and cheaper. People are like, okay, I can get on board with that. It was great as well cause at Liberty IT in Belfast, the team grew to about, I think, 12 architects. It's a whole bunch of people we can talk about later about, we had expertise right now in the entire enterprise.
So we started thinking this idea: You know, could we frame Liberty Mutual as a service first enterprise? You know, it was kinda like go big or go home.
And people started listening. So it was just, it was an incredible story. I'm so proud of the work we did there. Like, I'm sure we can talk with the team, but it's just, there's so many ways we drove that different mindsets and I'm really delighted to see more stories today about the great work that's happened at Liberty Mutual. So it was a fantastic experience.Rebecca:
I just thank you so much for you knowing and sharing that like deep, deep origin story. Where you said, you know, 2014, you're like, wow, there is potential here to reinvent how we write applications and then you do that out and it ends up being there's potential here to redo how you do business, right?
To go from $50,000 to spending $10 on something and applying that across an organization that probably has a lot of 50K spends in different places. So that led to this idea, i,t sounds like where you, the nomenclature, right? You called it or named it serverless first. Wondering if you can define what serverless first means to you and to the Liberty org and whether or not that changed over time.Dave:
Well, from a few different efforts of change, you realize that sometimes if you're extremely detailed upfront, you turn people off. So we just started talking about serverless first and a different way of building. And we started to slowly define what that meant. So we started to say things like event driven, well-architected. We talked about the serverless first spectr you know, start with serverless and managed services and work your way back through, you know, containers and even back to like, you know, the likes of cloud foundry, et cetera. So really giving people that prioritized list to work backwards from. We talked with engineering excellence, it's that we will take great pride in how we build. We'll have umpire teams.
So we can, we grew it to be slightly bigger. We'd be driven by a KPI.
And not just, you know, not just writing a feature, but actually driving the business KPI. So this all led to teams that were more self-sufficient and more responsible. And again, there's a couple of really nice things for Liberty Mutual. One of the phrases was responsibility is our policy. We're like, yeah, we can work that into it. One of the phrases with auto was the fact that only pay for watch you need. For your auto insurance. So we thought, okay. That sounds like a serverless thing. Only pay for what you use. So we started folding in the corporate kind of directions, which are really solid and linking them back to what the engineers were doing.
The engineers loved this because it was all of a sudden tying us to the business. And then when we did sit and talk to the business, we were talking the same language. So I've not consistent language from the engineering teams to the business leaders. It's just, it's just was incredible. This idea of experimentation as well.
You could try things really quickly and see if it worked and then you'd have the scale there if needed. So it's just about tying those, tying those things together the whole time. So it was, it's just fascinating to see how it grew.Jeremy:
So you talk about all of this work that Liberty Mutual did and all these sort of, you know, just the, the evolution of that serverless first mindset and what that meant within the company. And we have a mutual friend, Matt Coulter who built that CDK patterns library.
And then we just had Christie Perrault on our last episode. She's from the US, works with Liberty Mutual and she was talking about the internal patterns library. You know, that's available so that, you know, developers can just grab this right off the shelf, and then not only can they start quickly, but also follow a bunch of rules and standards and all these things that are already approved. You know, so this is amazing, right? And just super well implemented. We've heard of other companies like Lego, for example, that have teams that are just about, you know, basically, I guess, you know accelerating their development process. They've even gone and extended the well-architected framework to make it more stringent for their particular needs. And I'm just curious, you know, Liberty Mutual, Lego, some of these bigger organizations have very, very large IT departments or very large development teams. So it makes sense that they can do this. It's not quite as simple for small or even mid-size orgs to find not only the time and the resources, but like the right people that can actually lead these charges.
So, I'm curious, you know, from your perspective as somebody who's done this in a larger organization, but I know it was also working with, with others, you know, is this just immaturity in the space? I mean, you know, it's been five plus years now, but it's still a bit of wild west out there, right?
So is this just something where we think, you know, it just needs to mature more and all the tools and the best practices will be out there? Or do you think that this is still something that most organizations are going to need to deal with for a while and kind of go through their own learning, or on their own journey, I guess, to discover the benefits and the best practices and the implementation that works for their organization?Dave:
I would hope that, I think a better understanding of how engineering works. Engineering has to be part of the organization. It's not the IT department. IT is not a cost center. It's a value driver. So I think when teams open, companies appreciate and realize that, and you can let the engineering teams build a valuable, then the question becomes, how can I help the engineer teams build quickly?
One of the initial ideas, myself and Mark McCann had is about the act, the act of enablement, technical leadership through enablement. It's leading from the back of the room.
You know, and as people join my team, we led from the back of the room. We enabled other teams to be successful. And it was often the thing where you sat back and you didn't, you weren't really in the front line.
So I think the idea of providing enablement capability to teams is really powerful. You're not kind of driving the teams to, you know, type in code faster. That's not what it's about. It's how can you give the teams the tools to do what they need to do? We had several attempts at finding that toolset.
We had a couple of failed attempts at building that internal developer platform, but it was when CDK came out, that we'd seen there was real value there. And I'd been trying to push inner source for several years before that. But Mark, I think, joined the team in about 2019. And the first thing I assigned him to was CDK, is look at that, we think there's potential in that.
Because we could see that cloud formation was slowing people down. So that idea of creating the building blocks you need, and the Lego analogy is brilliant. Adrian Cockroft talks about having better bits of Lego that you can build your systems with, but you need to be very clear in what kind of guardrails you're going to put in for your engineers and what tools you're going to give them.
And you really need to understand, you know, where your value proposition is. There's far too many companies building what I would say too low down on the stack, and they're trying to build too much stuff. So I think there's a little bit of companies understanding what their engineering is for. And giving them the right tool set to do that.
I think the tools are there today, if you want to take that approach. Like CDK patterns is absolutely awesome to take those patterns in and those higher level constructs, but you have to have engineering leadership if you're going to pave the way and let those things happen.
The thing I was able to do in Liberty Mutual was go in the C-suite, the executives, and say, we're going to take this approach to get this benefit
People like, okay, I'm good with that. If you don't join the dots in the C-suite, then you're, sometimes you're fighting a losing battle.
So I think it's really important to, it's often a different message you put into the C-suite when talking with the engineers, but sometimes, you know, you need to think of it in a, this is how we're going to deliver value for the organization using these tools. So I think the tools are there, but maybe not the attitudes in engineering leadership in some companies.Jeremy:
Now I've never known any company to be slowed down by cloud formation though. So. Rebecca:
Yeah, now you're just talking crazy talk now. That's such a mirthful laugh, Jeremy. Dave, you discuss a few things that maybe failed in the beginning or you all were working through internally, Okay, how do we apply this type of thinking and how do we help spread that across the org? Can you talk a little bit more about some of those internal adoption struggles initially, and then what helped you sort of build out of those?Dave:
Well, one of the best techniques that we started looking at was Wardley mapping.
We started Wardley mapping probably maybe about 10 or 8 years ago. And we just, it took a long time to figure out how to do it. But eventually when this idea of genesis, custom, product, commodity, when that finally landed, we really look at things and say, that's a commodity.
With this thing is custom. It needs to be product. How would you move certain things? And I'll give you a good example of that. A lot of our traditional guys spent a lot of time working with infrastructure and security, spent a lot of time in those grips working with those really brilliant, brilliant professionals and engineers, but infrastructure always want to build front in front of something.
Let's build the front before AWS. You can go through this thing to get data with AWS.
And you think a lot of guys, we, we don't need to do that. That's not providing us any more value. You know, let's just write some really good standards and not build the front in front of everything. So there was always that early approach to let's wrap the cloud in something.
And you just know that you're going to run into the road if you do that. So those things like that, We then we, for a while we got too opinionated. We built the most amazing framework to do everything for you and it got too bloated. So, you know, we went, we protect the developers. Don't make it too opinionated.
And eventually we got to the idea that let's open things up and take this InnerSource approach where we let engineers change things. We trust them to add value. But we provide some guardrails, like the knowledge for that was through well architected. So it was definitely a learning experience. But I think at the end of the day, developers need to have control of what they're doing, which is really important.Jeremy:
Right. And I want to dig into Wardley mapping a little bit later, but let's go back to talk about trusting developers right? So trusting developers, I mean, we should, right? We should be able to trust them as long as they are up to date and they know the technologies that you're using. So you have this evolution of developers who were writing code, throwing it over the wall. Somebody else's handling that, moving to this idea of a serverless first developer. And you wrote a great article, I think maybe last July, about the evolution of the serverless engine, or a serverless first engineer. So could you talk a little bit about that and what you mean by a serverless first engineer and really what do you need to do now, or what is a serverless engineer, maybe? A serverless first engineer. sorry. Dave:
Well, I think, I mean, the whole idea is that I think the most important idea is code is a liability. You know, I think that's the key idea behind that attitude that you're not going to, you're going to try to avoid any operational overhead and write as little code as possible. And you're hopping off to pass on certain capabilities to the cloud provider.
I think that that's the most important thing. I think this idea of being able to kinda break up what you're trying to do. I think about what, do I need to write versus what would I like to write? That's a big leap of faith, I think for any engineers. And again, I think there's certain things like eventing and how you write your functions, et cetera, is all very important, but I think being very clear on the business outcome you're trying to achieve, I think is the most important thing. I know Sheen Brisals from Lego talks about the rocket ship, is that once you start writing in this way, you're on a rocket ship. We are, you can't really get off. You're you're, you're almost committing to this constant evolution architecture of what you're doing, where it's, you're always optimizing and improving things. I think that's very much a mindset.
It's sometimes the engineers that have kind of stopped learning to find this as a difficult place to kinda go.
But there's always engineers that are hungry to learn the next thing. And, that's some of the engineers that really enjoy this kinda serverless first kind of environment. I've had many conversations with engineers that were maybe apprehensive about serverless first, or didn't quite understand why. I think there's a bit about reassuring those engineers, that this is actually a good direction to go in and we can actually, it's a better space to be an engineer and you can build more quality. You can, there's a lot more things you can do as value add. So I think there's, a whole package around being a serverless first engineer, I think is really interesting. But it's not very well understood.
I don't think it's a great phrase serverless first engineer, because it's quite difficult to describe, but there's a certain mindset there. That's kind of always evolving, which I think is interesting for engineers.Rebecca:
I'd like to dig into that a little bit more. So we recently spoke with Eric Johnson, who is a DA at AWS, and he was really excited because he's now going into universities and sort of piloting this program. By teaching serverless ideas or like, you know, the paradigm shifts to engineers and university who are still learning, you know, like C sharp.
And so I'm wondering as you're bringing new team members on and like new serverless first engineers, you're talking about like, Hey, it's kind of hard to find people who are already thinking in this way, or, you know, maybe you find a great engineer, but then you have to establish whether or not they buy into the paradigm or want to shift to the paradigm or just like can step back and be like, okay, yeah, I'm gonna develop in terms of what I actually need to write versus what I would like to write. I'm curious if you're going to talk a little bit about how you've seen that evolution with engineers, cause I imagine that, you know, even still the crop of engineers coming out of university, let's say the younger folks are, they may have been exposed on their own, but they haven't been exposed in terms of what they've been learning in the traditional methodologies of learningDave:
I think the mindset is engineer over programmer. I think that's absolutely critical mindset switch. If your job is to write code, then you'll write code. If your job is to engineer a solution, for whoever you're dealing with, your stakeholder, then it becomes a completely different proposition. And often I think coming out of university, if good programmers, and then you need to almost convert them into engineers. How do they solve problems? I think technical coaching is a huge part and, I spent, you know, if you think of the whole team at Liberty, I think we had,
you know, a really strong team. I think we had 4 serverless, we had 4 heroes and a really, really strong group of people. We spent a huge amount of time speaking to engineers, coaching people through lots of kind of engineering excellence kind of reviews.
And I was like a broken record. People would say, I've written this great thing, yada, yada yada, and say, well, what's the business KPI? Or where's the value? Or how much does it cost? Just bring in a subtle commercial question to okay, love the fact that partner's really cool. That's brilliant. But what problem is that solving. For who?
And then if you say, well, yeah, it's a really complicated will, could you not just use step functions for that? I think so, but I really like this language. Okay. That's good. But so bringing it back to, and I think it's really powerful for engineers coming out of college, they have those technical leadership role models that will ask them the right questions.
I think that they will have that technical leadership, as you know, grilling the engineer, you have to do this casting them out, you know, putting them on there, putting people on their kind of back feet. That's, that's completely broken for the modern way of work. You want someone who has been done this before. Who's got some experience who can maybe point out, well, you know, why did you do that? It's more of a coaching conversation to help people learn in a safe environment. So I think that's really important to kind of bring people new into the industry. And that way of your role is to engineer solutions for your, for your business partners.
And that's where I think serverless really comes into its own because you can do that quickly and you can be laser focused on that.Jeremy:
And I love that phrase you know, sort of taking people from programmers to engineers or transforming them into engineers, because I think of it now as like, you almost don't want to hire programmers, you want to hire cloud architects, right? Because you have to think all the way through. And I think about how much code I write now, even when I'm building an application, I'm like did I really only write like, you know, a hundred lines of code? And that does, you know, and then I plug into, you know, then I write either, you know, 10,000 lines of cloud formation, or I use it in a framework, but essentially, you know, all that cloud formation or whatever framework I use to transform it into cloud formation, essentially, that does 90% of the work that I normally would have had to do in the past. And one of the things you mentioned, in the article is this idea of cognitive burden, right? And that idea of sort of thinking through all the way from, you know, what is it that I'm trying to experience or what am I trying to accomplish? You mentioned this idea of what's the business value there and putting all that in.
I think a typical programmer has always been a problem-solver and always trying to solve those problems. But this is just, I don't want to say it's harder. I mean, cause I think it's more exciting. I think it's more interesting, like you said, you have more freedom, you can do more things. You've got more control. You have more control by giving up control, which is kind of crazy, but if you think about it that way. But I'm just curious, like, what are those extra bits of cognitive burden that we do put on developers that are moving into this sort of cloud architect space? Dave:
I think that's two funny stories about that. I always remember it. I was working on a stack a good few years ago and we, one of the engineering leaders was curious to why it was taking so long.
And I said, well, look at how we've designed the stack. There's many layers to the stack, and only 3 people who know the entire stack. And if you have a conversation with someone's engineers and you ask them the question, you can see the cognitive burn in their eyes, as they try and think through this huge call stack, it's just too complex. We haven't used like domain driven techniques to break this down. And they kind of, you know, as Dan North says, this doesn't fit into my head.
And I think with some of the cloud architectures, if you do break them up properly, things can fit in your head. You know? So I think there's, it's old architecture, that's decades old, but it's just the fact of break things down properly. And they will be simpler. You know, as, Brian Foote says, don't design a big ball of mud. That's not good for anyone, you know?
And then the second thing is around kind of programmers. I think programming is still important. It's still really important to be a good programmer. But I remember getting up in front of Liberty a few years ago and saying that the junior engineers were the best programmers in the company. I said the junior engineers were better programmers than the architects in my team.
And I got a huge laugh back from that specifically Jillian McCann was really angry. She was like, I am one of the best programmers in the company. And I was like, actually, yes, Jillian I think you're right. But it was illustrating the point. You know what I mean? You're also the best engineer in the company. So, you know, it's so there's something about having the experience or especially the cognitive burden to know what you don't need to do. Good engineers know what they don't need to do. And then that's the difference. You're almost simplifying, as you go, Rebecca:
So let's talk about some of those, some of the ways that you distill these lessons and then share them out with folks. I would definitely want to talk about the serverless edge and you've got a lot of things going on, right? You got like blog posts, you got some team members, you've got newsletters, events. Can you talk to us a bit more about what the serverless edge is and why you and Mark McCann started it?Dave:
Yeah. So it's a funny story actually. After I left Liberty, I'd been speaking to a bunch of people across the industry and it was actually, Adrian Cockcroft. He said, you need to write a book. I was like, no, I'm just going to take a few months off and then, you know start. He says no, no, no, you need to read a book. It's really important. So I says, okay, I'll see if I can write. And, I ended up putting together a book, which we're publishing with IT Revolution towards the end of this year. And really it's around the, and I've got the serverless edge is the blog that we discuss some of these kind of, some of these topics and really it's, there is a, the serverless edge gives you an advantage over many other technologies because it makes you go faster.
And really what I've tried to illustrate in the book is when you take business strategy illustrated by Wardley mapping and technology strategy illustrated by serverless first. And if you can combine them together, there's a flywheel effect that absolutely propels your company into a different stratosphere.
And you can see a few companies who have done this. I'm sure you guys have spoke to some companies who have really gotten that really tight. And once your engineers understand what the business strategy is and what it's not, through something at Wardley mapping. And once your business relays to how they can ask for things and how they can get technology moving forward, then it's, you know, the IT department is gone, you know, you're on steroids moving forward.
So it's really, so this idea of the value flywheel is something we've kind of created these trying to illustrate that is to kind of talk about how do you get that flywheel effect working within your company? So really within, within the book that's coming out, and IT Revolution has been awesome.
And I've been speaking with Gene Kim over the book and talking to some of those authors, which is great company to be in, you know, they publish like Accelerate and, you know, Team Typologies and a bunch of really fantastic books the DevOps Handbook.
So being in that company of authors has been great to kind of propel these ideas forward and their whole new kind of space. And then actually teasing out the ideas with my two coauthors Mark McCann and Mike O'Reilly has been really good. They actually, you know, flex this out and get some of these ideas into the community.Rebecca:
So you've mentioned a few times,I know that Jeremy promised at the beginning of this podcast that we'd get back to it. But I think it's probably time that we talk a little bit about Wardley and Wardley mapping as a tool to drive transformation and then the Wardley strategy cycle. And I really appreciated how you had brought the, the idea of the worldly strategy cycle, because I think when people do hear about Simon Wardley and they hear about Wardley mapping, but there's like another, a cyclical, like a loop involved in that too, right? The Wardley strategy cycle. So will you talk a little bit about those two things and then we'll, we'll come back to how they apply to more about the serverless edge. Dave:
Really, I mean we first started speaking to Simon and talking to him and joined some of those research groups over the years. But as we started to use Wardley mapping as a technique within Liberty mutual, it just became really powerful because, you know, we have a team in a very complex area. We would map out what they were doing and it would become immediately obvious the things they didn't need to do.
I used to get some reactions, like people going, why are we doing that? You could like bingo that worked. So people were automatically saying, why are we spending so much time doing this? We need to move that into product. So this idea of this mental model of how visible is the work you're doing to your stakeholder, is it right front center or is it broad a few layers down plus where in the evolutionary cycle is this, is this genesis, custom or it's brand new or is it product utility?
You should be just renting it from someone. So that was a really powerful way to have the discussion. And then as you get into the strategy cycle, you talk about doctrine. What are the core tenants or hygiene factors that are within the company? Know like common language, communication, you know, quality standards. There's a whole bunch of hygiene factors that we talk about that that should be within a company. Do you have alignment through mapping?
And then, you know, getting into things like landscape and orientation and how you're actually, you know, executing those things. So I think that's a fantastic model, but what I did was really apply some of those thinking into the book into that what I call the value flywheel.
So really we've got these four different kind of areas where it's like, purpose. Are you really aware of your purpose as an organization as a team?
Can you read, do you know the north star of what you're doing, and this was something done a million times. You talk to your team, they tell you about their amazing Kubernetes stack and say, well, why are you doing that?
So, boom, straight away during the business problem, then challenge. Can you map out what you're doing? Are you open enough to receive challenge from people?
You know, maybe we have all the tech, but we have the wrong team. You know, so there's a socio-technical thing there. Do you have the right structure? Are you challenging what you're doing on the next best action? Are you going to execute quickly on that serverless first developer experience? Like, can you get that in production tomorrow? It's going to take you six months. And then long term value, like sustainability well-architected. Are you putting well-architected standards into what you're doing?
So even though you've written some quickly, is it well architected. And tthen that drives you to push you on the purpose even more. So once you start that flywheel effect going, you make rapid progress. So thank Simon Wardley's work was brilliant for getting us in that mindset. But I know I've said this to Simon, but his language is it's very research-driven, it's hard to get your head around. He says it takes seven years to learn mapping and he's probably right. So what I really, what we really did in the book, myself, Mark and Mike was kind of take that and kinda make that slightly more accessible. And how can you apply that? Then you know, and really the tagline is okay, you've migrated to the cloud. Now what. Do you have a nice data center? Are you actually ready to fly? Will you take off?Jeremy:
Yeah. And it funny that you say that, because I actually had a question about this, where we've had a lot of guests talk about Wardley mapping, we've had Simon Wardley on this podcast, where we talked about Wardley mapping. But in seven years, like I'm still trying to learn Wardley mapping. So I think he's right on that.
But what I, when I think about all these guests we've had, including Simon who is brilliant and the whole abstract of it is brilliant. But the actual application of it and bringing it into an organization it's sort of like, you know, I always joke about this. You're reading a tutorial, you'll get to step four and then step five somehow skips over 700 steps. Like that's how I feel like bringing Wardley mapping into an organization. So how do companies do that? I mean, this book is obviously a great first step for them, but, beyond just the principles of Wardley mapping itself, applying those within the organization. Can you talk a little bit more about that?Dave:
Yeah. Well, I think the language is really important. Actually mapping itself is kinda dangerous if you're going map with a bunch of executives, it's you know, just be careful because
it's a tough technique. But there's two things we did was really interesting. We created a grid for Wardley mapping.
There's layers of visibility, say A, B, C, and D, where A is most visible. And then we had a number 1, 2, 3, 4, was it like, genesis, custom, product, utility. So we would, we would talk to a team and we would say, where are they? This team's like they're like seawall. It's product right in front of the stakeholder. That's where you want to be. This team that are, they're like D2.
They're like some custom built madness, that's four layers away to say you're too low in the stack. So we get a really simple way of teams realizing where they were, you know, and it's almost like that's where you are and which direction are you going in? You've written something really valuable. Are you trying to commoditize that? Are you trying to create innovation? And we also combined that with team topologies. Are you enabling all their teams? Are you creating value?
And once you put those two things together, it's like, well, you can't create value if you're a commodity that said no way, no one even knows you exist.
So it's really trying to get teams in the right head space to understand where they're at. So even that language, I think the language of Wardley mapping that was even more important.This concept of, you know, product versus commodity and custom is really important because a lot of teams, they write something custom and then they never like refactor it to bring it into product. That's like the pioneer settler time planner idea that Simon uses, you know, a team can be a pioneering team, but they never move over [inaudible]. So it's every team and product is on an evolutionary journey. So it's about talking to teams to where they are on that journey. So think having somebody sit and talk through the teams with that, and for me, that's a great role of technical leader or an architect is to command and, and provide that, kind of coaching to the team and then you can't just go in and say, you need to be X, you then say, well, I think we need to move to X and let me help you get there
And you maybe go and clear the way for them or introduce something. So it's about helping the team, see where they go next and then assist them in getting there themselves. So I think,
yeah, I think that was super important, but, this idea of a common language with the evolution of the team, I think is really importantRebecca:
It sounds like you might say about Wardley mapping, especially when you're in front of stakeholders, right? You're like, well, to distill it down, it's with great power comes great responsibility. So like don't just wield this tool, willy nilly, especially with folks who aren't necessarily like in the right head space to even consider its implications.
And then you certainly don't want to make rash decisions off of like, maybe something that you sketched out in 30 seconds. If the rest of the people in the room don't understand like the origins and how to use it. So I love that you're applying, you know, the Wardley strategy cycle and Wardley mapping to your book. And I, and so in that book, right, you talk about, what do you say? You broke it into four parts. You say purpose, challenge, I'm going to mess up on the third one and then, well architected. What's the third?Dave:
Yeah, next best action.Rebecca:
Next best action.Dave:
Bias for impact.Rebecca:
Thank you. And then, well architected. And so you have a podcast. The Serverless Craic podcast. In which you talk shop, let's say, with Mark McCann and Mike O'Reilly, and you have, like, I think you dedicate maybe six episodes, to the well-architected framework and sustainability is your favorite pillar.
So will you talk a little bit about the podcast and then why you dedicated so many episodes to well architected? And then maybe how that fits into your book itself?Dave:
Yeah, well, I mean, we're huge fans of well architected. It's just amazing. You know, the fact that it's eight years old, still blows my mind. It's such a neat idea. And, you know, Google, Microsoft also well-architected approaches that are slight different names, but the same stuff. And I just love well-architected because I use this entirely in every company.
It's like, I call it, it's like your five a day. I always say, we need to introduce well architected as a phrase, that everyone understands. That someone can ask, "is that well architected, yes or no?" When your doctor asks you, did you, did you eat your five a day? Either say, yes, because that's five for veg. No, I did not. Or you can say, yeah, but I kinda had fruit juice which isn't really five a day, but I'm going to count it as five a day.
If that's your attitude, then the doctor knows that you're not telling the truth. And I say, well, it's your responsibility. So, you know, you do what you need to do. Same with well architected.
It's a great way to level out because when you ask people about architecture, they talk in circles.
But well architected is quite clear without [inaudible]. I love the fact that they added sustainability, too as a sixth pillar. And again, I talked good friends with Adrian Cockcroft, who's the VP of Sustainability for AWS and the whole idea that the cloud provider are responsible for the sustainability of the cloud.
So they make sure the data center is running well. And it's your responsibility for sustainability in the cloud.
So there's something like 1% of the global electricity bill is on data centers and that's going to increase something like ten fold in the next decade. So most software engineers are not quite clear on how their designs specifically relate to increased carbon burn.
And the one thing that's happened as the cloud providers can measure carbon usage. And as regulations comes in around, you know, carbon requirements for, you know, 2035, whatever companies will have to start saying, this is our carbon burn. So there's a direct responsibility for engineers. We now have a number for technical debt.
It's not just someone's opinion. You know, you actually have a number even with the cost in the cloud. You can still hide that with Saving Plans.
So imagine a future where you can actually assess an architecture to see how sustainable that is? And you could look at that. So obviously of course, serverless is the best way to create a really sustainable product.
So, I think there's going to be a huge uplift in sustainability as the metric that matters for good architecture. I don't think we've ever had that before. So I'm excited about the changes that the cloud providers will bring out to help us measure on their changing mindset on engineering teams to actually, think about sustainability as something that is, as a measure for good architecture.Jeremy:
Yeah. I was excited to see the sustainability pillar added. cause that's, I think it's interesting to be focusing on and, you know, actually Paul Johnston and I were talking about this I think two years ago now, or whatever it was like, you know, just saying. how important it was, you know, sort of going green with serverless and that being a major driver for it.
So I just want to ask a little bit more about the podcast and, and the conversations you've been having. I'm just curious how the feedback has been because Rebecca and I love it when this podcast gets people asking questions or interacting with us or disagreeing with us, even, although I mean, it's hard to disagree with Rebecca and me, but still, if they do, so I'm just curious have you, have you engaged with some people have people reached out to you? You know, and sort of like, been inspired by this? Cause again, it's super interesting stuff and crazy important. Dave:
Yeah, the feedback's been really good. A lot of people really enjoy it. They like the kind of conversation. And what we're kinda trying to do is have nice kind of short conversations that are, you know, almost like bite-sized to try and make some of these things more accessible. We're trying to hold back in our inner desire to go really deep in some of these topics, we're trying to keep it at a nice high level.
And really it's a lot of people are listening, and say, you know, it's a nice short podcast. I can, it was really interesting what you said and encouraged me to go and learn more, you know, and it's really, we're trying to almost have. An open conversation between a few people. They're just getting to sit in there and they can have chats you would have at work, sitting on the coffee table about, you know, about well architect or whatever.
And it's not quite, we're not really any vendor specific. We're just kinda shooting the breeze and just having some fun with that. Like, so I think it's nice to kinda, almost like level out the conversation and talk about some of the cause at one thing I think about, and I often talk about modern cloud versus legacy cloud.
A lot of people don't understand what modern cloud means. So it's trying to maybe give some language, and this is what it kind of feels like for modern cloud, because I think there's a lot of companies who are stuck on legacy cloud, but didn't realize it..
So definitely a goal or call to action with some listeners to think, we need to do, we need to make some improvements, you know, we do start moving things forward.
So I think that's definitely a subtle goal, but the feedback's been awesome. And thanks for the thanks for the compliments. Really appreciate it. Rebecca:
If you, I know, I don't know how obvious it is, but Jeremy's into podcasts. So, he definitely, maybe I wouldn't be as surprised if he had like seven questions about the podcast and we had to just like cut them all from here. It's like, but this is an open invitation to disagree with us to challenge us.
I imagine Dave probably also give somewhat of an open invitation for that, but I'll let you speak for yourself. I'd rather listeners interact with us and say like, Hey, I don't know if I agree, or I haven't seen it work that way rather than just be like, oh, listen to that podcast and then like keep going.
So, yeah, it's congratulations. It's not an easy thing to stand up, especially to get three people around the digital coffee table, as often as you do. So it's really exciting. It's fun to listen to you. So you're talking about this idea from legacy cloud, you know, to modern cloud, and it reminded me of a quote that you're talking about.
Like the reasoning behind your book, titled TBD, but you say the need for cohesion between business and technology has never been greater and we need to simplify the technology narrative. And so it sounds like in a lot of ways, right? Serverless if you, when you do it right. And when you will architect it and when you have this, let's say guide rails of the questions that you ask to help other people understand, like, are you actually achieving the optimal goals behind what the serverless mindset, the serverless first idea, this paradigm is that simplifying, let's say the choices, you're making as engineering, and then ultimately that ends up hopefully improving, or it does end up improving the business. And so the business narrative, it's pretty simple. It's like, you know, ROI, like, what is the ROI? Are we like moving fast? Are we executing quickly is a feedback loop shorter? Are we making more money for the products that we're serving? Can you talk about what it means to simplify the technology narrative on the other side of that?Dave:
Let me, I think, there's definitely something around what you talk about as an engineering team. And if you're constantly in the weeds, explaining stuff, people can't really understand. I think you're missing something. Do you know? It almost needs to be a single language. You want your engineers talking about the same thing that your business leaders are talking about?
I think that's, for me, that's the goal. I find the challenging when the engineer team there's so deep and technical implementation as if almost forgotten why they're building what they're building. And I think one of the things I think is nice about serverless is some of the questions or the challenges or things about, you know, response time versus observability, you know, developer experience, they're higher level things that you can actually talk about.
They're not in some weird kind of technology framework that no one, they're not talking a different language, then you're kinda business leaders. It's like, we want to be more responsive. We want to be faster. We want it more reliable. We want to be cheaper. You can actually lift the level up that much of the conversation because you know, you're not having to write thousands of lines of code and do really complicated things because the cloud provider does most of that for you.
So it takes the focus away. And I think, we have a conversation. It almost leaves space for innovation because it takes care of a lot of the low level stuff and, and gives you space to think about what, what can you do for your business leads? I had a great example, a few years ago of a team who were brand new to serverless and they had to write an application and it took them four months to do it One of the colleague of mine was kind of late and he says, right, we're going to do this serverless first.
And like, we, we don't want to do that because we don't know it. So we had a conversations. Okay. We'll learn it and we'll try it. And of course they used to CDK patterns and they had the application written in like three months, which was like, you know, I think they had six months to write it.
But when I said, well, are you going to deploy now? And they were like, oh, we don't have to. Just deploy it. Let's see what happens. Get through all security stuff. And then just start seeing what else you can do. So they start doing observability dashboards, start reducing costs, they do a couple of architect reviews.
They just, you know, really optimize the thing. So at the time it did a bit of yak work on it, by the time the customer needed it, which is for a very specific date. They had the thing written, they had it tuned, optimized, they were good to go.
You know, and it was probably one of the most, best applications they've ever written.
So the fact that they can get the product stood up very quickly and then have extra time to, you know, not, not harden it, but improve. To do some of the things that you never ever get to. If you're having to write thousand thousand lines of Java code and worry about ec2s and et cetera.Jeremy:
That is Amazing. Well, speaking of long podcasts, we are out of time, but it was awesome talking to you, Dave. So if people want to find out more. about you, or they want to find out about the podcast or the serverless edge or your new book, how do they do that?Dave:
So we're writing on the serverlessedge.com and that's where most of our, that's where all our content is. For the book we're writing, The Flywheel Effect, for the book, but that will be published on, IT Revolution, will be listed on, I think it's already listed in Amazon under the Flywheel Effect. That's available for pre-order now. And, we also have, Serverless Edge, Twitter handle where we tweet some of our material as well and all the usual channels like YouTube and LinkedIn, et cetera. But I think primarily, the serverlessedge.com and, the book the Flywheel effect it's listed in Amazon.Rebecca:
I didn't realize it was already titled. And man, I was going to be like, are you accepting applications? Like we could have a little contest around like name Dave's book. But great choice of name.Dave:
Yeah, the Flywheel Effect. This kinda, we, were thinking about it for a while and put it really resonates with that flywheel effect between kind of business strategy and technical strategy. So there's really something there that once you get those two working in unison, you get that kind of rocket ship effect.
Like, so it's, it's pretty exciting. I hope it's, I hope it hits the mark, it's exciting times.Jeremy:
Yeah, That's awesome. Congratulations on that. Alright. Well, we will put all that stuff in the show notes. Thanks again, Dave.Dave:
Thanks very much. Thanks very much for the time. Really appreciate it. And great to catch-up.Rebecca:
It's our pleasure.