Liberty Mutual’s journey into a Serverless First World

Mik Kersten from Project To Product talks serverless first with Dave covering:

• Liberty Mutual’s journey into a serverless first world
• A customer over cost-centric approach to cloud
• Removing “undifferentiated heavy lifting” from the work environment
• Creating “two-way door” architecture for flexibility and flow
• Using “lego blocks” to help engineers build innovative solutions on the cloud
• Shifting away from traditional IT to partner-enabling technology

Mik Kersten:
Hello, and welcome to the Mik + One podcast, where I sit down with industry leaders to discuss the Project to Product movement. I’m Mik Kersten, founder and CEO of Tasktop, and best-selling author of Project to Product, How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework®.

Mik:
Today, I’m very happy to be joined by David Anderson, Director of Technology at Liberty IT. David is a lifelong programmer that I’ve had the privilege of crossing paths with on occasion. I’ve admired how David connects his deep technical knowledge to business value, so when I heard the progress that David was making on deploying the cutting edge of serverless computing at Liberty Mutual, I realized I had to share his unique approach with our community. With that, let’s get started.

Adrian Cockroft’s cloud philosophy

Mik:
Welcome everyone. I’m here with David Anderson.

David was introduced to me by Adrian Cockcroft shortly after we were debriefing on that pretty amazing podcast that Adrian I did a couple of months ago. What really fascinated me, if we reflect back briefly on the way that Adrian looks at cloud for CEO’s, cloud for executives, and really making the case, is it’s not about reducing costs. It’s not about infrastructure. It’s really about optimizing and just dramatically shortening your feedback loop through flow, so really reducing flow time, where the time to value is the number one metric that people should be looking at. And as we were talking about this, Adrian introduced me to the work that David has been doing at Liberty Mutual, and it’s absolutely fascinating because I think we’ve got an example here of exactly the right direction architecture to enable this kind of fast feedback loop, with what Adrian called, to applying the theory of constraints to your OODA loop.

Mik:
I’ve invited David here. David, I’d like you to introduce yourself in a second, and I really want you to listen for what you’re going to hear as a both executive and technology message on how to actually move into the future of cloud and how to, most importantly, apply that to innovation to your business. So, David welcome.

David Anderson:
Thank you, Mik. Great to be here.

Mik:
Before we get into some of the deeper concepts, tell us just a little bit about how Liberty’s technology is structured, how your organization fits into the overall company. And then I’d really like us to begin to really understand how you so quickly got to this place of innovation and architecture that I think so many organizations are striving for. Tell us a bit about Liberty IT.

David:
Well, Liberty Mutual is a Fortune 100 insurance company. I think we’re the fourth or fifth largest P&C insurance company in the world, and over a hundred years old. Liberty IT – we’re approximately a 600 person organization based in Belfast and Dublin. And we’re almost like an internal software house for Liberty Mutual. There’s the broader technology organization, which we are part of, but our remit within Liberty IT is really to progress technology and engineering within the Liberty Mutual enterprise. We work with all parts of Liberty Mutual. I’ve been at Liberty around 12 years.

Mik: Okay, great. And just to cut quickly to the chase here, what you’ve done within your organization is actually much more forward-looking in terms of cloud architecture than I’m used to seeing, Now, from a technology point of view, it makes sense. I think this is the future of how we’re going to do cloud computing, but tell us a little bit about what’s happened because when a lot of organizations, a lot of executives are just trying to wrap their heads around Kubernetes and containers where you’ve ended up is actually somewhere quite different and what I actually believe as a significantly ahead of that. Tell us a bit about your journey and where you’ve ended up in terms of your thinking around serverless.

The start of the Serverless First journey

David:
Yeah, absolutely. I mean, I like to say it’s our journey towards serverless first. I think it was around six or seven or maybe even 10 years ago, our CIO James McGlennon, he kicked off three big initiatives:

• our move to public cloud
• becoming more customer centric, and
• our agile transformation

And we did those three things roughly at the same time. And that set us off on a really good trajectory. And then as we started the move towards public cloud, we put in some really solid cloud native principles, and that really helped define how we worked with our finance, security, all our different parts of the organization. What does a really good cloud stance look like for a large enterprise? And we figured it out six years ago. And so we started that infrastructure move, while doing that agile transformation and becoming extremely customer centric in how we think. Back around that time, myself and my team were huge fans of Wardley mapping.

