Episode 12

Bryon Kroger (00:05):

For the past several episodes, we've been deep in the world of strategy. We've talked about mapping value streams, deconstructing domains, and setting clear cascaded goals. We've built the frameworks for thinking about our complex enterprise in a new, structured way. But here's the hard truth that we have to confront. In government and large enterprises, we are brilliant at creating strategy: thousand page documents, [00:00:30] color coded decks outlining the whole entire next decade. In a world being eaten by software though, strategy without execution is nothing more than an expensive hallucination. And this is the great divide. The space between the boardroom and the keyboard, where trillions of dollars and countless hours of human effort go to die. Leaders create plans as if they're constructing a building, but software doesn't work that way. By the time the blueprint reaches the team, the mission's already [00:01:00] evolved. The technology has already advanced and the user's needs have changed.

(01:05):

The strategy is already obsolete. And the teams on the ground lacking the context or the capability to adapt, they're left to execute a dead plan. This is the anatomy of a zombie project. This is why Mission O/S is built on a simple, powerful mantra, borrowed from the lean startup movement. Think big, start small, scale fast. This isn't just a catchy phrase. It's the operating [00:01:30] model for bridging the gap between strategy and execution. Let's break that down. Think big is about everything we've been discussing. It's the necessity of doing the hard strategic work. Applying it to the enterprise, is using value stream mapping and domain-driven design to deeply understand the enterprise. It's using frameworks like OGSM to set clear, bold direction. You have to have a vision. As Jeff Bezos says, thinking small is a self-fulfilling prophecy. [00:02:00] If you don't have a compelling vision for the future, you'll get trapped in incrementalism.

(02:05):

But, and this is a crucial distinction, thinking big does not mean building a detailed plan. And this is where we get to start small. Starting small is the antidote to the enterprise affliction of starting big, right? The default instinct of a bureaucracy is to eat the elephant in one bite, but that's a guaranteed recipe for failure. For us, starting small means that the very first [00:02:30] step of executing any grand strategy isn't actually about what we build at all. It's to prove that you can ship. And it doesn't mean some complex application. It can mean something as simple as hello world. Start with execution. Start with evidence. I cannot overstate this. Your ability to execute your efficacy is the prerequisite for any meaningful strategic conversation. This is the central thesis of Mission O/S. Efficacy before alignment. [00:03:00] You have to build the well-oiled IT system first. You have to establish that path to production.

(03:06):

You have to prove that you can get a single line of code from a developer's keyboard to a real user in a real production environment. And that small initial act of delivery is the most strategic thing that you can do because it changes the entire nature of the conversation. Strategy ceases to be a theoretical debate and it becomes a series of testable hypotheses. Our ability to continuously [00:03:30] deliver is the engine of modern strategy. It's the scientific instrument that we use to probe reality. Is this feature valuable? We don't have to argue about it for six months in an architectural review board. Let's ship it to 5% of our users and see what the data says. Does this new workflow save time? Let's build a thin slice of it and measure the results. Our strategy is no longer a static document. It's a living, breathing thing that we can validate, invalidate, [00:04:00] and adapt based on real world evidence.

(04:03):

That brings us to scale fast. Once you've established the capability to deliver, once you have that first balanced team shipping code through a reliable path to production, scaling is not about adding more process. It's not about implementing the scaled agile framework. Scaling fast is about removing the things that stand in your way. So scaling is about taking the successful, repeatable pattern of that first team and enabling [00:04:30] more teams to follow by descaling the bureaucracy. It's a fractal pattern and the leader's job becomes one of bureaucracy hacker... identifying and eliminating the organizational friction that prevents the flywheel from spinning faster. This also redefines the role of leadership in a digital organization. Your job is not to be the master strategist with the perfect plan. Your job is to be the chief enabler of execution. Your first responsibility [00:05:00] is to champion and fund the creation of that initial path to production.

(05:04):

