Long Term Value – Phase 4 of the Value Flywheel

Our previous articles are about the value flywheel effect. We’ve discussed three Clarity of Purpose, Challenge, and Next Best Action phases. In this article, we talk about phase four, Long Term Value. 

Long-term value is about keeping the flywheel momentum going. How do you keep progressing and focus on the next best thing or action? We look at the ways to do that. We discuss the importance of being well-architected to ensure that what you are building is set up for the future. Ten years or even two months down the line, you don’t want to go back to tweak, revisit or invest time in ops.

Long Term Value is about Discipline

Long-terms value is about discipline and investment in engineering excellence. And it means delivering value sustainably for the medium to long term. You must invested in well-architected frameworks and pay down your technical debt to get long-term value. Build in quality or architect appropriately to provide a sustainable solution and deliver long-term value. You have to have the rigor of discipline. And you can’t decide to do it at the end. You have to bake it in.

Architecture is a continuous practice

The big thing to grasp is architecture as a continuous practice. We talk about the well-architected framework from AWS, which comprises six pillars. If you bake these things in continuously and always look at them, there’s a considerable amount of value. Architecture used to be a weird thing that no one understood. It’s pretty straightforward. The pillars are security, cost optimization, operational excellence, reliability, performance, and sustainability. The new pillar is sustainability which means you’ve low carbon in your workload. SCORPS is the acronym we’ve been using. There’s a lot of goodness in those six simple pillars. 

You’ll hit the wall if you don’t invest in long-term value and a well-architected framework. You need to do it sustainably or you do not pay down tech debt. You need to build resilient, scalable, performant, and cost-effective things or it catches up with you. And you crash, you stop, and you can’t deliver any value anymore.

Make space to Innovate, Leverage, and Commoditize.

You create space for innovation, with the ILC cycle: Innovate, Leverage, and Commoditize relating to turning the flywheel. You build to leverage ideas quickly. If it’s well architected, there’s more chance you can commoditize and move on to the next cycle. You’re effectively building quality. You get ready for your next turn of the flywheel. You are free to look for the next clarity of purpose.

Investing in Long Term Value keeps you from firefighting

You’re solving issues, trying to see why things don’t work, or resolving customer issues. You have acquired the capacity for impactful, meaningful, and differentiating work. And not just ‘run work’ or busy work to keep the lights on. You’re always going to have unknown unknowns. Some things will happen that will take you by surprise. Some of the things we talk about are known unknowns. Something will happen if you don’t look after reliability, performance, and security. That’s just a fact. You are better to squirrel away early and focus on the stuff you have yet to discover.

One of the most essential pillars we love is Operational Excellence. Do you have observability? And do you know where your value is coming from? Or where is your next round of value coming from? Good observability helps to point you in the right direction of well-architected improvements that keep the flywheel turning.

The challenge is getting teams on board.

We have a ‘Wee Jimmy’ story with a lesson: Wee Jimmy built a fantastic system and knows how it works. Wee Jimmy is a genius and does not need to document anything. He leaves the company, and no one knows how it works?

Your challenge is getting teams to embed long-term value, getting them into the right cadence, and adopting it to free up architecture. And it gives teams more autonomy. It fuels the overarching pyramid. Looking at broader cloud controls and constraints and building a functional, productive organization drives all that. You don’t have to have an architect on every squad. You can scale that way: efficiency, throughput, and the longer term.

Make your team’s lives infinitely better.

It democratizes a lot of architectural concerns to enable teams to think about them in a productive, practical, and enjoyable way. Teams enjoy and embrace it and they see value in the improvements. They are not chasing their tail and trying to firefight issue after issue. If you do this right, you enable and empower teams to deliver well-architected solutions that deliver the long-term value you’re looking for. If every team needs an architect, who will draw the picture? Engineers need to draw the pictures themselves. That’s just enough design.

What happens if you ignore Long Term Value?

You see teams in a false economy where they finish their build quickly. Things start to go wrong. And they build up technical debt very quickly. They end up firefighting, and everything slows down. It’s a perfect velocity thing. Is there anything else you can think of that happens if you don’t think about this?

Your business, execs, and critical stakeholders wonder why I am no longer getting value from meetings. Where’s the differentiating capability? And where’s my next feature or capability that can differentiate us in the marketplace? Why are the teams not delivering this month? You’ll have a lot of noise from the execs wondering why it is not working anymore.

Follow the growth versus run numbers.

In most modernizations, you’ll deal with a part of the org that needs to leverage well-architected. You may have heritage-style apps. And they are all good at what they do. If you look at the run/grow type numbers across that part of the organization versus a well-architected area of the organization or application. Growth on the well-architected/serverless first side is much higher. On the older side, the run is to compete for growth capacity. You need to delegate to the cloud provider. And adopt well-architected practices to always focus on value. And not on runs or paths that don’t add value. If you’re not doing that, you’re going to struggle. Your growth is going to struggle against run costs constantly.

Ignoring Long Term Value leads to System Rewrites.

Teams know the business. They are part of the business. Suppose they don’t invest in long-term value. They will spend their cycles doing things that could be more innovative and creative. And aren’t going to help business growth. You’re going to be doing stuff to keep the lights on and you will miss out on innovation and value add.

Teams, who think about long terms value free up capacity and cycles to think about the future. And they have time to think about what’s next. What are the opportunities on the horizon?
The problem becomes the dreaded rewrite a couple of years in. And you realize that this big ball of mud needs somebody to take a sledgehammer. You approach your stakeholders to do a next-generation version. It’s going to be brilliant with all of the same functionality and 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 challenging conversation. You should give an honest answer which is that we didn’t bother doing architecture. And we have to build the system again. That’s not a good place to be.

Long Term Value is about turning the value flywheel faster.

Long-term value ties in with the value flywheel. Clarity of purpose, a suitable environment for challenge, psychological safety, and you understand what the ‘next best action’ should be. You see key input metrics to improve as the flywheel turns. Long-term value is knowing how to turn the flywheel faster? And delivering value quickly to users and customers. Teams see software appreciating over time. Software that depreciates needs patching, upgrading, and dealing with issues.

Long Term Value is about minimizing liabilities and offloading responsibility to your Cloud Provider.

The term we use is ‘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. This phase of the value flywheel is about minimizing 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. All of those things are at play in this phase of the value flywheel.

Good architects encourage teams to build for long-term value. It’s a software engineering thing. Teams need to build better systems, think about long-term value and not just about the delivery date at the end of the month.

That’s the craic. And that’s the value flywheel effect and all four phases: Clarity of Purpose, Challenge, Next Best Action, and Long Term Value. Our book is on sale. Take a look at the blog on TheServerlessEdge.com. Follow us on Twitter @ServerlessEdge, YouTube, and the Serverless Craic podcast.