David:
And we started to read the content as Simon was working on it. We were kind of following along with him right back in the early days, maybe 2014 or so. And we started thinking, okay, when we reach the cloud, when we are transformed, and when we are customer centric, what next? We started to map out, and say, how do we become innovative, how do we bring in speed, fast feedback, how do we make sure we focus on the value and how do we become a learning organization. We don’t want to stand still. We started to Wardley map out this kind of landscape of the cloud, and it landed on serverless. We thought that’s the perfect direction for us to start thinking about.

David:
While the bigger organization is doing that kind of cloud infrastructure move, we need to look at the application architecture move, which is the layer on top of it, so how are we going to behave when we’re in this cloud native world? And that led us towards the serverless first strategy that we’re talking about today. Back then, we didn’t really know what it was called. I think Lambda had just come out. We were experimenting with Lambda. Lambda and S3 were kind of interesting, but this whole serverless first movement hadn’t really happened yet. We were quite lucky that we could really see forward. And I’ll thank Simon Wardley and his mapping technique, for giving us the vision to see far forward.

The Serverless First journey catalyst – Wardley Mapping

Mik: Okay. I want to unpack that just a little bit before we continue, because the thing I too commonly see is that the move to cloud comes from, let’s reduce cost, let’s move off our data center, which results in lift and shift, which results in not much change and potentially higher costs. Right? At least initially. What you’ve done is something different, which is become more customer centric, create the Wardley map from that. And then that led you to a very different place in terms of your serverless architecture. And again, I think for our listeners, we’ll define that that soon if you’re not familiar with it, but just a much more effective place in terms of flow and feedback to the business. It’s actually quite interesting to me, and I’m definitely a fan of Wardley mapping. Just tell our listeners a little bit about what Wardley mapping is and what this Wardley map looked like that brought you to, I think, a very unique place. And again, ahead of your peers.

David:
There’s two axis, there’s the value chain, which is your vertical, if you start from the customer and work your way back from the value chain, that’s your standard way of doing value mapping. But then what Simon has done is put on this movement, this evolution, where on the very left, it starts with Genesis, things that are brand new, that no one has done. And then it’s custom, that you figured it out, but you can’t really repeat it. Then you’re in the product where you can actually repeat something and then something becomes a commodity. When a component is commodity it’s not worth building it anymore, just go and rent it somewhere. What we started to do was we looked at how we would create value with the business in our technology platform.

David:
We started to look at things that were maybe customer product and thought, well, if that’s going to move, what happens next? What’s the next piece in the value chain? Back around six years ago, we were focusing a lot on compute, but you could quite easily see the compute was going to become a commodity very quickly. So we thought, okay, well, what then? And you say, well, is there a certain framework that will be the one framework to rule them all? You say, no. As we worked our way up the value chain, you go what next? What next? And then, so you can predict a movement and you can also spot inertia, is there potential blockers to that movement? Is there a technical decision we might make today that may prevent that movement?

David:
Once you can see that piece of inertia, you can say, well, let’s avoid that. And let’s make sure when I’m in enterprise architecture type discussions, let’s highlight that maybe that’s not a good move because there’s a potential inertia point. I think with far reaching vision forward, you can see, and I mean, I think that for software there is always movement, you just know the software is going to become faster and faster and faster. It was quite obvious to us that we keep a really clean architectural stance. And then one of the things that we felt was, I think is really nice, is Amazon talk about no one-way doors as you build your architecture, don’t do things that will shut off things in the future. Always leave a two-way door that you can back away from things. You can change your decision. That was a really important way of thinking. We try and have flexibility in what we do.

Mik:
Okay. Excellent. And so I think it was the Wardley mapping that catalyzed you and the organization’s thinking around value to the business, value to the market, which I think it’s so great at doing. And interestingly got you to sort of a new point in the space, right? Because it actually led you, I think further in the map to actually a serverless architecture where, like you said, very few people knew about anything other than Lambda back then. If you could just define for us at a high level, what serverless architecture is, as you know, is it just, I think a lot of people might be thinking it’s just the nickname for the next type of implementing, but what really is serverless architecture? And tell us a little bit about your learnings and your journey with Lambda as well.

