Serverless Craic Ep 29 What is Long Term Value - Phase 4 of Flywheel?

Serverless Craic from The Serverless Edge

What is Long Term Value?

We've spent the last couple of episodes talking about the value flywheel effect and the value flywheel itself. There are four phases: Clarity of Purpose, Challenge, Next Best Action and Long Term Value. We've been talking through each of these phases in detail. And today, we're going to talk about phase four, which is Long Term Value.

So the simple question is, what is long term value? Long term value means continuing to deliver value for the medium to long term, because you've invested in a sustainable way of working. You have invested in well architected and paid down your technical debt to get long term value. And you're not going to hit a wall in the short term, because you've not built in quality or architected appropriately or built a sustainable solution.

As you go forward make sure that all of your systems are built to deliver long term value. You have got to have that rigour of discipline. And you have got to do it continuously. You can't decide to just do it at the end. It's got to be baked in. If you don't invest in long term value and the well architected framework, you'll hit the wall. You might go fast for a quarter or two, or a sprint or two. But sooner or later, it's going to catch up to you. You may be going fast and delivering value, but you're not doing it on a sustainable way. You're not paying down those debts. And you're not building things that are resilient, scalable, performant and cost effective.

You may go fast for a few months or even a few years. But eventually it catches up with you. And then you crash, you stop and you can't deliver any value anymore. If you invest in this, your team are thinking about delivering differentiating value instead of firefighting. You're solving issues and trying to see why things don't work or resolving customer issues. Because you've invested in this you have capacity for impactful, meaningful and differentiating work. And not just run work or busy work to keep the lights on.

The challenge is getting teams embedded into it. And getting them into the right cadence and adopting it. But when that happens it frees up architecture. And it give teams more autonomy. It fuels the overarching pyramid. When you're looking at broader cloud controls and constraints. And building a more functional, productive organisation, it drives all of that. You don't have to have an architect on every squad. You can scale in that way. It's all about efficiency, throughput and looking after the longer term.

What happens if we don't do it? You see teams in a false economy where they get their first or second build done quickly. But then things start going wrong. And you build up technical debt very quickly. Things start to go wrong. You end up firefighting. And it really slows down. It's the perfect velocity thing. You start off quite fast. But it starts to slow down rapidly as things start to creek.

Is there anything else you can think of that happens if you don't think about this? Your business, execs and key stakeholders start to wonder why am I not getting value out of meetings anymore? Where's the next differentiating capability? And where's my next feature? Or my next capability that can differentiate us in the marketplace? I've got the same teams and they were good last month. Why are they not delivering this month. Or they were good last year? Why are they not delivering this year. You'll have a lot of noise from the execs wondering why is it not working anymore?

The problem becomes the dreaded rewrite a couple of years in. And realising that this big ball of mud just needs somebody to take a sledgehammer to it. You turn around and talk to your stakeholders because you are going to want to do next generation version of this. It's going to be brilliant. With all of the same functionality. But it'll be better. And the response is: 'why would I pay you to build it again? You built this five years ago, why are we building it again?'. That's a very difficult conversation. And the real answer is we didn't bother doing architecture, so we have to build it again. That's not a good place to be.

A team that's leveraging and operating the flywheel will see their software appreciating in value over time. As opposed to depreciate. If you're not thinking about long term value your system is always depreciating. You are going to have to invest in patching, upgrading and dealing with issues. The terms we use are 'code is a liability' and 'the system is the asset'. You need your teams focused on the system delivering the value. And removing as many code liabilities as they can.

And this phase of the value flywheel is about minimising liabilities and offloading more responsibility to the cloud provider. Or how can we leverage managed services and SAS providers. To remove custom build and evolve into a commodity. So all of those things are at play in this phase of the value flywheel.

Serverless Craic from The Serverless Edge

theserverlessedge.com
@ServerlessEdge