Next Best Action – Phase 3 of the Value Flywheel

We are reviewing our book ‘The Value Flywheel Effect’ and discussing the different phases of the Value Flywheel Effect. The first value flywheel phase is Clarity of Purpose; then we have Challenge, Next Best Action, and Long Term Value. Today we’re talking about Next Best Action.

Next Best Action focuses on Business Value

When you boil it down, you prepare with your Northstar, Clarity of Purpose, and understanding of your landscape. How do you start? What is the next best thing you can do? What is the simplest thing to start today to improve your lot and remove inertia barriers? There’s no hiding in the book that we prefer serverless and serverless first thinking. Conceptually, you must focus your ‘next best action’ on business value. Don’t focus on building a large platform or spend the next six months organizing 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 you’re doing well. And you will only get feedback if you do something! You won’t see your hypotheses proving correct if you don’t try stuff. It takes courage.

Our last article discussed psychological safety and creating an environment for success, which will also help you 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 doesn’t 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. Consider a frictionless developer experience, so your engineers can create value. The serverless first mindset is how you decide on choices. Let’s define that.

A serverless first mindset is selecting a serverless option when reviewing 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 back down the stack. You need to start with the serverless option first. Many 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 work 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 rent all services in a ‘managed service’ or serverless style. It’s not commonplace yet. But it’s something we’ve had great success with.

Serverless First but not Serverless Only

Once you get set up with serverless, you get your proficiencies and the teams into it. You can do the majority of use cases leveraging serverless building blocks. And sometimes, you replace serverless building blocks with something more dedicated. Suppose you are scaling up or 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 fewer coordination and handoffs to set up an experiment environment. So they can do those ‘next best actions’ more quickly. They have a lot more under their 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 with problems 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. 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 following 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. We’re talking about the speed when you have these things lined up correctly.

Teams need to be faster to go to market. It’s the organizational constraints slowing them down. It’s no longer the fact that it’s too long to build. That’s the wee bit on why it’s essential. The ‘next best action’ implies responsiveness and speed. It’s about something other than how quickly you type code. It’s a time to value. How quickly can you get value in customers’ hands to see if it works?

A frictionless developer experience is critical for the ‘next best action.’ Can you remove impediments to the fast flow that your developers face? And can you remove manual handoffs to ensure a golden path to production for teams and get value into customers’ hands?

Early next best actions for organizations should ensure 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 discussing around doing experiments and taking the  ‘next best actions.’

Serverless first does not equal less technical.

It’s important to qualify that it takes time for teams to get up to levels of maturity and expertise. Going serverless first is no less technical than going down a traditional route with traditional software architecture methods. 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 potent for the organization.

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 the 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 many 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 perfect technique for discovering where the opportunities lie. Where can you experiment with the components to move towards a more serverless first approach? You can look at the value chain and pick the component to chat about. 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 must review the value chain to identify skills, investment, training, tools, servers, and runtimes gaps. You will identify time spent inefficiently 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.

We say this a lot. But code is a liability. You can tackle those code liabilities by mapping out your tech stack and adopting a serverless first approach. So you won’t be hit by old systems left to decay over time. And when you need to make rapid changes, you can only respond if you have paid down your code liability. Mapping your stack and embracing serverless helps to minimize code liabilities and get you on the right path.

Stay away from a framework mentality.

What happens if we don’t do this? We call it the framework mentality. Someone decides they will write a framework and 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 pleased. 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 we are still trying to 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 code release will slow you down in future releases.

Framework fixation. Since we’ve moved most 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 mold where you have been thinking constrainedly. And where you have been working to organizational patterns that have been very constricting. If you do it, you are allowed in your thinking and possibilities. Frameworks were prominent 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 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. You’re not delivering business value if your ‘next best actions’ are always around patching, upgrading, hardening, or getting ready for scale. You need to adopt a serverless first mindset and approach so your cloud provider is your platform team. Who is constantly upgrading, improving performance, and making things more secure? And you’re getting all that for dollars.

You’re focusing on differentiated stuff and delivering value, outcomes, and impact. If your ‘next actions’ are always around hardening, patching, and securing, you need to consider minimizing that in the future.

If your ‘next best action’ is fixing the infrastructure and you’re not an infrastructure company, you’ve done something wrong. It needs to be something about your 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.