Finding business value quickly

David:
The thing that we started to notice is once we have a foundation on strong engineering and we start to move engineers into the space, they naturally want to go fast, so any work that they’re doing that doesn’t seem valuable for our customer, they were starting to think about why do I need to do this? We used the term undifferentiated heavy lifting. Like, why am I spending two or three days doing this thing? It’s invisible for my business. So we started to use the term undifferentiated heavy lifting and how can we remove that? Things like provisioning a server, you don’t need to be doing that. Writing the configuration for a runtime, a workload, you don’t need to spend days and days maintaining that. Trying to reduce those things that you shouldn’t be doing.

David:
As we see things like, S3 Lambda and other serverless services, can I just maybe bind in something and use a bit of compute to use that service in a way that’s almost event driven? And I think event driven is key because the fact that you can have a very loosely coupled architecture where things can just an event off each other, which gives you a huge amount of flexibility. We started to come to the conclusion that serverless first, it’s not about functions as a service. That’s just the underlying compute model. It’s not about even that the cost model, the pay per use. It’s not really about that. It’s not about Lambda, definitely not. It’s more about finding business value quickly. What I started to notice that, when we had teams writing with this kind of service first mindset, their first implementation choice is a serverless component.

David:
They weren’t starting back at an on-prem Java framework and working their way up through all that evolution. We’ve done that, so let’s start at the end now and use a serverless approach to build our new technology. And if it doesn’t work, for some reason, we’ll fall back to PaaS or a containerized solution, and that’s fine. That’s perfectly acceptable. We have some great software running in containers and PaaS solutions, but let’s start with serverless and fallback if required. We noticed that the engagement of the engineers was just skyrocketing. Everyone loves working in this environment. We noticed that people could actually produce software a lot quicker. And then the quality of that software is quite high because some of the security considerations are better because you have less exposure. Some of the scalability is there, you get out of the box. You throw in all these non-functional requirements, that are taken care for you. I wouldn’t say it’s faster, it’s still very difficult, but engineers will be more effective and efficient with their time, which I thought was absolutely fascinating.

Mik:
Yeah. Exactly. I think this, I think that you hit on this undifferentiated heavy lifting. I think as you know, with my journey with I’ve been trying to do is help organizations find where the bottlenecks are, right? Basically, apply the theory of constraints as you’ve been doing. And I think first principles, identifying these bottlenecks, because what we so often see is that the sheer amount that developers spend on working on provisioning environments, configurations, and Kubernetes, and these things help. But if we actually dig into the areas where flow efficiency is most effective, where the bottlenecks are, so much of this goes into this heavy lifting. And I think what you realized so early on is that in, I think the phrase is perfect. I’m going to start using it. And now that you’ve said it, David, I hope others will, as well as it’s undifferentiated heavy lifting.

Mik:
If you’re looking at it from the point of view of the customer, all of that configuration, all of that time, is not going to something that measures value, which is why, of course, with the Flow Framework, these four items, they only measure the flow of value, so instantly all of that heavy lifting gets seen as something that’s not adding to the flow of value because you’re doing it repeatedly every time you’re trying to create a new application or bring something new to your customers, internal or external.

Lego building blocks analogy

Mik:
And I love that strategy. You start with the thing that’s got the least undifferentiated, heavy lifting. It sounds, it’s very obvious when you say it, but can you just give us a little bit more summary on how innovation happens in this kind of environment, what you’re providing to your developers and contrast that with, I think what you saw before, right? Because so many of our listeners are still trying to wrap their heads around the, what benefits will we get when we move from this, on-prem Java applications, to moving those into the cloud, to containers, but really where I think, again, where you’ve ended up, shortcuts, a big part of that journey, even though you’ve been very thoughtful around the parts of your portfolio, because like everyone else, you’ve got a large portfolio, falling back to containers or on to paths on potentially some things still on-prem.

