Amsterdam 2023
Accelerating Towards Serverless-First with the Value Flywheel Effect
Many organizations have migrated to the cloud, but the modernization journey is the next challenge. Orgs must combine business goals with technology goals to maximise time to value and accelerate with the cloud. The value flywheel effect has just been published by IT Revolution which is a playbook on how to make that journey.
https://itrevolution.com/product/the-value-flywheel-effect/
Using experience from case studies in the book such as Liberty Mutual, BBC, A Cloud Guru and more, Dave will discuss the four phases of the Value Flywheel (finding Clarity of Purpose, creating a safe environment for challenge, Serverless First & Next Best Action and Long Term Value with the Well-Architected Framework) and how customers can use the Wardley Mapping technique to create an effective modern cloud strategy.
There will also be some real life stories around serverless myths and pragmatic ways to ease the modernization journey.
DA
David Anderson
Author, The Value Flywheel Effect
Transcript
Hi folks. Um, my name's Dave Anderson, and today I wanna talk to you about accelerating towards serverless first with the value flywheel effect. Um, thanks for, uh, coming to talk. I really appreciate it. Um, I'm an architect, a GP globalization partner, so, um, I'm actually a practicing architect, so I, I practice what I preach. Um, so really service first, it's, I wanna kinda preempt by saying there's a lot of interest around cloud migration, but for me, the big incoming wave of disruption is actually modernization. And that's the thing that I see on the horizon for many organizations'. Like we've, we've moved to the cloud, we've, you know, we've, we've got the Cloud sox, we've done all that. How I modernize my stack now that we're actually off-prem. And for me the, the answer is the serverless mindset. And I'll, I'll get into that as we go.
Um, what's my experience in this? I worked with Liberty Mutual for many years, and when I was a, a director of technology there, like a C T O role. We started the journey in 2013 and I was looking enough to be at the table and we started speaking with a w s about kind of, um, moving a lot of our workloads. There's a couple of really fundamental principles that we put in place that we used a w Ss as a partner. So it's not just a cloud vendor, a partner. Uh, we had this idea of serverless first code is liability. And part of my team, we, we kinda drove this message and how can we get our engineers to write less code, I think more with the capability and get that as cheaply and as efficient as we can build. Well, how do we build in really good building sort of, uh, quality controls and how do we give teams the autonomy to move fast?
And I call this the second transformation, the modernization piece. And I wrote some of this up as a case study, um, before I moved on from Liberty, and I captured a lot of these, these kind of thinking. I kinda had a model that I used called the value flywheel and really had this kind of, this idea of how do we join business technology. I, I'd spoke to the presence of the business who were saying like, I, I don't want to hear the word lambda or a s I don't care about any of that. Just how can we go fast and go safely at a decent cost? That was it. So we come with this idea of how do we have a nice kinda flywheel effect, the how, how we join these things together. It's just kinda talking through these. Um, the first is that idea of wardly mapping.
In my team, what we did with myself architects, we used wardly mapping as a way to create perspective. How could we assess and make sense of the landscape? Then we just idea of clarity of purpose. A lot of teams were building, but they didn't know why. Um, you know, leaders would say, we, we need to have certain KPIs working on north stars. And the teams are completely unaware that, so how do we create a common clarity of purpose, the idea of challenge. How do you create an environment within the teams that people are happy to say, where are we building this? Is this really the metric that matters? Is there's a better way to do this? How to create that environment of kinda challenge serverless first, once you get that idea of clarity of where you're going, how can we make developers build really quickly and at quality study the service first kinda strategy, and then finding long-term value?
How do we ensure we're not just making quick, quick builds that we can build things and throw away, we want sustainable, sustainable practice. So this is a kinda coin is the value flywheel effect. We've captured this in the book, the, the value flywheel effect that just came out there on it revolution, uh, about just before Christmas I wrote off my two co-authors, mark McCann and Michael Riley, and the three of us are now, um, architects at GP kinda practicing that, that that same um, um, model. And it's really about, the book is really about how do you accelerate your organization towards the modern cloud. And I want today I want to kinda share some, some key learnings about those kind of five phases and, and, and give you some takeaways. But first I want to kinda hit something that's been sort of popular. The, the recent Twitter storm of serverless first, or in kinda prime video, it seems like every six weeks there's a Twitter storm where someone is kind of declaring a technology's dead or technology's alive.
And the thing about serverless first, it's not serverless only people think it's lambda or nothing. I'd be the first to say that if your technology strategy is used Lambda, then you're not doing it right. You are not doing it right. And I mean, it's like, I thought this is funny, only AIF deals in absolutes. Like ask any architect over the past couple of decades should I use technology X? The answer is always, it depends, where do we lose that kind of that perspective. It depends what problem you're solving. If you're running, um, on demand video with millions of subscribers, Lambda is not probably a good option. And that was a very well written article by kind of, um, the, the prime video team. If you really want to hear about this, that serverless first kind of, um, assessment of that article, I would go and read Adrian Cock Croft's article on Medium where he breaks it down.
What serverless first is, is using the cloud provider managed services to build quickly at quality. And then you're in a, in that evolutionary architecture state where you can make choices as you move forward. There's a nice thing about don't, don't build yourself a one-way door. Always make technology choices that you can pivot away from. That idea of evolution is really important. Um, it it, it, it kinda challenges me when, when architects say, this is the only way we'll do it and we're gonna bake ourselves into the corner, and that's us. That that's not a responsible way to behave, I think for your business. So I would think of that serverless versus as being a starting point, not the only place you need to get to. So want to hit on each of these kind of five areas. First, I'll hit on worldly mapping. And really for me the question is how did a couple of engineers sitting in Belfast kind of influence a Fortune 100 company?
And the answer was wardly mapping. We were able to sit and assess the landscape and decide what were the best moves to make. Like with any transformation or big technology drive, there's like a hundred things that you could do. What's the thing that you should do to really make a difference? And, um, if you haven't heard of wordly mapping, I would definitely look it up. There's, there's a bunch of stuff in the book about it, but I want to kinda give an illustration. So what's the role of the architect in this, this, and this is a really scrappy map that myself and a few of the team drew probably maybe eight years ago, we're trying to assess the landscape maps are ugly, they're not correct, they're just something that you kinda threw up. It helps a team align on a way of thinking. For me, what the architect often did here was facilitate.
The architect would maybe say, well, what happens if this technology evolves? Or what happens if there is an inertia point here where we can't evolve that? Ask leading questions and find out what's the really important thing to do Your spot week areas we have, we have a, a key area of our business is in custom build, held to go sticky tip. Let's, let's address that. Let's focus on the right areas and align on the right thing to do. And I think a nice thing about mapping, which is often kinda hidden, it's alignment and collective, you're deciding what's the best effort to go forward. A really nice way to illustrate this is this map here, and this kinda sits very well with, um, Patrick's talk this morning about chat. G P T I was trying to think what's the best way, and I'll, I'll, I'll kind talk through this.
The way you read a wardly map is you usually kinda start at the bottom and work your way up. And if you haven't seen this, this technique, it's by Simon Wardley, the researcher. The visibility is on the Y Xs here, where things at the top are more visible, things at the bottom are less visible. And there's an evolutionary axis from left to right where we've got Genesis, something brand new, never been seen before, custom, we kinda know how to build it, but we're not quite sure product. This thing is now in demand and commodity. It's just this thing exists. And, and that's that chat. G p t kind of exploded on, on social media around the start of February. And I'm like, like many of us, I'm pro, I'm probably the same. You're on the edge of ai, you kinda, you deal with it, you understand that, but you're, you're not a specialist.
So chat g p t exploded and about six weeks later, this guy Mark, ick, ick, put this map out on Twitter and within a minute I was able to say, right, I can see through the chat G p t kind of Twitter storm and I can see what's important. And I'll just quickly annotate this map, the bottom right here, you've got things that are invisible and commoditized open AI, LLMs, A P I and cloud. And there's, there's a value chain that ends the tools. This tells me that the tool sets are mostly commoditized. These things have been within people like, you know, Facebook, Google for many years. We are now just accessing it. So building a better tool for Jett b t is not a good avenue to go down. There's a more interesting value chain up the middle, which is a good vector db, tech splitter, uh, embedding vector, prompt templates, qa, prompt techniques, right?
Prompt engineer, what is that? That's interesting. I can now see that the focus that I need as a sort of consumer of Jet G P T think of it, what's the prompt techniques and then what is this, this prompt engineering field is start to come about within a minute of seeing this on Twitter as you able to kinda see through all the activity around chat G P T and think, right, that's where I need to focus. So that's the, the bit that's evolving. Even some of these pipelines around embedding Vector, db, pine cone, I mean these are things that will evolve like someone else will look after that I can focus my time, be high up the value chain and really leverage chat G P T. That's the power of something like worldly mapping. You can sense Mick, these very complex technical areas. And I, I would follow Mark on Twitter.
He's got a bunch of really brilliant maps and a lot of really great, uh, kinda prototypes. But for me that's the power of mapping. You can straightaway see the sense of a very complicated kind of environment. So the next kind of phase is that Claudia purpose. And one of the things that I did quite a lot, and Mark McCann, one of the co-authors does this quite a lot, is use this North Star framework from Amplitude to try and ask teams what is their north star? What is the metric that matters? So you would say like, what's your, what's the north star metric for this team? Say number of deploys say, well that that's good, but it's not the north star of us as an organization. You'll figure out something if you're Spotify could be minutes of music listened to. So there's a north star metric, there's mid to long-term impacts where we'll let get us to, and there's input metrics which could be breadth frequency, and then there's the work to try and drive this.
It's a little like kinda impact mapping. And what you're starting to do there is find out who are the users, what are the needs, what's the scope? You're starting to ask questions about the work that we're doing and you're getting a good picture and this is a great way of distilling down a piece of work and having something nice and clear. And you're probably thinking, should the product manager do that? That's not my job as an engineer. And again, that's the wrong kind of, that's the wrong idea. We are the business. You wanna be sitting down this as a team, product, engineering, legal, whoever else. Let's figure out what we're all working towards and agree on a north star metric. And it's not to say the other metrics aren't important. I mean you still wanna think about your uptime, you know, time to market, et cetera.
But as engineers we often obsess over the things on the right, the outweigh the thing on the left, which is the business goal. And I mean for most of our kind of leaders, the stuff on the right is table stakes. It's the stuff on the left is the thing that we really wanna talk about. So it's just about finding that balance. And again, a brilliant example of this I thought was this is a sketch from, um, from Simon, guru Simon Wardley. He met the cloud guru team at, uh, the, the cloud training, um, company that's been acquired by RealSoft. He met them on an event in 2017 and they were doing a lot of serverless events and they said, Simon, this mapping thing seems interesting. And he says, can you do one? And literally in the green room at a conference like this, he scribbled out this map and basically mapped out their entire company strategy and they realized that they were focusing too much on the community, on conferences and other things, and they needed to focus on their learners and engineer.
So they effectively pivoted their model and just created focus. And I've spoke to a few of the leaders in Cloud Guru and they were since acquired for think $2 billion and help them just focus just a simple basically napkin sketch just to say, you know, there are some things evolving, but you need to focus on your user need, which is your developer who's looking to learn. So something like that. And there's a proper case study in the book about, about how they, how they did that. The next one is like kinda challenge. And I think this is really important. I mean, remote work has completely and changed the environment as we work. The idea that you can come into the office, like a team is a bunch of people who sit in that bay that's been blown apart by remote working. So it's really a very different kind of environment.
The things that bind us together in the physical location may not exist in the remote location. So we need to think differently about what that looks like. And I always think the system is more than the code. There's that social technical aspect. There's, you know, how do your engineers work within each other? How do you work with other teams? Do they understand where they are in the, in the technology systems as well as the organizational system? There's a whole bunch of things there that maybe were implicit when you're physical, but they're not quite explicit when you're kinda remote. And this is really very straightforward. I would, if you haven't already, I would certainly look at team topologies as a way of thinking about teams and technology. I was joking with with, with uh, a friend a few, a few, um, weeks ago saying that whims team topologies published, it was like four years ago or five years ago.
It's been such a new idea. So don't assume everyone understands what this is. You know, it would take the time they explain team topologies in these systems to other peers in your organization because getting that, getting that right is absolutely priceless. And that creates that nice environment where you have enabling constraints where you're thinking about what are the things that are absolutely must dos If you've got a team, a p i, it must be correct, maybe there's certain ways that teams go to production, maybe there's a build it, own it, run it, whatever those constraints are to keep your teams operating. I dunno how many teams that I would talk to and they'd say, yeah, we're a stream team and we're building a platform and we're helping other teams. And you're like, okay. So I think that idea of putting, enabling constraints in your organization, we'll help your teams move quickly.
A brand example is from a, a startup called Work grid where the C T O Jillian McCann had probably the best end constraint. Um, and really that I idea of inviting challenge into the organization as a C T O, our technical strategy is really simple. If you get an idea, let's talk it out as a team. So any idea is value, but we all know what our enabling constraints are from a a technology perspective. Let's just evolve quickly, no big process, just let's, let's fire that up. It's the best way to introduce that challenge to give people that ownership and empowerment. So from a service first perspective, that next best action. I think for me, this is really the, this is such an important concept and I've seen, there was a, a nice slide in the previous talk about that shared responsibility model, a s of this shared responsibility model.
We talk about the, the cloud and you often see companies that migrate will move to the A SS infrastructure. They maybe have separate availability zones for kinda dr they might have edge locations for, for enhanced performance. Like that's a really powerful move and there's loads of value in that move, but I would describe that as your basic cloud migration. But now you're treating a w s as a data center. Now in fairness, you probably just have a really nice data center run by some really professional people, but you still effectively have a, a data center elsewhere to really leverage the power of the modern cloud. You need to lift that value line. What, what can your cloud provider do around kind of compute storage, database encryption, platform management? I mean really, and this is like, this is the same. It's not just for wss, it's also for Google Azure. However, um, can your cloud provider be your platform team? And then you focus on what do you wanna build on top of that? I think helping teams move up that can align, I think is really powerful. They really move at speed.
And one of the things about serverless first is that, that it's not understood too much is it's effectively an operational construct. Like oftentimes when you say the word serverless people just think of Lambda. There's a nice kinda spectrum here on the left. You've got more operations, things like, uh, for compute, you've got a virtual machine, you've got my ssq, l OnPrem storage, OnPrem, E B s, um, Hadoop on-prem, on the right. You've got on-prem systems, lots of operational overhead that you that that you own and run on the right here. Just things that are completely abstracted, way behind a service like lambda, dynamo db ss three step functions, even event bridge. These are things that basically they're an a p I call away. So what I would often say to teams is start on the right. Don't think you need to start on the left and slowly evolve to the right start on the right. And if, if something happens, like if you're using Lambda and the computer there, there's any, it's not fast enough or your three putts quite high fall back at the Fargate or manage containers, it's okay to fall back but start on the right. You see people installing massive kind of very complex solutions and they kinda locked into high operational, high operational overhead. So I mean, you've gotta think of service first as an operational construct and not just as a, as a single service.
And really what's one, I was asked the question a few months ago and really since the books came out, I've been speaking to lots of different companies and leaders about some of these concepts and one of the things I keep getting asked about, what's the impact if we go serverless first, what's the impact on our teams and engineers? What are the things that are now different that traditionally aware? So I get this kind of list of there, there's definitely something around your engineers need to be really close to cloud principles, not just the ability to deploy something to the cloud. They really need to understand what are the true kinda cloud native principles. And even in leadership, your leaders also need to understand those as well. Um, I think system designers, event driven architecture, that becomes really important that people can think in systems and not just in low level components.
Um, there's also a commercial piece of it. We talked about finops. You'd be really aware of cost and value. You build cost, run cost and value delivered. They are now empowerment and engineers understand what those are. I think there is, there's something around, uh, learning teaming and inter teaming those interpersonal skills of your engineers, you that growth mindset. And I would say, I mean, not that they Farley, I know it's not a IT revolution book, but the modern software engineers are brilliant book to describe some of these concepts. And Dave Far, he's been doing brilliant work and, and and describing what this, what this new norm looks like. There's a bunch of really solid principles like, you know, build it, run it, own it, rapid feedback loops, a lot of things we've been talking about in the, in the DevOps kinda movement. So really they kinda illustrate that surprise, surprise.
I put together a kinda quick map. And really what I'm thinking about it is if you're a, a VP of engineer, like a, a, a technology leader, probably your main need is of a high performing team. That's the thing that you want in your organization. Now, the first probably, um, dependency there is technical skills. You want good technical skills. They often, people will stop here if I hire a really bunch of really smart technical people, a high performing team, but there's more to it than that technical skills. You might have cloud expertise or system designer. Um, and that's the first thing you often interview for the first thing you'll test in a team, I would say the next dependency is interpersonal. You want people who can work well within the team and also interface well with other teams. I always think it's a really bad sign if a team is fighting with another team that shows a lack of maturity in engineers.
You want a growth mindset that people aren't afraid to tackle new technologies, new problems after interpersonal, you've got commercial thinking. You want people being value aligned to, to what we're trying to do as an organization. You want people to be aware of the run cost, the build cost. You do want people refactoring something to save 10 bucks when it's costing like 10 grand to do the refactoring. And really there's something about empirical evidence. You don't want people doing work based on gut feel or I think this will be good. You, you want to be data driven. And then from commercial thinking, you've got modern software engineering. This is things like build uh, run it evolution architectures. And for me, the the two things that I'd be looking to evolve to the right, I think modern software engineering, I'd be looking to make sure the teams understand those modern software engineering principles and also that idea of commercial thinking that don't understand the value, you can evolve those two bottom dependencies across and the the tech skills you've got. So for me that's, that's a nice kind of, um, map of how you could potentially map out some of your engineering skills in your organization and make sure you're moving the right ones.
Again, a map like that helps me and my peers talk about where do we need to focus on as we, as we grow the organization. Again, this, I thought this was a really nice, um, talk by, uh, Werner Vogels, the CT O of Amazon at reinvent. Last year you did piece on event driven and the word being event driven. It's couple of nice videos. And for me, when you get to this idea of modern cloud, this modern shop engineering, everything becomes event driven. That that's, that's the path we go down. It's more async than synchronous. And um, so what does that mean for the role of an architect or technology leader? What I, like I say, I'm a, I'm a practice architect in GP and globalization partners. What I found is the architects are more of an enablement function. The architects, they're not sitting in team, you know, drawing new ML diagrams or trying to, you know, code things for the team.
What you're really doing is you're facilitating thinking and making sure the teams are moving on. We see lots of event storming that we're sitting down trying to figure out what, what does this landscape look like? Let's try and explore and, and find the things that we don't know. And Alberto Brando's got some great stuff on how you do event storming. I mean, if you're old you realize it's just fancy B P m, but we'll call it event storming for now. But it's a brilliant facilitated collaborative technique. The North Star exercise is something we will actually sit and do with groups of people with cross-functional teams. What are we trying to achieve? Let's map this out usually on mirror or something. And let's figure out what the, what is the metrics that matter? When you start to get into some of the e D a, the event driven concepts, uh, you use something like event bridge as your, uh, back, uh, event backbone.
You start to get into the, the principles of eventing design, bonded context domains, a lot of domain driven design, a lot of principles around building a large, uh, distributed system that's, that's built to scale. And then finally, example mapping. You wanna use behaviors driven development and example mapping to make sure the teams understand what are the right behaviors they're trying to build. So again, that's a very different picture of an architect maybe 10 to 15 years ago with what you're doing. The, the technical complexity still there, but you're trying to offload some or, or help the teams get through that themselves and, and help 'em think bigger.
So for me, what you're trying to do really there in, in this service first organization is ensure the engineers have high agency with low buyers. The system you're building the platform has got low buyers who can move fast, but the teams are empowered to move quickly so that you're trying to remove any kinda gates and any kinda friction. Okay, so for the last kinda phase, this idea of long-term value, what I would call a, a problem prevention mindset. How can we remove problems before they happen? The hero engineer who just went in and, and sat on support all weekend and fix something, that's brilliant, but the question is, well, how could we have stopped that before brought down production all weekend? So there's two areas here that, that I wanna talk about. SCORP and Engineering excellence and SCORP is a, an acronym we use for well Architected, which I'll, I'll, I'll I'll cover in a second.
And any of engineering excellence, but what can it combines? The two of these is this concept, uh, the four Disciplines of execution or four dx. This is a model by I think, um, um, Steve Coy came out a few years ago. It's about a way to help teams empower themselves to create their own kind of, um, directions. Almost like empowerment. And I, I found this to be a brilliant model. There's four stages. First discipline of focus. Work with the team to make sure they have widely important goals. You send the team, what do you, what do you need to fix what's important for you? Second, the discipline of leverage. Work on lead measures, not lag, lag measures. Try and help the team identify lead measures, which is very consistent with the North Star framework. What, what are the lead measures we need to focus on here?
Third, the discipline of engagement. Use a compelling scoreboard or scorecard. That's really just a way for the team to visualize something. Um, when we first started doing this, we had very fancy scorecards or scoreboards, but we've really simplified it now. It's effectively a confidence page with a bunch of tables. It's as simple as you can get. It's the simple, the scoreboard the better because that empowers people to change it. That's not, that's not a bunch of fancy graphs or nothing. And the fourth is the discipline of accountability. There's a cadence of accountability. What we often do with some of these things is at the end of every sprint, every two weeks or every four weeks, we'll check in and review these, these, these stats. The important thing with these metrics is we always focus on the trend. We don't compare teams. There's no such thing as one team being better than another team.
You look at a team and look at their trend over the past couple of months and see if they're trending in the right direction. It's quite straightforward. So first of all, for corp and wall architected, um, we use the a w s wall architected framework, which has got six pillars. Um, you see them, their operational excellence, uh, security, reliability, performance, cost and sustainability. Um, each of these pillars usually has about 12 questions. And each question is a bunch of best practices. So what we'll try and do is we'll maybe focus on some thicker reliability and we'll dive into the, the, what the team are doing around what's their, uh, best practices around DR about resiliency, about maybe chaos testing, things like that. We'll look at outages, recovery times, things like that. So this is a, a framework that we can define. What do we mean by good architecture?
Um, in the past I've heard people say, well, you know, architecture to me is no, architecture is a thing. We very strictly have defined it. These six things, what we mean by good architecture. So what we kind of ask the teams to do for the scope process, and again, um, the single dashboard contains a whole bunch of tables, which at the top will have business metrics, which are things sort specific to that value stream. And then the SCORP is actually the acronym for the, the five key pillars. Now we haven't, not added in sustainability yet, we're kinda getting there, but it's really about security. What are the threats and mitigations, what about the threat models? What have we seen? What are vulnerabilities are open, let's kinda just track some numbers. Month to month cost. What's the cost per component per cloud service? What are your big costs?
What have you improved operational excellence. Usually that's the door metrics, you know, deploy frequency change, um, M T T R, et cetera. Reliability, what incidents have happened and what was the recovery like and their performance. Are we seeing errors, maybe ingestion, stats, processing times. And then finally, if we do a deep dive on a well protected review, are there any big findings we've found? So having that in a simple wiki page where we just ask the team to drive that, well we, we wanna focus on performance because that's where we think we need to. Okay, just let the team drive it. Um, and I always think of Scorp as being, it's been like kinda, once you educate the teams and what this is, it's bit like eating fresh fruit and vege like your five a day. It's just, you know what works, you know what I mean?
You know what's good and what's not good. You let the team work decide and kinda drive the conversation. The second thing that I've got there is engineering excellence. Again, we find a thing where people would say, well what's good software engineering? You know, it, it depends. One of the things that I was able to do, and again it's covered in the book, is take down pink's, uh, drive about motivation and this idea of mastery, autonomy and sense of purpose. And can it tweak that slightly? Well, mastery is technical mastery. How good are the skills within the team autonomy or the team like functioning well that they can move quickly with, with with, with minimal friction and customer obsession. Are they very clear on what those north star things are? And usually for uh, uh, a team that are kinda high performing, they'll be focused on customer obsession 'cause they've got the other two kinda nailed.
A brand new team might have to start with technical mastery. Maybe they need to lift their cloud skills. Maybe there's some serverless kinda learning they to do need to kinda kinda get to that. This kind of our shows that kinda evolution through this. And ideally, or usually you'll have many teams on very different stages. But this is what I would use for our concept of engineer excellence. And again, we do a similar thing with engineer excellence that we, we, we dashboard some of these things and we, we celebrate the improvements that the team have made using this four d x. So for long-term value, you have an organization-wide kind of, um, definitions of big good architecture. We mean scorp and that's that, that's what that is. And by engineer and excellence, we have a very specific idea of of what these things are. A nice example, one of the, um, examples in the case studies in the book is this idea at B B C, uh, one of the things that people often say, well, you know, serverless is fine, but it doesn't run a scale.
Um, there's a brilliant case study in the book around the, the B b C news team have completely deployed that, that solution using service technology and they have some absolute eye watering requests, like 2.3 billion requests served in the month, 3.3 billion service functions invoked. Um, you know, they've like, yeah, <laugh> 171 releases during the month. I mean these are some fantastic and anybody who is is familiar with B B C when there's a spike in news that think is absolutely hammered. And the the team have said that the the performance is way beyond anything they've ever had before. So, you know, some of these techniques, they do work, but you need need to kinda put these things together. So kinda getting a summary, I've kinda tried to put these five practices around that idea of creating atomic habit habit around worldly mapping. Kinda learn the, the shape of worldly mapping and how you can use that within your team to kinda sense make, um, be very clear that star and try and use that technique of something similar.
They, they align those business and technology kind of goals. Um, look at the social technical picture. I've got much more than that. Like, but really I would start with team topologies. Don't be afraid to explain team typologies to your peers. Don't assume that it's it's understood. Um, lean in the serverless first as a concept, as a mindset. It's not about blindly using lambda. There's a whole different approach there that, that I would call the modern cloud and then create a heartbeat within your organization or an engineering quality, either engineering excellence and, and, and a good architecture practice. People often, and that's kind of the, some of the key messages that, that have got in the, this, this working model of the value flywheel. A negative of the flywheel is that once this starts to turn, you can keep that turning. It's not something through. Once you continue through this kinda cycle of improvement, people often say is serverless must be easier.
There's less things you have to do, it's higher up the value chain. There may be less things you need to do from a technology perspective or you know, fine tune, uh, host, uh, virtual machines, et cetera. But there's a wider scope of responsibility. So I would say it's not easier, but it's better with Gillian McCann, the seed of worker that has been famously saying this for years. It's not easier, but it's better when you create the high performance team. You give them ownership, empowerment and responsibility, but you also need to give them a platform where they can move very fast and at, at, at, at, at speed and quality. Um, so that's pretty much me there. The book is been out since uh, uh, Christmas. Um, we have a blog there called the Serverless Age where myself and two co-authors, um, we create some content.
We also have a, a podcast serverless crack, which we kinda is bit lighthearted and, um, give us a follow on the, the help I would need from, from this event is as we move on modern cloud and serverless. First I'm really interested to hear about that kinda modernization journey. Where are you at in that modernization journey? What are the kind of, I would say the, um, the obstacles? What are the inertia points that you're starting to deal with? I think there's a broader discussion to be had, um, around how as a community we overcome these. I think the DevOps mindset and approach is absolutely perfect for where we're going, but there's another, we're we're starting to move up the value chain and I think there's some different techniques we need to apply. So I'm really interested to hear what are your opportunities, challenge, and, and learnings from, from that modernization journey. Thank you.