What is the Serverless-First journey in Liberty Mutual?

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

Episode 21: David Anderson on IT Shifting to Partner-Enabling Technology by Mik + One: Project to Product

Mik Kersten:
Hello, and welcome to the Mik + One podcast. 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. It’s absolutely fascinating because I think we’ve got an example of the right direction architecture to enable this fast feedback loop. As what Adrian called, 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. I really want you to listen. You’re going to hear as an executive and technology message on how to move into the future of cloud. And how to, most importantly, apply that to innovation in your business. So, David welcome.

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

Liberty Mutual and Cloud Computing

Mik:
Before we get into some of the deeper concepts, tell us just a little bit about how Liberty’s technology is structured and 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 is 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 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. What you’ve done within your organization is actually much more forward-looking in terms of cloud architecture than I’m used to seeing. From a technology point of view, it makes sense. This is the future of how we’re going to do cloud computing.

Tell us a little bit about what’s happened. Because a lot of organizations and executives are trying to wrap their heads around Kubernetes and containers. But where you’ve ended up is actually somewhere quite different. And I actually believe is 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:
It’s our journey towards serverless-first. Around 10 years ago, our CIO James McGlennon kicked off three big initiatives:

We did those three things roughly at the same time. And that set us off on a good trajectory.

As we started the move towards public cloud, we put in solid cloud native principles. That really helped define how we worked with finance, security and other parts of the organization. What does a really good cloud stance look like for a large enterprise? We figured it out six years ago. We started that infrastructure move, while doing an agile transformation and becoming extremely customer centric in how we think.

The importance of Wardley mapping

Back around that time, myself and my team were huge fans of Wardley mapping. We started to read the content as Simon Wardley was working on it. We were following 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 how to become innovative and bring in speed and fast feedback. How do we make sure we focus on the value and become a learning organization. And not stand still. We started to Wardley map out the landscape of the cloud, and it landed on serverless. That was the perfect direction for us.

While the bigger organization was doing the cloud infrastructure move, we needed to look at the application architecture move, which is the layer on top of it. How were we going to behave 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, which were interesting. But the whole serverless-first movement hadn’t really happened yet. We were quite lucky that we could see forward. And I 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 the wrong place. Let’s reduce cost or let’s move off our data center! Which results in ‘lift and shift’. And that results in not much changing and potentially higher costs. At least initially.

What you’ve done is something different. Which is become more customer centric and create a Wardley map for that. 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 it is 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 a very unique place ahead of your peers.

There are two axis. The value chain, which is your vertical. Start with 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 in movement and evolution. On the very left, it starts with Genesis. They are things that are brand new and that no one has done. Next it’s Custom. Things that you figured it out, but you can’t really repeat. Then you’re in Product where you can actually repeat something and that something becomes a commodity. When a component is commodity it’s not worth building it anymore. You need to just go and rent it somewhere.

How we applied Wardley mapping to our business

We started looking at how we could create value with the business on our technology platform. So we looked at things that were customer product and thought, well, if that’s going to move, what happens next? What’s the next piece in the value chain?

Around six years ago, we were focusing a lot on compute. But you could quite easily see that compute was going to become a commodity very quickly. So we thought, okay, well, what then? Is there a certain framework that will be the one framework to rule them all? No. As we worked our way up the value chain, we looked for what next? What next?

So you can predict a movement and you can also spot inertia. Is there potential blockers to that movement? Or is there a technical decision we might make today that may prevent that movement?

Once you can see that piece of inertia, you can say, well let’s avoid that. And in enterprise architecture type discussions, let’s highlight that’s not a good move because there’s a potential inertia point. I think with that far reaching vision you can see. In software there is always movement and it is going to become faster and faster and faster. It was quite obvious to us that we needed to keep a clean architectural stance.

Amazon talk about no one-way doors as you build your architecture. Don’t do things that will shut off other things in the future. Always leave a two-way door so you can back away and change your decision. It is a really important way of thinking. We try to have flexibility in what we do.

Finding business value quickly