David:
Yeah. Well, I think a lot of the controls we put in from our centralized cloud teams, are resource tagging, continuous deployment, pipelines, security controls, finance, et cetera. They will work for many different types of solutions in public cloud. Once you stand that up and you get to the ability to bake those controls into the environment, then we went up a gear, because then we thought, well, if you switch around, but we’ve got these controls baked into our environment and there’s one path to production. We do things like auto remediation. If something is tagged incorrectly, it’s gone, it’s zapped, so we’re very hard on our own teams. Then once you get to those controls, then you say, well, how can we speed up our engineers?

David:
And it’s not really about reference architectures as such like, this is how you build something. I think
reference architectures, where interesting yesteryear, but now it’s much more. I love the Lego analogy, give me good Lego building blocks and then I can build something fantastic. And the more complex the building blocks, the faster I can build.

David:
We started to look at templating patterns, architectural patterns, and that led us to CDK – the cloud development kit – where we started creating quick patterns that developers could maybe generate an API within a couple of seconds, within a minute. And there’s a production ready, hardened API. And then with all your correct tagging, and some well-architected features built in. Then you’ve got an accelerator, where people can take these building blocks and start to build applications faster, but in order to get to a place where developers could do that, we’ve got this system where we have a high level of engineering, which we encourage, we’re quite team centric with how that works. We encourage people to become experts in cloud, understand the cloud, read the white papers, actually get behind cloud, not just use it as a system.

David:
And then you can use these kinds of enablers to go really fast. I would call these serverless first building blocks. And it just so happens that last year, AWS brought in CDK, which is perfect. Before that, when we’re using CloudFormation, it was a bit trickier because the syntax of CloudFormation is a bit more complex, but CDK has been an absolute game changer. But again, the point is those building blocks for developers, having expert developers design those, is absolutely critical.

Mik:
Okay. And so you’re now at the point, actually even further in the journey of course, where you’ve got those Lego blocks. You’ve got these consumable services and development kits for developers. That is just amazing. And can you tell us, how did you make this case and how did the organization really support something that, again, at that point in time, when you started this journey years ago, and I think, still at this point in time, this is extremely cutting edge, so whether there was perception of risk that we’re trying to get ahead too high, too far away from what others are doing, how were you actually able to make this case to the organization?

Mik:
Of course, we heard what you said, which is the customer centric mandate that brought you to cloud. I think really this is the underpinning of everything because the thing I keep coming back to in hearing what you’re saying, David is organizations that have a cost centric mandate of moving to cloud. I see them go sideways at best, whereas this customer centric mandate brought you to something that I think to others initially would seem so risky, which is let’s bet on Lambda, on something very few of our peers are using at that point in time, but it’s actually brought you to the place where I think your point you just made, with this common set of controls, it actually sounds like you’re managing even risk and delivery. And then the pipeline better than others who might be stuck in, in other ways of doing things. So how did you make the case? And then of course get the ongoing support and investment within the organization, because you’ve pivoted and learned as you’ve gone along.

David:
Yeah, that’s a great question. I mean, for me, I think Liberty is a hundred-year-old company. We’ve always thought of technology as a differentiator. It’s not the IT department, technology is a key part of how we drive our business forward. We think completely in a digital manner. That’s just table stakes. The thing I thought was really interesting is we don’t really sit down with our business partners and talk about Lambda, provisional concurrence, step functions, that’s not how, you just say, well, what’s the goal for this book of business? Is it fast throughput? Is it low cost? What do we need to do to improve, the customer’s experience? What’s on your mind as a business partner?

David:
And when we start to get down to it, maybe it’s something I need something to market quickly. Something needs to be at low cost. We need to improve the experience. Find out what’s the actual business imperative behind the piece of work you’re on. It’s not just a project. We need to do A to B and we’ll be done by Christmas. It’s like, what are we trying to get out of this? Once your engineering team understands that they’ve got the skills, they actually build that, plus all the product scales as well to do all the, et cetera, that the proper design was at, the whole package brings together. Then you want to be in a place where effectively you’ve got power tools in the hands of your engineers and they understand what the business are after. I mean the business will now ask us, can you make that secure and make it perform? You just know that you have to do those.

