Episode 14

Bryon Kroger (00:05):

We've covered a lot of ground in this series from the depths of the technical stack to the cultural shifts that define a high performing organization. Now we need to talk about the leader's two most essential tools. The force that holds it all together. We need to go deeper on the leadership pillar introduced in episode four: vision and strategy. In the chaos of a large scale transformation, these are not just nice to haves. They're survival [00:00:30] tools. Without a clear vision, your organization has no direction. And without a coherent strategy, it has no path. So you'll just be wandering blind through the bureaucracy. Let's start with the vision. The first and most important job of any transformation leader is to articulate a clear, compelling, and concise vision of the future. This vision becomes your north star. It's that fixed point on the horizon that you're constantly navigating towards, no matter how turbulent [00:01:00] the sea of change becomes. And it is turbulent.

(01:04):

Now, most enterprise vision statements are terrible. They're either so vague as to be meaningless, like "we will be the world-class leader in mission excellence," or they're so prescriptive that they're not a vision at all. They're just a long list of features. A true vision answers one simple question. What will the world look like when we've succeeded? And that paints a picture of a future state that's so compelling that [00:01:30] it inspires people to undertake this difficult, difficult journey to get there. When we started Kessel Run, our vision was a future where an Air Operations Center could plan and execute the air war in hours, not days. A future where Warfighters had the software that gave them a cognitive advantage over their adversaries. That's a picture that people can see. A purpose they can rally behind. A good vision is ambitious, but it's also believable. It provides the why that fuels your entire transformation.

(02:00):

[00:02:00] The story that you tell over and over and over again in every meeting and every email, in every hallway conversation, until it becomes the shared reality of your organization. But of course, vision isn't enough. A North Star tells you where to go, but it doesn't tell you how to get there. And for that, you need a strategy. This is where we need to make a critical distinction. In the traditional enterprise, strategy is just another word for the plan. It's a detailed multi-year Gantt chart that [00:02:30] sequences every activity from start to finish. It's built on a fatal assumption that the environment is predictable and the plan can survive contact with reality, and it never does. In Mission O/S, strategy is not a plan. It's a living framework for making decisions. It gives you why of movement. Why go this way, not that way? So think of it more as a set of guiding principles and high level bets about how we intend to move towards our vision.

(03:00):

[00:03:00] But it's a living thing, a hypothesis that is constantly tested and adapted by the results of our execution. Our strategy informs our execution, but then our execution informs our strategy. It's a continuous loop. So how do we create one? How do we take a big ambitious vision and break it down into a coherent, actionable strategy? We like to use a set of powerful visualization tools, two additional mapping tools. [00:03:30] The first tool is called Wardley Mapping. A Wardley Map is a way of mapping the competitive landscape of your mission or business. Helps you understand the value chain from the end user all the way down to the commodity components. And it maps the evolution of each component over time. It's a powerful tool for understanding the why of strategic movement. For example, a Wardley Map helps you see which parts of your system are commodities that you should be renting from, say, a cloud service provider, [00:04:00] and which parts are custom-built secret sauce where you need to invest your best talent.

(04:05):

It shows you where you can attack an adversary's value chain or where you're vulnerable to attack. And it turns strategy from a game of guesswork into a game of chess. It's the map that allows you to see the entire board. At a lower level, I like to use another mapping tool called Impact Mapping. So if Wardley Mapping is this macro view of the entire landscape, Impact Mapping is the micro [00:04:30] view that connects our day-to-day work back to the strategic goals. Impact mapping helps you answer four questions. Why, who, how, and what? Why? What is the business goal or the mission goal we're trying to achieve? This comes from our goaling framework. Who? So who are the actors who can help us achieve that goal? These could be humans or systems. How? [00:05:00] How can their behavior change help us achieve the goal? And then what? What can we, as the delivery team, do to enable that change in behavior?

(05:10):