Mik:
Wardley mapping catalyzed you and the organization’s thinking around value to the business and 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. Because it actually led you to serverless architecture. When 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. A lot of people might be thinking it’s just the nickname for the next type of implementation. But what is serverless architecture? And tell us a little bit about your learnings and your journey with Lambda as well.

David:
We started to notice, once we have a foundation of strong engineering and we start to move engineers into the space, they naturally want to go fast. Any work that doesn’t seem valuable for our customer, they are starting to think why do I need to do this?

We use the term undifferentiated heavy lifting. 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 looking to see how can we could remove it. Things like provisioning a server? You don’t need to be doing that. Writing the configuration for a runtime or a workload? You don’t need to spend days and days maintaining that. Try to reduce those things that you shouldn’t be doing.

Binding in serverless services

With S3 Lambda and other serverless services, can I bind in something with a bit of compute to use that service in a way that’s almost event driven? Event driven is key because you can have a loosely coupled architecture where things can event off each other. Which gives you a huge amount of flexibility.

We started to come to the conclusion that serverless-first is not about functions as a service. That’s just the underlying compute model. It’s not about even the cost model, the pay per use or Lambda. It’s more about finding business value quickly. I started to notice that teams with a serverless-first mindset made their first implementation choice with a serverless component. They weren’t starting back at an on-prem Java framework and working their way up through all that evolution. Their attitude was that we’ve done that. So let’s start at the end and use a serverless-first 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. We have some great software running in containers and PaaS solutions. But let’s start with serverless and fallback if required.

Increasing engagement of engineers

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 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.

Mik:
You hit on this undifferentiated heavy lifting. In my journey I’ve been trying to help organizations find where the bottlenecks. Basically, apply the theory of constraints as you’ve been doing. And I think the first principle is identifying these bottlenecks. Because so often we see the sheer amount that developers spend working on provisioning environments. Configurations, Kubernetes and other things help. But if we actually dig into the areas where flow efficiency is most effective. It’s where the bottlenecks are. So much of this goes into heavy lifting. You realized that early on. 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. It’s undifferentiated heavy lifting.

Looking at it from the point of view of the customer, all of that configuration and time, is not going on something that measures up to value. The Flow Framework only measures the flow of value. So instantly all of that heavy lifting is not adding to the flow of value. Because you’re doing it every time you’re trying to create a new application or bring something new to your customers, internally or externally.

The Lego building blocks analogy

I love that strategy. You start with the thing that’s got the least undifferentiated heavy lifting. It
sounds very obvious when you say it. But can you give us a little summary on how
innovation happens in this kind of environment. What are you providing to your developers. And contrast that with what you saw before. Because so many of our listeners are still trying to wrap their heads around the benefits. What will we get when we move from on-prem Java applications into the cloud.

And even though you’ve been very thoughtful about your portfolio, like everyone else, you’ve got a large portfolio. So you can fall back to containers or to paths with some things still on-prem.

Centralized controls

David:
A a lot of the controls we have are from our centralized cloud teams: resource tagging, continuous deployment, pipelines, security controls, finance, et cetera. They can work for many different types of solutions in public cloud. Once you stand that up, you get to the ability to bake those controls into the environment.

We went up a gear, because we thought, if we switch around, 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. Once you get those controls, then you can ask, how can we speed up our engineers?

And it’s not really about reference architectures like, this is how you build something. I think
reference architectures are from yesteryear. 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.

Cloud Development Kit (CDK)

We started looking at templating patterns and architectural patterns. And that led us to CDK – the cloud development kit. We created quick patterns so developers could generate an API within a couple of seconds or within a minute. And that’s a production ready, hardened API.

With correct tagging and well-architected features built in you can have an accelerator. Engineers 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 a system of high level of engineering. And we’re team centric. We encourage people to become experts in cloud, understand the cloud, read white papers and actually get behind cloud. And not just use it as a system.

