Free AI web copilot to create summaries, insights and extended knowledge, download it at here

Abstract

me of the effects of altitude were well known, if not fully understood. The technical capability should be there, but is there even a route up it?At this point, there weren’t even any maps of the area, and the only possible route to the mountain would mean going through Tibet because the Nepal side of the mountain was closed to foreign visitors. The first challenge was reconnaissance. Or seeking to understand the problem space better. The measure of success was not “can we climb Everest?” It was “can we find a route to attempt a climb?”In 1921, an expedition set out to answer this question. They were also set the stretchiest of stretch goals to climb it if possible. In the end, they identified a route through the Rongbuk glacier and established Advanced Base Camp at 5300m and Camp II at 6100m. They also learned how strong the winds could become and failed to find a spot on the North Col to camp higher up to go further.The first milestone was a success, and they learned enough to put together a better plan for the following year, and many of the same people returned in 1922. This time, they were bringing supplemental oxygen for the first time. The tanks were heavy and leaky, and the climbers didn’t like them, but they also recognised the difficulties of being at altitude, so they wanted to explore their feasibility.It’s worth noting that altitude is one of the biggest challenges here (along with extreme weather). <a href="https://www.youtube.com/watch?v=rYr9xAK-iYw">I’ve been to Base Camp</a> and vividly remember getting out of breath tying my shoelaces or talking. Getting into a sleeping bag was a multiple-stage activity with rest breaks to regain my breath.This time, they could use the camps and identify and set up camps III and IV. From here, they climbed to 8324m, a world record — albeit over 500m short of the summit. It was during this trip they also learned that the oxygen bottles, while bulky, allowed them to go further than before. The team couldn’t return the next year but returned in 1924 when Mallory and Irvine were lost attempting to make the summit.It wasn’t until the 1950s that a different route was chosen. This time from Eric Shipton’s reconnaissance from the Nepal side, which was now open. Shipton located a route up the Khumbu glacier that he believed was possible, and he and his climbing team explored this. They also learned the valuable lesson that climbing in summer was too dangerous due to the risk of avalanches as the snow melted. This laid the groundwork for Hillary and Tenzing’s first summit in 1953.Turning a vision into reality is a lot like climbing Everest.<ul><li>You have to explore the problem. You may start with a set of technical skills, but you will also have a set of hypotheses, assumptions, and unknowns. Early milestones are biased towards exploring these while still generating business value. During this time, you’ll learn things you didn’t expect.</li><li>You need a rough plan on how you’re going to do it. Or, roadmap. This is the shape of what you’re trying to do. Organised by the problems you know that you need to solve. For example, landing a human on the surface of Mars is a very different roadmap from landing a human on the Sun. There are commonalities, but we’re much closer to solving the Martian problems.</li><li>You need a detailed plan for the next milestone in your roadmap. The goal of your next milestone is to provide value. This value will be some combination of learning and direct outcomes. You will also learn things you didn’t expect, which will (re)shape future milestones. Your plan is the logistics of how this happens.</li><li>After each milestone, you should revisit your roadmap and apply the lessons learned. This is why you don’t invest too much effort in future roadmap items. The more effort you invest, the greater your inertia towards applying what you’ve learned and learning from the past.</li></ul>Just like climbing — you establish a camp and then explore that camp to find the next camp. Getting closer and closer to your goal all the time. Sometimes, you have to backtrack and find another route. At each point, you are learning how to apply your technical skills to the mountain you are attempting to climb. Every mountain is different.When attempting to turn a vision into rea

Options