Ship a new feature, build a new integration. This simple exercise is incredibly powerful. It gives us an exhaustive list of all the things that we could do. Strategy then is deciding which ones to do. We make a bet on which ones we will do. [00:05:30] This becomes the foundation for the hypothesis that we discussed in the previous episode. It also creates a direct traceable line of sight from every single feature in our backlog all the way up to the highest strategic objective. It forces every single team to answer the question, why are we building this? And if you can't trace a feature back to that specific desired mission impact and change in user or system behavior for a strategic goal, you shouldn't build it. [00:06:00] These two techniques are how we deconstruct vision. They're how we build a shared understanding of the landscape and our place in it.

(06:08):

They're how we create a living strategy, right? But a strategy is useless if it stays on a whiteboard. It has to be executed. And this isn't about handing down a list of tasks. It's about cascading the why. We've already talked about the mechanism for this, the goal cascade. With OGSM, for instance, each level of strategy [00:06:30] becomes the objective for the level below, so that teams always understand how their work connects to the mission without being micromanaged. That's how we deploy strategy in a way that creates alignment without destroying autonomy. Where we want to get to is what the military would call mission command. A good commander doesn't micromanage with a 40 step checklist and a grid coordinate. They don't say, March to Hill 405, take this trail, use this formation and follow these [00:07:00] exact steps. Instead, they provide Commander's Intent. We need to take the high ground so we can dominate the valley and then the teams go make that happen.

(07:11):

Mission command is clarity without control, direction, without dictation. It aligns everyone on purpose and then trusts them on the method. It gives teams the why and the result, but not the script. This is the essence of empowerment, right? The secret to moving with speed and agility. [00:07:30] When your teams have mission command, they don't have to stop and ask for permission at every turn. They can make smart, decentralized decisions at the edge because they understand the strategic context of their work. It requires you though, to lead with context and not control. On the flip side of that, I'm often asked like, what if they don't take the metaphorical hill? Well, thankfully we're talking about software where most failures are not [00:08:00] severe and can be recovered from quickly. And I don't mean if we spent five years building and then find out a failure. That is a severe failure, but the way we're able to iterate with software, we can avoid a lot of these very severe consequences. But, they still matter.

(08:15):

So this is where your growth board comes in. You gave the team the objective and they built a strategy and they've agreed to a set of measures.

(08:26):

So they used that objective, that Commander's Intent to [00:08:30] come up with their own strategies, goals, and measures. Everybody at the growth board agreed that was the way forward. And as long as a team is learning their way to success towards that mission impact and those changes in user behavior, they should continue or even get more resources. But when a team is not progressing, a decision has to be made. Do you persevere? Did we learn something and we think, oh, we could still get to success here? Do we pivot like, oh, this team's good at experimentation. [00:09:00] We just need to go a different direction? Or do we cancel? Either this team is a dead end or the problem space is. If you do this well, competent teams will feel safe and empowered and even energized. And over time, any incompetence will be rooted out. But if you don't pivot or cancel teams when it's required, the competent people will end up leaving or stop performing and the organization will become another bureaucracy as it tries to solve those failures with control.

(09:30):

[00:09:30] And so as the organization's challenges become greater, which happens as they scale, right? As the organization scales, complexity scales, the talent density has to scale with it. And if you don't hold people accountable, talent density actually goes down. And then that creates this negative loop where the best people leave and things get worse. And usually when that chaos emerges, people respond with bureaucracy, with control, with rules.

(10:00):

[00:10:00] So we have to do the opposite of that. We have to increase the talent density level, which is something we'll talk about in the next episode. But one thing that's really important as we do that in relation to strategy and execution is accountability. So don't just hold growth boards, use them to make the hard decisions to hold teams accountable for progressing towards those goals and the ultimate objective. Safe to learn doesn't mean that we can actually fail, like not achieve [00:10:30] the mission, not get the objective. We have to get there eventually. So the point of learning is to progress towards the goal. If we're not progressing, then we're not actually learning. So we've covered vision, strategy, mapping, execution, and accountability. These are the tools a leader uses to clear a path through the complexity of the enterprise. They're how you turn a bold ambition into a tangible reality and align your organization to that shared purpose, giving your teams the [00:11:00] freedom and the focus to make it real.

(11:02):