Then you can use these enablers to go really fast. I call them serverless-first building blocks. It just so happens that last year, AWS brought in CDK. Before that, we used CloudFormation. It was a bit trickier because the syntax of CloudFormation is complex. But CDK has been an absolute game changer. But the point is having those building blocks for developers. And having expert developers design those building blocks, is absolutely critical.

Getting the organisation on board with serverless

Mik:
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. How did you make the case? And did the organization really support something that? Because at that point in time, when you started this journey years ago, this was extremely cutting edge. Was there was perception of risk that we’re trying to get ahead too high or too far away from what others are doing? How were you actually able to make this case to the organization?

We heard that the customer centric mandate brought you to cloud. I think that is underpins everything. Organizations that have a cost centric mandate of moving to cloud go sideways at best. Whereas this customer centric mandate brought you to something that I think to others initially would seem so risky, eg. let’s bet on Lambda. Something very few of our peers were using at that point in time.

But it actually brought you to a common set of controls where you’re managing risk and delivery. And the pipeline is better than for others who might be stuck in other ways of doing things. So how did you make the case? And then get ongoing support and investment within the organization, because you’ve pivoted and learned as you’ve gone along.

Technology is a differentiator

David:
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 in a digital manner. That’s just table stakes. The thing that’s interesting is we don’t sit down with our business partners and talk about Lambda, provisional concurrence or step functions. Instead we ask for the goal of a 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?

And when we get down to it, it maybe something that needs to get to market quickly. Or something needs to be at low cost. And ee need to improve the experience. Find out the actual business imperative behind the piece of work you’re on. It’s not just a project. We need A to B done by Christmas.

It’s like, what are we trying to get out of this? Once your engineering team understands that and they’ve got the skills, they can actually build that. Plus all the product scales to do design and the whole package. You need to be in a place where you’ve got power tools in the hands of your engineers and they understand what the business are after. The business will ever ask to make it secure and make it perform. You just know that you have to do those.

Early wins with our Serverless ChatBot

We had really solid cloud foundations. And then we had some really strong, early wins. In 2016/ 2017, we started to experiment with natural language processing in our call centers. We were looking at how to bring in voice. How to bring an Alexa experience into our call centers? We looked around different options. There were great vendors, but they were expensive and with long tails. We has the thought that we could build it ourselves using the serverless-first mindset. So we built a working prototype in 12 weeks and put into production. We probably wouldn’t have signed the contract with vendors in 12 weeks!

We in-house 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. It was handling a very small number of calls. We went through a lot of strong design principles to figure it out. And we tested the customer experience. It was handling very simple queries like ‘when will my rental car be ready?’. We put that out to the market in 12 weeks, production ready and hardened. And then we just scaled. It handles over 200,000 calls a month. And when people say, “Wow, how did you do that?” We say: “We used a serverless-first approach!”

It’s like show, don’t tell. When you get a piece of work that ready for this type of technology, that’s how you show it. You’ve built it quickly. It’s performant and it’s cost-effective. And it just ticks all the boxes. For me, that’s cloud native! Being innovative and responsive and turning things around quickly. If someone asks for a feature, you can have it in production in a matter of days, not months.

Patterns of success

Mik:
As you know, I couldn’t agree more. That is the pattern of success that I’m seeing. In terms of helping the organization invest in the right way and empower the right people to create modern
cloud architectures. You can demonstrating something meaningful to part of the business, like this Chatbot for the call center. And you’re showing this thing had a flow time measured in days. That’s not what everyone’s been seeing on other parts of the portfolio. It’s amazing how infectious that becomes. And how quickly it can bring the organization forward.

David:
There are tons of examples of 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 recently. We had a homeless organization in Dublin that spoke to one of our engineers called Andy O’Sullivan. He was doing outreach work. They said, “We’d really like an app to do some certain things.” And he looked at it. 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 are hardened and low cost. It’s absolutely incredible.

The most important thing, for anybody who’s receiving this software is that it doesn’t sound like IT. It’s a partner solving their problem with technology. That’s the game changer. There’s no requirements documents or big lead in times. It’s like, what do you want? Boom, there you go. It’s fast feedback. It’s incredible.