lity, particularly an aspirational vision, you need to know where you’re going (your vision) and the things in your way (your roadmap). You also need to be able to focus on establishing the next camp (execution against your plan). Where teams struggle is:<ul><li>Too much focus on roadmaps and planning. By looking too far into the future, you build an unrealistic plan with no credibility with the people tasked with executing it. You spend time on the planning side that could be used to make progress. I’ve seen teams spend six months putting together a roadmap. Teams produce Gantt charts so complex that no one can track them. The process is in service of solving a problem. It should not become a problem.</li><li>Failure to turn an aspirational goal into a concrete milestone. The next milestone needs to be unambiguously concrete. When you’ve achieved it, it should not be a matter of opinion but something you can demonstrate.</li><li>Focusing on execution at the expense of exploration. Teams that defer the key problems in their roadmap are in store for nasty surprises. Part of delivering on a vision is learning how to deliver the vision. Teams in the “get shit done” mindset don’t stop thinking about what they’re doing in the wider context. There will be times when you need to execute, and it is a powerful and necessary skill. But, remember — you couldn’t land a human on the Moon with Agile.</li><li>Exploration for the sake of exploration. The contra-problem is teams that want to know everything before they commit to a course of action. The purpose of exploration is to learn in the service of achieving an outcome. If you don’t achieve the outcome, then it’s not worthwhile. Your exploration has to be in service of something that brings value to your business. If you’re not delivering value, people will start questioning why they’re funding you. The first Everest expeditions showed benefit by showing how the future ones could succeed. If it had just been a group of friends having fun in the snow, they’d never have received future funding.</li><li>Failure to apply lessons of previous milestones. Every time we reach a milestone, we’ve learned a lot, whether we’ve realised it or not. If we cannot carry this forward, we will lose our ability to adapt. Stopping execution and coming up for air ensures our efforts remain relevant. New tools and techniques might now exist for what we’re doing. Our roadmap may need to be revisited. Our understanding of the problem domain will have advanced. This is why I have a deep suspicion of complex plans — the more complex the plan, the harder it is to adapt it as we learn.</li></ul>No two projects have the same requirements for balancing exploration and execution. In fact, any single project will see the balance between the two shifts over time. For example, a self-driving car company should expect to see a very different bias towards this than a travel company. This is one of the many reasons that attempting to measure developer productivity is unhelpful — things will naturally ebb and flow. The time I’ve spent on data analysis, prototyping, scribbling on a whiteboard, or just listening to people with more context than me has been equally important to getting things done.As a former manager, my rule of thumb is that I would expect people to be able to put together a rough roadmap for the next 18+ months with a detailed (enough) first milestone and plan to achieve it. Or to work with them and coach them how to put it together. I’d expect a roadmap to take in the order of days to create.The goal is to validate and share the shape of the problem space you’re working on. The milestone plan should be finer-grained, but planning for a single milestone should also be in the order of days. I don’t want a detailed plan for the second milestone because your first milestone will likely invalidate it. Roadmaps are a tool for unlocking a vision. The next milestone is a tool for demonstrating that we can progress the implementation of that vision.Without the first milestone, aspirational visions won’t feel tangible for teams. Put simply, being able to implement a vision is about identifying the next camp to build and then building it. Learning by doing and then using that learning to identify and build the next camp. That’s how we climb mountains, metaphorical or otherwise.</article></body>

Turning your vision into reality

How to plan and execute in a world where you don’t know everything yet

Everest Base Camp and the Khumbu Ice fall, Andy Walker (2007)

Hopefully, I’ve articulated the importance of having a clear view of what you’re trying to achieve. This is a prerequisite for being able to deliver something non-trivial alongside lots of other human beings.

However, the next stage is harder than it sounds. Today, I will write about how I think about translating vision into action. In particular, how to address the common problem of “how do I plan when I don’t know everything?” Which, it turns out, is every time you write a plan.

The trouble is that we often start with only a rough idea of what we want to do. I’ll take an example — I used to work for a company that did travel, and their vision was “become the single app for all your travel needs.” The company believed there was an opportunity in this space that would enable it to scale its business and also had an eye on things like flight search and hotel bookings in Google as a future competitor.

The first thing you should recognise about this is it’s an aspirational goal. Aspirational goals are a good thing when they can give people a framework for understanding the direction of travel. Other examples might include Google’s “organise the world’s information and make it universally accessible” or Microsoft’s “a computer on every desktop” as unifying visions, which turned out pretty well for them.

The purpose of an aspirational vision is to inspire action by generating purpose. Other examples might include the first ascent of Everest or landing a human on the Moon for the first time.