David:
We had some early wins. We had really solid cloud foundations. And then we had some really strong, early wins. The one story was what, I think it was 2016, 2017. We started to experiment with natural language processing around our call centers and how do we bring in voice into, how do you bring the Alexa experience into some of our call centers? We looked around different options for doing that. And there was all these great vendors, but expensive and long tails. We thought, we reckon we could build that ourselves with the serverless mindset, so we actually, we built a working prototype in 12 weeks that we put into production. We probably wouldn’t have signed the contract with some founders in 12 weeks, so we were able to in-house, we built a fully serverless chatbot in production in the call center that was able to speak with policyholders with natural language and have a conversation.

David: And so what we did was we had a very small number of calls that it was handling. We went through an awful lot of really strong design principles to figure out what that should be like. And we tested the customer experience and it was things like very simple queries, when will my rental car be ready? Next Tuesday. Okay, thanks. Stuff like that. We put that to market in 12 weeks, production ready and hardened. And then we just scaled that and now it hits, I think it takes something like 200,000 calls a month. And now when people say, “Wow, how did you do that?” Say, “Well, we used the serverless approach.”

David:
It’s kind of like show, don’t tell. When you get a piece of work, that it’s ready for this type of technology, then that’s how you show it, you’ve built it quickly, it’s performant, it’s cost-effective, it just ticks all the boxes. For me that’s cloud native, being able to be very innovative and responsive and as well, the fact that you can turn things around really quickly. If someone asks for a feature, you can have it in production in a matter of days, not months.

Mik:
As you know, I couldn’t agree more. That is the pattern of success that I’m seeing in terms of helping bring the organization to invest the right ways and empower the right people to create these modern cloud architectures where it’s, if you’re demonstrating now, something that was meaningful to part of the business, like this bot for the call center. And you’re showing that this thing had a flow time, that’s measured in days, not what everyone’s been seeing on the other parts of the portfolio, right? Weeks and months, and that’s measurably, there providing value and then scaling up. It’s amazing how infectious that becomes and how quickly it can bring the organization forward.

David:
And there’re tons of examples where we’ve done that. That was just one of the early ones that was quite significant. We’re repeating that pattern time and time again. And even to something, we actually did something recently. We had a homeless organization in Dublin that spoke to one of our engineers, guy called Andy O’Sullivan, and he was just doing a bit of outreach work. They said, “We’d really like an app to do some certain things.” And he looked at it. And there was no budget, so he built something really quickly in serverless, that they were able to use as part of their reach out to homeless people in Dublin. Even building really quick applications that work are hardened and low cost. It’s absolutely incredible, but, and this is the most important thing, for anybody who’s receiving this software, it doesn’t sound like IT. It’s a partner enabling their problem with technology. That’s just a game changer. There’s no requirements documents, big lead in times. It’s like, what do you want? Boom, there you go. It’s that fast feedback. It’s incredible.

Mik:
That is an amazing story. And I think it’s a heartening story and how quickly those things can spread and the value of, for the business, for the community of being able to innovate so much faster. This goes back to your approach with this, right? You didn’t create the Kubernetes team and the Lambda team. The way they even think about team structures. To me, of course, the most interesting thing is aligning product value streams, so the way that you can deliver value, such as through the homeless application, through the structure of your software architecture, which you’ve aligned through cloud native and serverless, and through the team structure. Because in the end, if the team structure is aligned to technology, less then is aligned to business value, there’s a mismatch. Tell us a bit about how you think about that angle of things. Because again, I think it’s getting all these three things, right that really drives some incredibly fast results.

David: Yeah. I think, like I said, we’re big fans of Team Topologies. I think the work Matthew Skelton and Manuel Pais have done is fantastic. It’s really helped our thinking. And we’ve always thought that the team is the unit of delivery. It’s not a bunch of people, it’s the team, so you look at that team and do they have what they need, the expertise, the capability, et cetera. And I think, then the leadership within that team are that team able to sit with their business partners and actually figure out what is needed? I think for me, the interesting thing about the insurance industry, probably people think it’s sounds like it’s quite risk averse and no one does anything. It’s probably quite the opposite.

David:
We understand risk exceptionally well. And if you’ve got that team aligned to business, it’s really about how can we find the value? How can we find something that’s going to be a differentiator to build and having the courage to say, okay, that’s, what’s needed, let’s go ahead and invest and build that. Or we don’t need that, let’s stop. It’s almost like, the courage to build and the courage to stop.

Code is a liability