Aligning product value streams

Mik:
That is an amazing story. And I think it’s a heartening story about how quickly those things can spread. And the value for the business or the community of being able to innovate so much faster. This goes back to your approach with this. You didn’t create the Kubernetes team and the Lambda team or even think about team structures.

The most interesting thing is aligning product value streams. So the way you can deliver value, such as through the homeless application, is through the structure of your software architecture. Which you’ve aligned to cloud native and serverless and through the team structure. Because in the end, if the team structure is aligned to technology, less than it is aligned to business value, there’s a mismatch. Tell us a 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.

Team Topologies – teams are the unity of delivery

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

We understand risk exceptionally well. If you’ve got a team aligned to business, it’s about how to find 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, so let’s stop. It’s the courage to build and the courage to stop.

Code is a liability

One of the things I find fascinating about serverless and it’s slight tangent, is the tenet that code is a liability. I’ve been writing code since I was eight. I love writing code. But if teams want to build you have to be able to say, “your job is not to build, your job is to help your partner achieve their business needs. And sometimes that is not writing software.”

They need that have the understanding that code is a liability. Code is not an asset. When you write a piece of code, it’s not an asset you need to protect. It’s a liability. The more of it you have the greater the risk. The greater the security risk, maintenance risk, deprecation, et cetera. So less code the better. The system is the asset.

Spend time getting the system right, and try and do as little code as possible. That’s the real game changer. You can think of Lambda as the glue. You’re just tying things together. It’s a different way to think about building technology.

Code is a liability mindset

Getting the ‘code is a liability’ mindset into 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 anything.”

Get the teams into the mindset of creating value. That is really important. One thing that Team Topologies has given our teams is focus. Focus on a value stream, a complex value stream, an enablement, helping others or even a platform. Because we do have some teams building platforms. But they need to understand that’s their primary focus. It’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, well that’s not good.

Elevating tech debt reduction

Mik:
I’m a big fan of Team Topologies. We did an earlier Project to Product podcast episode with them. Because in the end, these topologies are the patterns that will allow you to understand how to align your teams to value streams. And the different options that you’ve got. It’s a great thing to look into. One of these principles, David, that you were reflecting on is 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 or your feedback cycle. And it’s actually impeding it.

And on your point that code is a liability, 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 an older product line. Because now we’ve got less liability there.

Sometimes we over fixate on technical debt reduction. But it’s about 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 see the same thing as you. Organizations that actively remove code and actively remove liability, are able to move complex portfolios ahead faster.

The Flow Framework

David:
Yeah. I think that the Flow Framework is fantastic for actually visualizing some of these things. And you can see different impacts that are hidden. Because as you talk about technical debt, there’s also business debt. If you’ve been in a certain line of business for maybe 10, 20, 30 years, it will grow extra complexity. Something like the Flow Framework gives that visibility of how things are planned out. And then you can actually identify if it’s technical debt or even business debt It 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 to allow
executives and other parts of organization to see the dynamics that you see. To see the dynamics that you’re reflecting so that you’re actually able to steer your organization through by understanding the trade-offs.

It has been amazing for me to see where the biggest constraints are. Because in the end, I think this is truly about what Adrian Cockcroft said on the podcast. It is about 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 the basic theory of constraints is a whack-a-mole. Where you’ll actually address some of the technical debt constraint or the architecture constraint. But what will be staring you in the face is business debt.

Tech and Business relationship

If some of those things aren’t addressed that are the root or source of of debt that the teams are dealing with, they’re stuck customizing a particular application for eight different regions. Rather than moving to a common platform that the regions consume. You might not be able to unlock the problem without 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 of an IT team and a business team. You have one team and one business imperative. And whatever your goal is, you just need to look at that. It takes courage and leadership from everyone in the team.

Get behind the business goals

And usually there is an individual who is effectively the business owner of that book of business or that business problem. You need to get behind their short term/long-term goals? Where do they need to tick? And sometimes there’s a simplification effort and nd that’s the business process. Or sometimes you reimagine it with innovation. Other times there’s a refactoring effort to tidy up downstream tactical debt.

