We’ve been going through the Value Flywheel Effect in the past few episodes. And talking about the different phases. The Value Flywheel is the core mechanism we talk about The Value Flywheel Effect book. There are four phases. The first is Clarity of Purpose, then we have Challenge, Next Best Action and Long Term Value. Today we’re talking about Next Best Action. That’s the third phase. So let’s start. What is it? What is next best action?
Next Best Action Focused on Business Value
When you boil it right down, you’ve got your Northstar, Clarity of Purpose and you understand your landscape. But how do you start? What is the next best thing you can do? What is the simplest thing you can start today to improve your lot. And help the flywheel turn a little smoother and remove some inertia barriers. In very simple terms: what is the next best thing you can do today, tomorrow or this week?
There’s no hiding in the book that we’ve got a preference towards serverless and serverless first thinking. Conceptually, you need your next best action to be focused on business value. And not focused on building a huge platform. Or spending the next six months organising runtime or infrastructure strategy. You need to get going and start adding value as quickly as possible.
Bias for action is critical. You need to get feedback on the things that you’re doing well. And you won’t get any feedback if you do nothing! You won’t see if your hypotheses are proving to be correct if you don’t try stuff. It takes a little bit of courage.
In the last episode we talked about psychological safety and creating an environment for success. So there are things to help take the next best action. You need lots of options and different bets to try out. And see what happens. Because you need to get feedback if that didn’t quite work. And you need to try something else.
Frictionless Developer Experience and Serverless First Mindset
With clarity of purpose, you will have a value proposition. There are two things to consider: a frictionless developer experience, so your engineers can create value very quickly. And a serverless first mindset, how you decide what choices you make. Let’s try to define that.
A serverless first mindset is selecting a serverless option first, when you review services and techniques to use in the cloud. We don’t just mean Lambda. You use a managed service or something that you can rent. And you don’t build something from scratch. You know that you need a capability and you go out to see where you can rent that capability. And if that capability is not good enough, you’ll fall back to using a service.
There is a fallback mechanism. For compute, it’s Lambda, Fargate, Kubernetes, EC2 and going easy to back down the stack. You need to start with the serverless option first. A lot of people think it’s a maturity cycle so they start at the bottom. Let’s build it and work our way up to serverless. But it should start with serverless and working your way back to a fallback mechanism. That mindset runs across from storage to a whole bunch of different things. But in a nutshell, you should be renting all services in a managed service or serverless style. It’s not common place yet. But it’s something we’ve had great success with.
Serverless First but not Serverless Only
In my experience, once you get set up with serverless and you get your proficiencies and the teams into it. You find that you can do the majority of use cases leveraging serverless building blocks. And sometimes you will replace serverless building blocks with something a wee bit more dedicated. If you are scaling up or you want something with dedicated throughput for performance reasons. We’re serverless first, but not serverless only. But you get going, and you get rapid feedback to learn and evolve.
The team can control more capabilities. So they’re not dependent on other teams for compute, hardware or networking. They can do a lot of these things. That grows their autonomy to try things more easily. There are less coordination and handoffs to get an environment set up to experiment. So they can do those next best actions more easily. They have a lot more under their own control. So feedback loops are tighter and faster. You can try out more things.
It’s trusting your cloud provider platform to have the capability to do something. And just use it.
Fast feedback by getting business value into customers hands
We’ve all seen teams that have a problem to solve go off and write a framework. They could spend three months on it. And another team will drop it into their service, and they find out by lunchtime if it works or not. Some teams lose sight of business value and go down a rabbit hole. And never come up again.
Teams with clarity of purpose, an environment for success and follow a serverless first approach can have an idea in the morning, and a fully working version of it in the hands of customers by the afternoon. It’s speed that we’re talking about, when you have these things lined up properly.
Teams are too fast for go to market. It’s the organisational constraints slowing them down. It’s no longer the fact that it’s too long to build. So that’s the wee bit on why it’s important. Next best action implies responsiveness and speed. It’s not about how quickly you type code. It’s a time to value. How quickly you can get value in the hands of customers to see if it works.
Having a frictionless developer experience is key for next best action. Can you remove impediments to fast flow that your developers face? And can you remove manual handoffs to make sure there’s a golden path to production for teams. To get value in the hands of customers.
Early next best actions for organisations should be around to making sure the pathway to production is smooth and compelling for developers. And that developer experience is world class. Because that speeds up all the other things we’re talking about. Around doing experiments and taking the other next best actions.
Serverless first does not mean less technical
It’s important to qualify that it take time for teams to get up to levels of maturity and expertise. Going serverless first is not less technical than doing down a traditional route with traditional methods of software architecture. We get into that in the next phase which is long term value. It’s difficult. But once you get up and going it’s phenomenally powerful for the organisation.
When you speak to new teams, they want to know how to start. Mapping your solution or stack is a great way to engage a team. You wardley map out with your customer/user of your software as the anchor. And you start mapping out the software components. You could look at how you deploy your software.
Often with a traditional team there are lots of components in the custom space. And you draw the map out without saying anything. But you ask about what slows down the team? And the team always points at the stuff in custom! So how do we move that across? And the team could answer that it’s too complicated and we can’t rewrite it. We’ve seen that scenario many times.
It’s a phenomenally good technique for discovering where the opportunities lie. Where are the components you can experiment with to move towards a more serverless first approach. You can look at the value chain and pick out the component to have a chat about. And let’s see if we can get you off this custom built thing and onto managed servers.
Code is a liability and not a Next Best Action
You also need to review the value chain for skills, investment, training, tools, servers and runtimes. You see how much time is spent on the operational side and non serverless value streams. And if you sit with a business person and have s conversation you can make a good case for switching to an efficient serverless first approach.
I think we say this a lot. But code is a liability. By mapping out your tech stack and adopting a serverless first approach you can tackle those code liabilities. So you’re not going to be hit by old systems that have been left to decay over time. And when you need to make rapid changes you can’t respond because you haven’t paid down your code liability. Mapping your stack and embracing serverless helps to minimise code liabilities and get you on the right path.
Don’t get stuck in a framework mentality
What happens if we don’t do this? We call it the framework mentality. Someone decides they’re going to write a framework and they can do it over the weekend. And that becomes the foundation for the next big project. You get version one into production and everyone’s really happy. This developer is a rockstar, because they have rocked out a framework.
But a year later, that framework is the very thing that’s slowing down the project. And no one can understand why we did this thing in the first place. So if your next best action is let’s write a framework, it’s not the right idea. Sometimes quick fixes in your first release in code will absolutely slow you down in future releases.
Framework fixation. Since we’ve moved the majority of our teams and engagements over to serverless first it’s helped us become liberal and creative with architectural design. Architectural creativity is thinking of new ways to solve different problems. You break out of the mould where you have been thinking in a constrained ways. And where you have been working to organisational patterns that have been very constricting. If you don’t do it, you are limited in you’re thinking and your possibilities.
Frameworks were big in the ’90s. I’ve been through this with many companies. Frameworks constrain teams, and lock them in.
Use AWS Building Blocks
That’s one of the reasons why AWS is so successful. Because they don’t have a framework. They have atomic services that you call. They are building blocks. And they don’t lock you in with a framework. Even popular frameworks like Spring is becoming more component based. That whole overarching framework idea does slow stuff down. We’re now at a time where you can use your provider for an atomic service or capability. And just use that and don’t worry about what’s behind it. It’s like the domain driven stuff.
They’re enabling constraints, rather than constraints that slow you down. If your next best actions are always around patching, pgrading, hardening or getting ready for scale, you’re not delivering business value. You need to adopt a serverless first mindset and approach so that your cloud provider is basically your platform team. Who are constantly upgrading, making performance improvements and making things more secure. And you’re getting all that for dollars.
You’re focusing your time on differentiated stuff. On delivering value, outcomes and impact. If your next actions are always around hardening, patching and securing, you need to think about what you can do to minimise that in the future?
If your next best action is to fix the infrastructure and you’re not an infrastructure company, then you’ve done something wrong, it needs to be something about your own business value proposition.
That’s the craic! Have a look at the blog on TheServerlessEdge.com. Follow us on Twitter @ServerlessEdge. And check us out on YouTube and Medium. Thanks very much.
Transcribed by https://otter.ai