Map Camp is a series of workshops and talks about Wardley mapping techniques. It’s a community event driven by actual practitioners.
Our Map Camp talk was ‘Adaptation – the Value Flywheel’. We look at Wardley Mapping as a concept. We also apply the concept to the Value Flywheel, which shows Wardley Mapping working in the practical implementation of ongoing technical strategy.
Wardley mapping at Map Camp
Simon Wardley and the Wardley mapping community have an excellent annual event called Map Camp. It is always an exciting day, with lots of good feedback on social media. We were part of the resilience track, and the title of our session was ‘Adaptation’. I decided to live map our Adaptation using the Value Flywheel idea from our book.
Maps tend to be on the walls when you are in the office. People get around a whiteboard and discuss problems like position movement and placement. And then, you photograph the map on the whiteboard. You take the photograph and then digitise it.
We have modernised our map sessions with the available tools. The fact that we’re working from home more means that collaboration sessions are digital. There are many online tools available: Lucid Chart, Online Wardley Map, and VS code.
Live Wardley mapping
Adrian Cockroft was the first person I saw live mapping at Map Camp. It’s becoming more popular, and many people are having an ‘aha’ moment. One challenge we had in the early days was a tendency to go too formal too quickly. But now we know how to use the tool properly and keep the conversation going.
Mapping Tools
The mapping tool we used in our talk is on X @mapsascode. It’s a language for making maps and is the same engine behind Online Wardley maps. Damon Skelhorn wrote it and made it available on GitHub. There’s a nice plugin for Visual Studio Code that works really well.
But if you don’t want to do that and not everyone wants to install an ‘ide’, you can go to onlinewardleymaps.com and play around. Initially, we thought it was too formal, but now I think it works well. Plus, you can give someone the code to play with themselves, which is good.
We used it well in this talk by uncommenting as we went. We used it to illustrate the narrative and our content.
Mapping the Evolution of Cloud up to Serverless
It’s worth looking at the map used for Wardley Mapping at Map Camp. It is one of Simon (Wardley’s) maps. Simon has been using this map for a long time to discuss the evolution of the Cloud up to Serverless. It’s at least five years old.
For anyone who doesn’t know about Wardley Maps, the anchor at the top represents the user. Then you have these four phases: Genesis, which is brand new; Custom Built, where you can build something but aren’t quite sure how to replicate it; Product, where you are getting good at building it, and it’s ready for prime time; and Commodity, which is just the price of doing business.
Wardley Map Inertia Points
Simon talks about Compute evolving to the Cloud and the propensity of DevOps to move to the right, along with good architecture practice, operating systems, and run time. He identifies that run time is an inertia point when moving to Serverless, and a second inertia point is going to the Cloud.
Once serverless happens, it opens up something called emerging practice, which opens up new needs or value for the user. Often, the user only knows that they need this once it appears. This map has a little pattern that people have used several times. When Simon draws this map, he often will change what this need is. He puts in a couple of different needs here. But it’s about the pattern and the fact that Serverless unlocks it.
Serverless and emerging practices
We have seen this unlocking happen. We’ve been able to navigate through the same inertia barrier in the work we’ve been doing with Serverless, and we have witnessed it opening up emerging practices. It has improved our time to value and our speed. It has allowed us to think differently about what is a new emerging value and what is a new need. We can address that as an organisation, business, or individual. So, we have effectively lived this map over the past six or seven years.
We work with many good engineers stuck at this inertia barrier. People can spend their entire careers stuck on that inertia barrier and still have a successful career. But you spend an awful lot of time trying to get over or burst through that wall, and sometimes it doesn’t happen.
The title of this was ‘Serverless 2030’. These things take time because there’s a lot of inertia to change. There are lots of traditional practices and techniques, and there’s lots of value in them as well. So it’s not like they can go serverless overnight. There’s an evolutionary journey that people, teams, and organisations need to go on to grasp the value in the top left corner of the map.
‘Adaptation: The Serverless Edge and The Value Flywheel’
The reason this is interesting and valuable is because this is a higher-level technical strategy. Your technical strategy isn’t, ‘Let’s move to Lambda’. It’s up the value chain looking at how to reduce operational load, move faster and unlock new needs. So, you need a higher lens that is closer to your business.
That brings us a nice snapshot of the map I used for Map Camp. The track title was ‘Adaptation: The Serverless Edge and The Value Flywheel‘. The video itself is worth watching if you have the time.
Innovate, Leverage, Commoditize Cycle
We base our ideas on innovation, leverage, and commoditisation cycles. Companies often innovate and leverage value but never get to commoditisation, which leaves you locked. That’s when you get into technical debt. We can’t go fast. They become prisoners of their past success.
We anchored our map with a senior executive, like a CEO. This is a pattern we have seen many times. There’s a layer across the top here, which is ‘clarity of purpose’. We have things here like operational efficiency, time to value, and business growth. We also need around cost management, digital modernization, customer needs, and even secure rapid experimentation. These might be at the top of the CEO’s mind.
This layer here belongs to the IT Department or Technology Leaders. If we need those things, we need Self Service Cloud to build quicker. We need better data and we need better security. These are things that you need to do in direct response.
Problem Prevention Mindset
But really, we’ve experienced another layer: your problem-prevention mindset. Things like well-architected engineering excellence, standardisation, and sustainability are the real things that no one asks for, but they actually enable a lot.
For example, commoditisation can affect your long-term value. Towards the bottom of the map, Wardley mapping is the enabler for all of this. Or the idea of challenging to make sure there’s movement. And that is the concept of the Value Flywheel. There’s clarity of purpose first. You challenge through your map, figure out your ‘next best action’ and leverage, and then move things over into long-term value to create space for further innovation at the top of the map.
Having an environment for success is very important. Psychological safety is a big thing that enables this to happen. It’s very hard to challenge if you’re going to get shouted out every time you raise a question. That’s why the environment for success is one of the key elements that underpins the entire Value Flywheel.
Equilibrium of expectation
The commoditisation piece is an interesting one to discuss. We always think of this one as a scaling thing. As you move with speed and produce more throughput, you carry that over the longer term.
But then you’ve got to think about the fact that teams move, and your developers move, and leaders move. But as they move, you should be able to go from one workload to another. And it should be reasonably consistent. You should only find something in a good state where you’re worried about making a change. Or something’s brittle, and you are left wondering about being able to assess the impact of what you are doing.
When you get everybody on this on a level playing field, there’s an equilibrium of expectations in terms of standards. We talk a lot about well-architected. And you could argue that it’s a commoditized set of best practices that everybody can align to. If you get everybody working to that standard, you should be able to move at speed and create the foundation for things like SRE, etc.
The role of a Technical Lead
The commoditise box is attractive because we need help to think of a time when we didn’t have some mad idea of bringing in something like threat modelling, whole team testing or some cloud strategy, like sustainability. As a technical leader, it is your responsibility to do that.
But people react by saying: ‘Why are we doing this? It’s not within my objectives!’ And we show them that we need to do this because it will make everything else easier. The hard battle is getting something like this kicked off. As a Technical Lead, sometimes you must plant the flag and say, ‘No, we’re doing this!’. But then, in a while, people start to see the benefits, as it lifts a lot of cognitive load.
As a Technical Lead, it’s your job to assess when the organisation is ready for change. Pushing something when people need more time to be prepared can be difficult. The trick is knowing when to push those things and connecting them to the executive vision.
Architect Elevator Approach
We love Gregor Hohpe’s ‘Architect Elevator’ approach. We have a lot of scar tissue from articulating what we’re trying to do for problem prevention and long-term value. It’s about selling it to the correct levels in the right way and getting the buy-in from the teams on the ground. We also got the pitch right for the executives and tried to do that across all the different floors of the elevator.
But it effectively drags much of this stuff over to ‘commoditised long-term value’, freeing up that space for your next thing, innovation, and thinking. You start to move those things to the right, e.g., cloud self-service. Serverless first brings a lot of these things across. You free up space to enable capability and whatever’s next.
Serverless First Mindset
Serverless First uses a serverless first mindset to move things quickly from the ‘next best action’ into the long-term value zone. There are some older architectures where you could take a year to move stuff. But you can do it faster with serverless.
Many people still think serverless is lambda, which is a terrible name. But there’s a phrase needed to describe a modern way of building software in the Cloud. I don’t think it’s been coined yet, but it really lends itself well to that problem-prevention mindset.
The importance of enabling capabilities and building blocks
The enabling capabilities and building blocks allow you to go after the next thing, and that value is critical. And you can get by for a while without doing that. But sooner or later, it’ll catch up. And it’ll catch up in a big way. It could be a security issue, a cost overrun, a quality issue or a slowdown in your time to value.
The three big ones you see in the news are significant security breaches, massive costs, or reliability issues, i.e., something falling over. And those rarely happen in isolation. They’re usually a knock-on effect because people haven’t drawn out this type of strategy here and given engineers room to practice well-architected techniques.
Observability and visibility
The significant gains from evolving from product to commodity are observability and visibility. How many times have third-party consultants come in to quantify your technical debt and recommend investing in an IT resource to move platform when you know the correct thing to do is tie technical debt or legacy to actual value?
If a system is down for half an hour a month, is it worth investing time to correct these issues? Or should you invest that time in modernising and moving it and bringing it in line with its future state to gain more capability?
You need to start quantifying the system’s value, ROI, performance, and how long it takes to make a change. Do you have people who can change that system? And factor in developer experience and happiness.
Serverless isn’t easier, but it is better.
As AWS Hero Gillian McCann says, “Serverless isn’t easier, but it’s better.” It’s not easy to do this. It’s hard to do all this stuff. But it’s a better way of doing it. It’s sustainable, rewarding, and more impactful.
We have written a blog post on ‘finding your why‘. A lot of our teams didn’t know how the thing that they were doing was going to impact the bottom line, the business or their team. They were just working on tickets!
If you don’t understand what your system is doing and how it’s actually adding value, you may come up with things like: ‘We need to move from spring to react and go single page apps into microservices’.
Understand your purpose
But if you need help understanding why, you must know whether that’s a good decision. Should your time be spent elsewhere? Is there a quicker path to what you are trying to do? Serverless certainly gives you a platform for operating that way and not making those blind decisions.
When we started mapping our teams and tech stack, the first question we asked was, ‘What’s your purpose?’ Why does this team exist? Do you know? Do you care? I was always fascinated to see the various answers from a team of 10 or 12 people on why they thought that team existed.
Serverless Craic from The Serverless Edge
Check out our book, The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
8 thoughts on “Adaptation, Wardley Mapping and the Value Flywheel”