That is your strategic priority number one, two, and three. Your second responsibility is to protect that first balanced team as they start small. They are your NUMMI maneuver. They're an island of the new way of working, and the bureaucracy's immune system will try to attack them. You have to be their shield. Your third responsibility is to take the evidence, the data, the stories from those early execution [00:05:30] wins, and feed that back into the high level strategy. You use their tactical learnings to inform your strategic direction. And your final responsibility is to clear the path. To use your influence and your political capital to remove the blockers that prevent your teams from scaling fast. Strategy and execution are not a sequence. They're a dance. They're a continuous iterative loop. Your strategy informs where you execute, and the results from your execution inform how you adapt [00:06:00] your strategy.

(06:01):

But the dance can only begin when you have the ability to take the first step. So the litmus test for any strategy in your organization is this: "what is the smallest, fastest experiment we can ship to production to test a core assumption of this strategy?" If you can't answer that question, or if the answer is "we can't," then you don't have a strategy. You have a wish. And in the world of critical missions, wishes are not enough. Now, delivery alone isn't the goal. It's [00:06:30] just the first step. The real goal is to learn the fastest, to continuously adapt, evolve, and outpace the rate of change around us. That's where we're headed next.

(06:50):

I want to tell you why shipping Hello World to prod can be such a monumental win when you're just starting out. I have seen countless teams now [00:07:00] try to push to prod after months or sometimes even years of development, only to find out that there are basic things missing in the path to production that would enable them to do so. And it requires either a lot of rework on their end, or forcing the path to production related teams to do a bunch of new work or offer new services. And so one example that I saw was that a team had built their application [00:07:30] using a language that wasn't supported by the secure release pipeline. And so then, the teams scrambled and incorporated that support for that language in the secure release pipeline, and then went to deploy to production only to find that the way they had architected would not work on the network they were deploying to.

(07:50):

And so you say, "Well, couldn't you have just read the documentation and built a better plan?" Sure, you could do that, but the problem is that in [00:08:00] the enterprise, things are not as advertised. And so when you actually look into the specifics of this situation, the secure release pipeline team was actually advertising that they could support this language, and the production environment was advertising that they had the backing services that were required for this application team in production, neither of which were true. And so doing things like shipping Hello World to production on day one would have told [00:08:30] this team that the language they chose wasn't supported and the backing service they needed weren't available. And just that one example of the learnings, you say like, "Oh, that's not a big deal. You could just change." But sometimes that requires re-architecting and doing rework for months, if not years worth of work. Not cheap.

(08:51):

And all along, not only do you have to pay for that rework, but you have a cost of delay that you're incurring, and you're building up risk that you built the wrong thing [00:09:00] or built it the wrong way. And so it's absolutely essential that you either get Hello World app to production or very, very early iterations of your app. The sooner the better. Don't wait until MVP.

(09:19):

As a leader, you have to be a bureaucracy hacker. And the piece of bureaucratic red tape that I'm most proud of cutting for my teams, and really now for all of [00:09:30] the DoD and the federal government is the Risk Management Framework red tape. And I want to be clear, I want to distinguish between the Risk Management Framework and the red tape that's built up around it because those two things are not synonymous. In other words, the framework itself doesn't create the red tape, but a bunch of red tape has historically existed and still exists all across federal government when you're trying to get an Authorization to Operate and deploy your software into production in accordance with this Risk Management Framework process. [00:10:00] And so everybody told me like, "Hey, this continuous delivery thing can't be done because there's just no way to do that from an ATO perspective.

(10:09):

It's governed by FISMA, which is law, you just can't do it. " And so we went in and actually read the Risk Management Framework. NIST produces all sorts of documentation. It's actually really great documentation. NIST 800-37 is the Risk Management Framework. And when I read it, actually everything I was trying to [00:10:30] do, it said I could and should do, and it even had a bunch of tips about how to do it. And so by simply following the Risk Management Framework, and re-architecting the process, and getting rid of all of the red tape that had built up around it, we were able to establish what's now referred to as continuous ATO or the ability to continuously deliver to production while still maintaining Risk Management Framework compliance, and being in compliance with the law. And so I'm super proud of that one. And it's [00:11:00] just one example of many where you can go in and look at what's actually required and eliminate everything else around it and build better processes that are actually value add and help you achieve efficacy and efficiency.

(11:15):

And when you look around, you'll find a lot of these, and they're super critical for enabling your teams to ship outcomes and create mission impact.