When presented with an aspirational vision, the job of leaders is to help teams translate it into something meaningful to them. Part of this process includes teaching them to do it for themselves — joining the dots is a skill you want everyone to cultivate. Some aspirational visions, like climbing Everest, have a very clear end point — others, like my travel example, are open ended. It’s impossible to cater to every travel need in a mobile app. So, when taken literally, the vision can inspire the wrong action.

Strangely enough, a model used in giving feedback can be helpful here. The model I’m talking about is the SBI model (Situation — Behaviour — Impact). In essence, what we’re looking for is the before and after picture and how to go from A to B.

Situation. Where are we today? In the case of my travel company, they want to know which travel needs they’re satisfying today and which they’re not. They’re running a business, so they want to know where their opportunity lies. Is this an optimisation problem with what they have, or will they need to create something new?
Behaviour. What are we going to do to change the situation? Otherwise known as a plan or a roadmap. The roadmap is a rough idea of which problems we need to solve in which order. At the very least, it should contain a verifiable first milestone to demonstrate we are making progress. A plan is what we’re going to do. You need a plan to get to the first milestone in your roadmap as a bare minimum.
Impact. How will I know that we’ve arrived at our destination? For open-ended aspirational goals, this can be impossible. For example, Google is never going to organise all the world’s information for both practical and ethical reasons.

Let’s take the first ascent of Everest as an example. Before the first ascent was attempted, they knew Everest was the highest mountain in the world (discovered to date) and had never been climbed before. The challenge of being first was a motivating purpose.

But before you can even start, you have to ask yourself whether it’s even possible. Nobody had ever climbed that high before, though there were plenty of people with winter mountaineering experience and techniques for climbing, and a combination of snow, ice, and rock was well known. Some of the effects of altitude were well known, if not fully understood. The technical capability should be there, but is there even a route up it?

At this point, there weren’t even any maps of the area, and the only possible route to the mountain would mean going through Tibet because the Nepal side of the mountain was closed to foreign visitors. The first challenge was reconnaissance. Or seeking to understand the problem space better. The measure of success was not “can we climb Everest?” It was “can we find a route to attempt a climb?”

In 1921, an expedition set out to answer this question. They were also set the stretchiest of stretch goals to climb it if possible. In the end, they identified a route through the Rongbuk glacier and established Advanced Base Camp at 5300m and Camp II at 6100m. They also learned how strong the winds could become and failed to find a spot on the North Col to camp higher up to go further.

The first milestone was a success, and they learned enough to put together a better plan for the following year, and many of the same people returned in 1922. This time, they were bringing supplemental oxygen for the first time. The tanks were heavy and leaky, and the climbers didn’t like them, but they also recognised the difficulties of being at altitude, so they wanted to explore their feasibility.

It’s worth noting that altitude is one of the biggest challenges here (along with extreme weather). I’ve been to Base Camp and vividly remember getting out of breath tying my shoelaces or talking. Getting into a sleeping bag was a multiple-stage activity with rest breaks to regain my breath.

This time, they could use the camps and identify and set up camps III and IV. From here, they climbed to 8324m, a world record — albeit over 500m short of the summit. It was during this trip they also learned that the oxygen bottles, while bulky, allowed them to go further than before. The team couldn’t return the next year but returned in 1924 when Mallory and Irvine were lost attempting to make the summit.

It wasn’t until the 1950s that a different route was chosen. This time from Eric Shipton’s reconnaissance from the Nepal side, which was now open. Shipton located a route up the Khumbu glacier that he believed was possible, and he and his climbing team explored this. They also learned the valuable lesson that climbing in summer was too dangerous due to the risk of avalanches as the snow melted. This laid the groundwork for Hillary and Tenzing’s first summit in 1953.

Turning a vision into reality is a lot like climbing Everest.