The first point is to sit down with the business owner. And I’m not using the word stakeholder there. I think that’s important. The business owner owns a piece of business. And you are saying, “Well, let’s sit down as a team and figure out what our options are next.” It’s that honesty, courage, and leadership to sit down and look that’s needed right across the board. In the Flow Framework, you have different flows. The phrase we tend to use is journeys. We look at the different journeys within our enterprise to see how can we make them more efficient or effective. You need to have an holistic view of it. Because it’s not just a software. Starts a conversation about what’s the business imperative here? And then you work your way back from that.

The power of a single goal

Mik:
As you said so well, you sit down as one team. And then you say, what’s the goal? Is our goal: reducing costs, moving to market faster or is our goal more of an innovation? Is our goal getting more conversions? And it is a goal set for a value stream for teams. And a common goal that you march towards.

The power of having that single goal 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 the tech might increase or your cloud costs might increase to the point where you have to do refactoring. Or re-architecture to get to that common goal of continuing to deliver value to the customer. You guidance is about making these trade-offs visible to the business owner.

Tech needs to understand the business domain

David:
When individuals and the technology team understand the business domain, they’ll know to expect a spike in traffic in six months time. And we understand the things we need to do ahead of time.

You touch on it very well with Project to Product. You can’t have the attitude – “we’ll not do that unless we get a requirement”. That doesn’t work today. You’ve got to think ahead and understand. In insurance, there are certain things that we see are going to happen. There are different patterns year on year. But there are also things that are completely unexpected.

You need to be flexible and you need to prioritize. Number one: serve your
customers first. You don’t want your systems to fall short in a time of need. And you can’t play the contract game. ‘Well, you didn’t tell us that we would hit one million users in a day.’ You can’t sit and play that game. 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: 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 able to understand how this would meet the needs of the customer ad where you you end up on that Wardley map. Through selecting the right set of technologies and architectures that supported the flow and feedback needs of the business.

I hear that you’ve launching a blog, where you’re talking about some of those key technology practices. 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. It looks at the cutting edge of technology. And it’s not really the latest version of a framework or component. It’s about the edge of the future of work. The edge of technology and that future facing technology.

The serverless edge mindset

There are different business models evolving. And different ways to handle our technology. I think some companies understand that. But it’s not well understood in general. I think a lot of people, when you mention serverless say, “Yeah, Lambda.” That turns on the Lambda versus container arguments. But that is not what it is. You’ve got to elevate yourself above the technology. And Think about the edge of technology and what does it mean?

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 you needs if you’re going to be on that serverless edge. That’s really important to understand. And I think it’s quite difficult to unpack that from a lot of the press you see around. You need people to give you narrative or commentary about different things that are happening. Because once you get to the cloud providers and see a lot of the technologies, it gets confusing very quickly.

That we’re trying to do with The Serverless Edge is provide a commentary for that. You don’t need to be a developer to read it. We’re want to reach a broader audience. There is a different way of working. It actually sits very well with the future of work. Because it’s a different way of working. And I think it’s going to be a game changer for companies. It’s the next level of Cloud!

Serverless Cloud Center of Excellence

I’m doing a talk on ‘How to enable a serverless cloud center of excellence‘ at
AWS re:Invent. Jessica Fang is giving that talk with me.

Mik:
I really look forward to following The Serverless Edge. I encourage others to do so, too. It’s great to have this combination of technology and very forward-looking, but very actionable architecture. I completely agree that the next step of cloud is what you should be thinking about now. And that you should just be jumping straight into it as you’ve made clear through some of your successes. Any final thoughts to leave the audience with?

David:
It’s worth looking forward with something like Wardley mapping. It can be 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. There are repercussions for your own organization, your market and your technology landscape.

So sit down and think ahead about where you need to be? And discover 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.

Mik:
My one recommendation is to bring your leading technologists into that discussion because you can’t do without 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.

Conclusion

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 @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.