Learn why software delivery fails in government — and what's required to make shipping possible.
Episode 09
Episode 9 revisits alignment and explains why organizations get stuck when they try to align before they can deliver.
Bryon shows how alignment emerges through learning, shared goals, and delivery in production—not through endless planning or consensus-building.
Why software fails inside government—and the real-world consequences when it does.

Rethink success: learn fast, reduce risk, and deliver real mission impact.

Why outcomes only happen in production—and why “it won’t work here” is a myth.

Why government software gets stuck before production—and how to fix it.

Build platforms that help teams ship—not slow them down.

Why product, design, and engineering must work as one team.

Change culture by changing behavior.

Achieve alignment through learning—not endless planning.

See how work actually flows through your organization.

Episode release date:
April 14, 2026

Episode release date:
April 14, 2026

Episode release date:
April 28, 2026

Episode release date:
April 28, 2026

Episode release date:
May 12, 2026

Episode release date:
May 12, 2026

Episode Resources
Transcript
In the last episode, we talked about how you can't change culture by changing thinking. You change it by changing behavior. But once we've got that change in motion, the question becomes, how do we steer it? And that's where alignment comes in. Unfortunately, this is also where many organizations fall right back into their old habits, conflating alignment with meetings, lots and lots of meetings. And so we saw this in the last episode too, leaders chasing transformation through optics instead of action. Alignment becomes more of the same, another ritual, another performance, multi-day planning events, committees, beautifully color coded roadmaps that are obsolete the moment they're printed, and countless dollars and hours spent trying to get everyone perfectly aligned on the plan. And that's a trap. It's called the alignment trap. And the problem with this approach is that it puts the cart miles ahead of the horse.
Organizations are having deep theoretical debates about the most valuable things to build, but they have no way to actually deliver them. They have no path to production. That means they have no way to test their assumptions with real users. So the alignment conversation becomes this endless cycle of long range planning and execution without validation. Costs go up, growth goes down, and frustration reigns. It's a trap because so much money, energy, and time is spent on the alignment activities that there's nothing left for building and for path to production. You just can't get out of the theoretical. And the Mission OS philosophy is simple. Efficacy before alignment. We have to prove that we can ship first by establishing a working path to prod. And it doesn't really matter what you ship first. You just get it in the hands of users. Because once you have that path in place, then you can start having productive evidence-based conversations about what actually matters.
When we disagree, we don't need to debate for six months. We can ship two experiments in two weeks and let the data do the talking. And when it's time to have that discussion about what really matters, not the release itself, but the behavior it changes and the mission results that it moves, it helps to have a shared model to link the work to the impact. And so the model that we use is from the Kellogg Foundation. It's called the Kellogg Logic Model. It's brutally practical and forces you to show your work from what you put in to what you do, to what changes, to what actually matters for the mission. The chain for the logic model is resources or inputs. These are the people, tools, and organizational assets that we bring together to conduct activities, which are the work we perform. This one's fairly obvious, right?
Planning, discovery, coding, testing, shipping. The outputs then are the tangible deliverables from those activities like new features and new software applications. Outcomes though are this missing link that we often see. Outcomes are the changes in user or system behavior that produce mission results. What do people actually do with the software we give them? And the impacts then are the mission results, the real world wins that your stakeholders actually care about. And so your stakeholders should define the desired impacts, the things we want to do for the mission. Your job is to determine what outcomes have to happen. What changes in system or user behavior have to happen to reach those desired impacts and connect your outputs, the things that you're building to impacts by aiming at outcomes on purpose. That's what efficacy and outcomes over outputs really means. You're not shipping software just to ship.
You're shipping software to change behavior and advance the mission. This is where the Improvement Kata plugs in. So the logic model tells you what good looks like. The impact that you're after, the outcomes that prove that you're getting there. The Improvement Kata, which is a model adapted from the Toyota production system, the masters of continuous improvement, provides you the framework for how you get there from where you are today, creating alignment that's scientific, iterative, and sustainable. So let's break down the Improvement Kata. A Kata is a Japanese term for a structured routine that you practice over and over and over until it becomes second nature. The Improvement Kata is a simple four-step routine for scientific thinking that we use to drive all of our alignment activities. Step one is to understand the direction or challenge. This is the big picture, right? The high level vision from leadership. The overall thing that we're aiming for.
For example, it could be reduce the time it takes to plan and execute the air tasking cycle. Step two is to grasp the current condition. This is the most frequently skipped and most important step. Before we can talk about the future, we have to have a deep factual understanding of the present. And we have to orient honestly. Where are we today? What does the data say? What are we observing in the system right now? Where's the friction really happening? This is where we stop guessing and start seeing. From there, we can establish the next target condition. Step three. This isn't the final destination. It's the next measurable outcome that we want to hit. Something achievable that gets us closer to the challenge and the mission results. It's not a task list or a roadmap. It's a condition you can see and verify. And if you notice, step three lines up really nicely with the Kellogg Logic Model.
The next target condition is the impact, right? The mission result that stakeholders and leaders want. For example, if our primary constraint in that air tasking cycle is in basic target development, then we might want to reduce the average basic target development timeline from 72 to 24 hours by the end of the quarter to alleviate the constraint. And so that's what we would set as our target condition. Step four then is to experiment towards the target condition. This is build, measure, learn in motion. We run rapid experiments, these build, measure, learn cycles to overcome obstacles between the current condition, and the target condition, and to learn what works. So our hypothesis is a function of an impact map, filling out the rest of the Kellogg Logic Model to list out all the possible outcomes that could contribute to the desired impact, all the outputs we could create to create the impact, and then selecting the ones that we will pursue to form our hypothesis.
So of all the available outcomes we could create and things we could build to create them, we make a bet that if we do these things for these people and create these outcomes, we'll achieve the desired impact. And then we allocate the appropriate resources to the activities that are required to complete the experiment plan. This is how we turn discovery into delivery. So this four-step routine is the backbone of everything that we do. And it matters because alignment isn't a meeting. It's a learning loop. Now I want to talk about the specific tools we use to execute it. To understand the current condition, step two of the Kata, we use Value Stream Mapping first. We bring the right people together in a room and map the entire workflow at a business level. We're talking about business events here. How value actually flows to the mission today through the end users.
We look at that end to end. It exposes where time and effort are being wasted and it replaces all the opinions and anecdotes with a shared visual understanding of reality. Now, the technical counterpart to this is Domain-Driven Design. So if the Value Stream shows how the business operates, then Domain-Driven Design shows how the architecture either helps or hurts that flow. And together, these two tools replace opinion with reality. And we combine that with a user journey map. How do users interact with these business events and the underlying systems. And all three of these together create a map of the current condition. Now, once we understand where we are, we can establish our next target condition. Step three. For this, we like to use a structured goaling framework like OKRs or OGSMs, which stands for objectives, goals, strategies, and measures. The framework you choose is less important than the discipline of carrying it out.
A framework forces us to be incredibly precise. So we don't just say make it better. We say, our objective is to improve the targeting process. Our goal is to reduce approval time by 30%. Our strategy to get there is to automate the data ingestion. And our measure is the average time and stage for a target nomination. So this creates a very clear target that the team can rally around. Now, the Improvement Kata is not a solo activity. It's a partnership. It's a structured routine between a coach and a learner. And so the learner is typically the product manager or the delivery lead who's responsible for hitting the target condition. Their job is to run the experiments and report on the learnings. The coach is their leader. Their job isn't to provide solutions or make decisions. Their role is to ask a specific set of questions over and over to keep the team focused and learning through action.
So when we meet, we like to ask questions like, "What is your target condition?" Or, "What is your current condition right now? What obstacles are preventing you from reaching the target condition and which one are you focused on?" Maybe what's your next step and what do you expect to happen? Or how quickly can we see what we've learned from taking that next step? The coaching Kata is how you scale this way of thinking. Because you can't scale this through command and control, you have to produce a whole bunch of teams that are capable of mission command. Leaders don't drive transformation by being the smartest person in the room. They do it by creating teams of scientific problem solvers. So zoom out. The Kellogg Logic Model keeps you honest about why you're building anything at all and what resources you'll allocate against the desired impacts.
The Improvement Kata keeps you honest about how you're going to learn your way there. And together they turn alignment from theater into science with outcomes in production and real mission impact. In the next episode, we'll expand on step two of the Improvement Kata, grasp the current condition. I'll walk you through how to create a shared map of your enterprise using tools that expose friction, waste, and the real opportunities for change.
So the Kata is predicated on a coach and a learner. And early on in my own journey, I was a learner. In fact, I would say I'm always a learner, a lifelong learner. There's this great book called The Trillion Dollar Coach, and this was an eye-opening moment for me because the book talks about how the same guy coached Eric Schmidt and Steve Jobs and one other person. And I'm just looking at it, I'm like, "Man, if those guys need a coach, I need a coach." And so nobody is above needing a coach. And I think no matter what you're doing, where you're doing it, what stage of your journey you're in, it's really great to have a coach. And so I had several. I had some people who were working directly with me, who taught me to think in these ways and use a lot of these processes, but sometimes when you don't have those people, or maybe even in addition to those people, almost every book that's written, you could consider it somebody coaching you for the low price of $20 or whatever the book costs you.
And it's really important that you're constantly seeking out that kind of coaching to make sure that you can go through your continuous improvement cycle.
So for the leaders out there listening who are used to giving answers and directing all the traffic, more of a command and control style of leadership, I think the hardest part about transitioning to this role of a coach who just asks questions is you have to learn a new set of skills, right? And often when you start doing this, things start failing and you're like, "I just have to go back to directing all the traffic." And it's because you haven't gotten good yet at coaching people to become the kind of people that can embrace mission command and succeed with it. And so every time things start failing, don't say, "Oh, my people aren't good enough. I just need to take over again." Think I'm not good at coaching and I need to fix that. And that should become your sole focus like, how do I coach this person to be me when I'm not in the room or to be like me when I'm not in the room if that's the way you want to think about it. Or to be them, which is different than you, but still capable of getting to the right outcomes.
And then once you have those skills, your role is to constantly guide them through questions. Make sure they have all the right data, that they're thinking about it in the right ways, but ultimately they still have mission command.
So if you're a change agent out there who wants to introduce this Improvement Kata to your organization, I would say the smallest, simplest problem that you could apply it to, in a week or less, to demonstrate its power is a Value Stream Mapping and Domain-Driven Design workshop. A lot of times you can combine those into one week or a lot of times for us, we're really good at running them at this point, we could get that done in three days. And what you'll see is people constantly walk away from that saying like, "Oh my gosh, I learned more about our organization in these three days than I've learned in three, four, five years of working here, and I have such clarity about what we need to go do now." It's just this big unlock moment and I think it's the easiest one because I say that everybody has clarity on what they need to do next. But once you go into solutioning, you'll realize there's a lot of diverging opinions.
So I'll go back to, if you have a path to prod, you can resolve those differences by just shipping both and seeing what works best, we'll get to that later, but ultimately the easiest, simplest thing that you can do, where you'll generally find everybody is aligned, is going through the Value Stream Mapping and Domain-Driven Design and condensing it into a really small time period. Huge unlocks, you'll get a bunch of believers, and they'll be ready for the next step.