David:
One of the things I find fascinating about serverless and it’s something we, I’ll take you on a slight tangent, it’s a mindset we started to get into the teams, is code is a liability. We’re all like, “I’ve been writing code since I was probably eight.” Do you know what I mean? Love writing code, but if teams of builders and they want to build, so you always say, “Well, when you turn up to work, your job is not to build, your job was to help your partner achieve their business needs. And sometimes that is not writing software.”

David:
Getting that aspect, that understanding of code is a liability. And this, I think, this is really strong for our business partners. It’s not an asset. When you write a piece of code, that’s not an asset you need to protect, that’s a liability, and the more you have of it, the greater the risk, the security risk, maintenance risk, deprecation, et cetera, so less code the better. It’s the system, that’s the asset. So, spend time getting the system right, and try and do as little code as possible. That’s the thing that’s been a real game changer. So as we start, and I mean, you can think of Lambda as the glue, you’re just tying things together, so it’s a different way to think about building technology. Getting that code is a liability mindset into the teams has been really important because sometimes, a business partner will say, “I’ve seen something we need to build X.” And you need to say, “Well, yes, that’s a good idea. And if we understood the business problem fully, we could maybe have a few alternatives where maybe we don’t have to build something.”

David:
I think getting the teams in the right mindset to create value, I think has been really, really important. And one thing that Team Topologies has given our teams is getting the team to focus on either a value stream, a complex value stream, enablement, helping others or even platform. Because we do have some teams building platforms, but they need to understand that’s their primary focus. It’s what’s always a red flag for me when a team says, “Yeah. We’ve got a value stream and we’re helping these guys and we’re also building the platform.” It’s like, okay, well, that’s not good.

Mik:
Yeah, exactly. For anyone who might not have heard it in terms of, I think I’m a big fan of Team Topologies. We did an earlier Project to Product podcast with them because in the end, these topologies are the patterns that will actually allow you to understand how to align your teams to value streams and different options that you’ve got. It’s a great thing to look into. And I think it is one of these principles, David, that you were reflecting here. And so, let’s just talk, you mentioned undifferentiated, heavy lifting. And I think that applies regardless of what your architecture is today, you need to be looking for the undifferentiated heavy lifting. That’s not contributing to your flow in any way, or your feedback cycle, it’s actually impeding it. And the point on code is a liability.

Mik: Again, my view is that applies universally. Like you, I’m a fan of event based architectures. Our core products have shifted to those, but we still have some legacy that’s not event based. And the thing we celebrated last week at my company is how much code was removed from a very much older product line, because now we’ve got less liability there. And, I think, sometimes we do over fixate on it’s always around technical debt reduction, but really elevating technical debt reduction. That whole point of the Flow Framework is to allow you to invest in removing that liability. And I actually do see the same thing as you. Organizations that actively remove code, actively remove liability, are able to move complex portfolio ahead much faster.

David:
Yeah. I think that the Flow Framework is fantastic for actually visualizing some of these things. And you can see the different impacts that are hidden because as you talk about technical debt, there’s also business debt. I think, sometimes if you’ve been in a certain line of business for maybe 10, 20, 30 years, it will grow extra complexity, so I think it’s something like the Flow Framework give that visibility and how things are planned out. And then you can actually identify, is it technical debt or even business debt, which gives you a great indication of what to go for next.

Mik:
Yeah. I’m glad you made that point. I think the goal of the Flow Framework is just to actually allow executives, other parts of organization, very different parts of the technology organization to see the dynamics that you see. To see the dynamics that you’re reflecting and that you’re actually able to steer your organization through by actually understanding these trade-offs. It has been amazing for me to see as I’ve been looking at more and more of these were the biggest constraints are because in the end, I think this is truly about what Adrian Cockcroft said on the podcast, which is applying the theory of constraints to your observe, orient, decide and act loop your OODA loop. You’ve been doing that all along. I’ve been trying to make those constraints more visible because there are these different, basically theory of constraints is a whack-a-mole, where you’ll actually address some of the technical debt constraint, you address the architecture constraint, and then you’ll be, what will be staring you in face is the business debt.

Tech and Business relationship