You have to explore the problem. You may start with a set of technical skills, but you will also have a set of hypotheses, assumptions, and unknowns. Early milestones are biased towards exploring these while still generating business value. During this time, you’ll learn things you didn’t expect.
You need a rough plan on how you’re going to do it. Or, roadmap. This is the shape of what you’re trying to do. Organised by the problems you know that you need to solve. For example, landing a human on the surface of Mars is a very different roadmap from landing a human on the Sun. There are commonalities, but we’re much closer to solving the Martian problems.
You need a detailed plan for the next milestone in your roadmap. The goal of your next milestone is to provide value. This value will be some combination of learning and direct outcomes. You will also learn things you didn’t expect, which will (re)shape future milestones. Your plan is the logistics of how this happens.
After each milestone, you should revisit your roadmap and apply the lessons learned. This is why you don’t invest too much effort in future roadmap items. The more effort you invest, the greater your inertia towards applying what you’ve learned and learning from the past.

Just like climbing — you establish a camp and then explore that camp to find the next camp. Getting closer and closer to your goal all the time. Sometimes, you have to backtrack and find another route. At each point, you are learning how to apply your technical skills to the mountain you are attempting to climb. Every mountain is different.

When attempting to turn a vision into reality, particularly an aspirational vision, you need to know where you’re going (your vision) and the things in your way (your roadmap). You also need to be able to focus on establishing the next camp (execution against your plan). Where teams struggle is:

Too much focus on roadmaps and planning. By looking too far into the future, you build an unrealistic plan with no credibility with the people tasked with executing it. You spend time on the planning side that could be used to make progress. I’ve seen teams spend six months putting together a roadmap. Teams produce Gantt charts so complex that no one can track them. The process is in service of solving a problem. It should not become a problem.
Failure to turn an aspirational goal into a concrete milestone. The next milestone needs to be unambiguously concrete. When you’ve achieved it, it should not be a matter of opinion but something you can demonstrate.
Focusing on execution at the expense of exploration. Teams that defer the key problems in their roadmap are in store for nasty surprises. Part of delivering on a vision is learning how to deliver the vision. Teams in the “get shit done” mindset don’t stop thinking about what they’re doing in the wider context. There will be times when you need to execute, and it is a powerful and necessary skill. But, remember — you couldn’t land a human on the Moon with Agile.
Exploration for the sake of exploration. The contra-problem is teams that want to know everything before they commit to a course of action. The purpose of exploration is to learn in the service of achieving an outcome. If you don’t achieve the outcome, then it’s not worthwhile. Your exploration has to be in service of something that brings value to your business. If you’re not delivering value, people will start questioning why they’re funding you. The first Everest expeditions showed benefit by showing how the future ones could succeed. If it had just been a group of friends having fun in the snow, they’d never have received future funding.
Failure to apply lessons of previous milestones. Every time we reach a milestone, we’ve learned a lot, whether we’ve realised it or not. If we cannot carry this forward, we will lose our ability to adapt. Stopping execution and coming up for air ensures our efforts remain relevant. New tools and techniques might now exist for what we’re doing. Our roadmap may need to be revisited. Our understanding of the problem domain will have advanced. This is why I have a deep suspicion of complex plans — the more complex the plan, the harder it is to adapt it as we learn.

No two projects have the same requirements for balancing exploration and execution. In fact, any single project will see the balance between the two shifts over time. For example, a self-driving car company should expect to see a very different bias towards this than a travel company. This is one of the many reasons that attempting to measure developer productivity is unhelpful — things will naturally ebb and flow. The time I’ve spent on data analysis, prototyping, scribbling on a whiteboard, or just listening to people with more context than me has been equally important to getting things done.

As a former manager, my rule of thumb is that I would expect people to be able to put together a rough roadmap for the next 18+ months with a detailed (enough) first milestone and plan to achieve it. Or to work with them and coach them how to put it together. I’d expect a roadmap to take in the order of days to create.

The goal is to validate and share the shape of the problem space you’re working on. The milestone plan should be finer-grained, but planning for a single milestone should also be in the order of days. I don’t want a detailed plan for the second milestone because your first milestone will likely invalidate it. Roadmaps are a tool for unlocking a vision. The next milestone is a tool for demonstrating that we can progress the implementation of that vision.

Without the first milestone, aspirational visions won’t feel tangible for teams. Put simply, being able to implement a vision is about identifying the next camp to build and then building it. Learning by doing and then using that learning to identify and build the next camp. That’s how we climb mountains, metaphorical or otherwise.