But even the clearest vision and the most elegant strategy will stall without the people to bring it to life. In the next episode, we'll talk about people, the core of every transformation.

(11:22):

Wardley Mapping can seem really intuitive when you first look at it, but the first time you sit down to do one, it's super intimidating. And I [00:11:30] know the first time that I tried to create one when I was in the Air Force, I actually couldn't create it. And the key insight I gained from that is that I actually didn't understand all of the factors that I needed to understand to create a real strategy. When we use slide decks and visuals and all these things, we can have all kinds of holes in our logic that don't get exposed until you sit down to write... like Amazon's famous six page narrative is a way of exposing this. [00:12:00] Wardley Mapping is a really effective way to point out logical gaps in your thinking as it relates to strategy. And so here I was thinking that I was like really good at strategy, and I knew all the things I needed to do, and it quickly exposed that I didn't.

(12:15):

And that's where a lot of people turn away. They're like, "Oh, Wardley Mapping sucks, can't do it, " because they don't realize it's not the tool that sucks, it's them. I needed to grow. And I made many iterations and finally got to a better place, [00:12:30] but even still, by the time I left the Air Force, I don't think I had it to a level where I could effectively communicate it to others. And so on my first project when I started Rise8, we built one for a commercial organization actually, and it was their path to prod. So we mapped out value delivery to customers down to commodity infrastructure. And what it exposed was actually, [00:13:00] the initial strategies had been all about creating new and better applications. And we found out that once we mapped this out, the real problems were in path to prod. A lot of the things that I've discussed in previous episodes, right?

(13:13):

A lot of those beliefs are built on having now done this kind of mapping for many organizations, and always finding path to prod is a key constraint. And so we ended up looking at that and realizing that there was all of these activities going on around path to prod. And what we needed [00:13:30] instead was like a straight line from capability to commodity infrastructure. We called it paving I-90 because I-90 was the route between two of the critical sites in this organization. So it was all about taking all of these components that were being done in path to prod and paving them into one cohesive path, and choosing the right mix of where to use commodity infrastructure versus where to build custom. And so we made a hypothesis from that, did build, [00:14:00] measure, learn loops, and got to success. And it was one of the first times that I was able to connect, like really tangibly connect, the strategy and why do this, not that, versus just brute forcing it, right?

(14:14):

Like getting everybody to see it and agree and buy into it, invest resources in it and succeed.

(14:26):

Early on in my career, I had a team that built a really [00:14:30] great Impact Map and it ended up saving them from building a whole bunch of the wrong things. And it revealed that a lot of the proposed features had no real connection to the strategic goal. And so as we're looking to replace a legacy system, we're given this set of requirements, and the assumption is that those requirements are correct, right? The enterprise has already done some version of Impact Mapping. It doesn't look anything like the way that we do it [00:15:00] in Mission O/S, but essentially, through multi-year planning, and committees, and working groups, they've taken this mission objective that we want to achieve, and mapped it to what they believe are the human and system behaviors that will drive that and all of the potential things we could build to do it. And they go through that exhaustive list of everything and select the things that we're going to do and they put those in a requirements spreadsheet.

(15:28):

Of course, what we know, what we've been talking [00:15:30] about a lot is that those things have a very high probability of being wrong, usually upwards of 50%, sometimes more. And so the team doing the Impact Mapping, they mapped out that same strategic goal and they were able to uncover that they could build less than half of those features and still hit the mission impact. So again, the desired impact hasn't changed. It's just.. there's a way better way to get to that impact map and they know that because they're [00:16:00] closer to the problem. And so fast forward, they built that smaller list of features and they were able to get user adoption. So they built less than half of the features on the requirement spreadsheet, still hit the strategic goal, saved a ton of time, a ton of money, and a ton of headaches. And so it's just a really great example of how even if something like an Impact Map has been done, it's important how it gets done, when, what the time delays [00:16:30] are...

(16:30):

So if you're in an enterprise where something like an impact Map has already been done and generated a set of requirements, it's important to go back and look at that, revisit it, and let the teams have the context so that they can iterate their way towards the strategic goal rather than build all of the things and assume it will hit the strategic goal.

‍