Mik:
I’m so glad you bring that up because in the end, if some of those things aren’t addressed that are actually the root or the source of different aspects of debt that the teams are dealing with themselves. If they’re still stuck customizing this particular application for eight different regions, rather than moving to a common platform by making things like search a common platform that the regions consume, a common service, you might not be able to unlock that without actually addressing the business debt. Easier said than done. How have you been approaching the business debt side of it?

David:
Again, it’s partnership. I think you can’t be thinking like the IT team and the business team. You have one team and you have one [business imperative (https://www.theserverlessedge.com/technology-in-business/). And if whatever your goal is, I think you just need to look at that. Again, I think it takes courage and leadership from everyone in that team. And usually there is an individual who is effectively that business owner of that book of business or that business problem. And you want to really get behind what’s their short term/long-term goals? Where do they need to tick? And sometimes there’s a simplification effort. And that’s the business process. Sometimes you reimagine it with innovation. Other times there’s a kind of like a refactoring effort to kind of tidy up some downstream tactical debt.

David:
You know, you don’t really know, but I think the first point is sit down with the business owner. And I’m not using the word stakeholder there, I think that’s important. The business owner, whoever is kind of owning a piece of business and saying, “Well, let’s sit down as a team and figure out what our options for doing next.” I think it’s that honesty, courage, and leadership to sit down and look at that right across the board and I think as well, I mean, you talk about in the Flow Framework, you have different flows. I mean, the phrase we tend to use is journeys. We look at the different journeys within our enterprise and to say, how can we make this more efficient or effective? And I think you need to have that kind of holistic viewpoint of it. Because again, I mean, it’s not just a software, there’s a bunch of stuff, but I think it starts a conversation about, okay, what’s the business imperative here? And then you work your way back from that.

Mik:
Yeah, exactly. David, you said so well as you sit down, it’s one team. And then as you said, previously, you say, what’s the goal? Is our goal of reducing costs? Is our goal moving to market faster? Is our goal more of an innovation? Is our goal getting more conversions? And this is a goal that’s set for the value stream, for the teams. And a common goal that you march through. And I think again, the power of having that single goal, which by the way, is something that evolves over time. I’ve heard you talk about evolutionary architecture. Today, the goal might be quickly innovating more features to market, but then of course the technical that might increase or your cloud costs might increase to the point where you actually now have to do some refactoring, re-architecture to get to that common goal of continuing to deliver value to the customer. I think, your guidance on actually, again, making this in the end, it’s making these trade-offs visible to the business owner, I think, is what you’re guiding others to.

David:
Yeah, absolutely. And I mean, I think when the individuals and the technology team understand the business domain, maybe you’ll know, well, okay, we’re going to see a spike in traffic in six months time. And we understand that they’re things we need to do ahead of time. Maybe there’s going to be, there’s some change coming up, but I think, I mean, how can we get away from it now? I mean, you touched on it very well with Project to Product. You can’t have the attitude – “we’ll not do that unless we get a requirement”. I mean, that doesn’t work today. You’ve got to think ahead and understand. You’ve got to look ahead. I think in insurance, they’re certain things that we see are going to happen. They're different patterns year on year, but they’re all the things that are completely unexpected.

David:
I think, you need to be very flexible and how you need to prioritize. Number one, you serve your customers first. What potentially could happen were you, and you don’t want your systems to basically fall short in a time of need. I think, and you can’t play the contract game. ‘Well, you didn’t tell us how they maybe hit the million users in a day.’ You can’t sit and you can’t play that game. You have to be, you have to look ahead and be preemptive and think what could potentially happen that I need to bake into the system. I’m a big believer in the technology team, understanding the business domain and figuring out, what does the system need to do based on what we know may happen?

The Serverless Edge

Mik: Excellent. And so, David, I think we’re at time right now, but I want to make sure that for our listeners, some of what you’ve done and actually the technology parts of the journey, I think the amazing thing has been the way that you and the organizations have leaned in to these new technologies and the results that you’ve seen. I actually do think it’s important to understand and keep up with some of those key technology movements because that’s what you put in place. And you were actually able to, after understanding how this would meet the needs of the customer, where you end up on that Wardley map, select the right set of technologies and the architectures that supported the flow and feedback needs of the business. I hear that you’re launching a blog, where you’re actually going to talk about some of those key technology practices. If you could just tell us about that, because again, I encourage everyone to check it out and understand where these technologies are going because of how powerful they can be of excelling this flow and feedback loop.

David:
Yeah, well, we’ve got a blog called The Serverless Edge. What’s the cutting edge of technology? And it’s not really the latest version of a framework or component. It’s what is the edge of the future of work, the edge of technology to kind of that future facing technology. And it’s really, there’s different business models that are currently evolving. They’re different ways that we handle our technology. I think some companies understand that, but it’s not well understood. I think a lot of people, when you mentioned serverless, they’ll say, “Yeah, Lambda.” It’ll turn on the Lambda versus container arguments, which is exactly not what it is. You’ve got to elevate yourself above the technology. Think about if I’m on the edge of technology, what does that mean?

David:
What does my company need to feel like? How do we need to lead or how do we set ourselves up for success? What are the things you need to think about? I think there’s a mindset if you’re going to be in that kind of serverless edge, that’s really important to understand. And I think it’s quite difficult to unpack that from a lot of the press and you usually see coming around. I think sometimes you need at least people to give you a bit of narrative or a bit of commentary about different things that are happening because once you get into the cloud providers and see a lot of the technologies, it gets confusing very quickly.

David:
That we’re trying to do with the Serverless Edge is basically to put a commentary on that for, and you don’t need to be a developer to read it. We’re trying to be quite, reach a broader audience. There is a different way of working. It actually sits very well with the future of work as well, because you can, there’s a much different way of working. And I think it’s going to be a game changer for some companies. It’s almost like what I’d call, it’s the next level of cloud, whatever that’s called.

Mik:
Yeah.

David:
I don’t think serverless is a great name, but hey, that’s what we’ve got.

Mik:
It gets across some of the key concepts in terms of getting rid of that undifferentiated heavy lifting, which I think you and I in our entire careers have felt what that’s like and want everyone to feel a whole lot less of it.

David:
Yeah.

Mik:
And delivering.

David:
Absolutely. Yeah.

David:
I’m telling the story as well about kind of how to enable a serverless cloud center of excellence at
Reinvent this year as well, 2020. That will be a talk as well. Myself and Jessica Fang are giving that talk, which is a bit more detailed about party enabled that serverless cloud center of excellence.

Mik:
Excellent. Well, David, any, amazing, and I really look forward to following the Serverless site as well and any, I encourage others to do so, too. It’s great to have this out there, again, this combination of technology and very forward-looking, but very actionable architecture. And really, as you said, I completely agree that the next step of cloud, but a step, the next of a cloud that you should be thinking about now, and you should maybe just be jumping straight into it as, I think you’ve made clear through some of your successes. Any final thoughts to leave the audience with?

David:
I just think, I mean, I think it’s worth looking forward. I do. Something like Wardley mapping, and I think it’s a difficult technique, but I couldn’t advocate enough for actually sitting down with some leaders in your organization and casting your mind forward because I think there’s a huge amount of change happening at the minute. And I think they’re repercussions in your own organization, in your market and in your technology landscape, so I think actually sitting down and thinking ahead of where do we need to be? And actually discovering the shape of that. And how you think technology and your business landscape may evolve. We have to be ready for that. I think there’s an awful lot of challenging frameworks around business strategy, but I’d be a huge advocate of Wardley mapping because it’s a fantastic way to actually see into the future, so I would definitely have a look at that.

Mik:
Okay, excellent. And my one recommendation on that is to bring your leading technologists into that discussion because if you’re doing it without that kind of deep technological insight. I’ve seen this Wardley maps end up in slightly different places than they should, but clearly what you’ve done is absolutely leading.

Mik:
Thank you so much, David, and we’ll check out TheServerlessEdge.com.

David:
Thanks Mik. Really appreciate the time. Great chat.

Mik:
Huge thank you to David for joining me on this episode. For more, follow me in my journey on LinkedIn, Twitter, or using the #MikPlusOne or #ProjecTtoProduct. You can reach out to Dave on LinkedIn or his Twitter, which is @Davidand393https://twitter.com/davidand393. I have a new episode every two weeks, so hit subscribe to join us again. You can also search for Project to Product to get the book and remember that all author proceeds go to supporting women and minorities in technology. Thanks, stay safe. And until next time.