Building software is an inherently creative endeavor.

We never build the same thing twice — if we wanted the same thing we’d just copy-paste it! We’re always solving a new problem, which brings with it new unknowns. We also work in near-constant uncertainty and ambiguity. Priorities shift, requirements change, and our understanding of what’s needed to meet those requirements evolves over time.

The best way to achieve success in the face of all this uncertainty and change is to set up rapid feedback loops. In the past I’ve likened this situation to racing in a rally car — you need a clear windshield so that you can see the turns approaching, and a sturdy grip on the steering wheel so you can rapidly course-correct.

In this article I’ll describe how an organizational approach called Mission Command can establish autonomous software teams which are empowered to make rapid, local decisions within that sort of rapid feedback loop.

Software as warfare

Another analogy is that building software is like operating on a chaotic battlefield. You need to be able to rapidly react to evolving circumstances and new information.

Maybe we can learn something from the military — how do they organize themselves to be successful in these situations? Not, perhaps, in the way you think. Military organizations are generally viewed as the quintessential organizational hierarchy, operating using Command and Control. Orders come down the chain of command, and everyone mindlessly follows the orders given to them by their superior.

In reality, this is only half-true. Modern militaries place great value in the concept of Mission Command, also known as “mission-type tactics,” or Auftragstaktik. Under the Mission Command doctrine there is still a chain of command, but rather than passing down detailed orders to the grunts on the ground, commanders pass down the broad mission goal, and trust the people closest to the action to determine the best tactics to achieve that goal. This doctrine has been shown to be incredibly effective. This is because it allows teams to work autonomously. Decisions can be made close to the information that informs those decisions. Teams work within a rapid feedback loop, continually modifying tactics in the face of new information and a changing environment.

Mission Command for Software Teams

Let’s see how these ideas apply to software delivery teams. We’ll visit two engineering organizations; Acme Corp, a top-down Command and Control organization, and Widgets Inc, which has more of a Mission Command culture.

Acme Corp has a conversion problem

Fiona, the Director of Frontend Engineering at Acme Corp has been told by her boss, the VP of Engineering, that the load time of the checkout page needs to be reduced. A recent analysis has shown that it increased from 400ms to 2500ms over the last 9 months, and that seems to correlate with a drop in completed transactions — fewer people are buying stuff!

Fiona brings this to the Acme Corp architecture group. They conclude that the best way to solve this problem is to optimize the database queries that power that page. Fiona concurs. She then meets with Tanisha, who is the tech lead of the Purchase Team that own the checkout page. She tasks Tanisha’s team with optimizing those database queries, with a goal of reducing query time to 50%.

Tanisha’s team get to work. They find some low hanging fruit that allows them to reduce query time quite a bit, but it turns out that significant additional reductions aren’t feasible, due to restrictions imposed by the ORM they are using. They decide that to meet the goal passed down to them by Fiona — 50% reduction in query times — their only option is to swap out the ORM. This is not a trivial task, but it seems that is has to be done. Several weeks of hard work later, they’ve managed to get the ORM swapped out (it turned out to be a little trickier than they first thought), and finally they get the remaining database optimizations in place. They managed to reduce query times down to 25% of what they were before, delivering even more than Fiona had asked for.

Tanisha meets with Fiona, letting her know that they’ve finally gotten those queries optimized. Fiona is initially pleased, but upon further analysis the load time for the checkout page has only been reduced by 10%, despite almost 2 months of hard work from Tanisha’s team. It turns out that those database queries take up only a small portion of the overall load times for the checkout page.

Everyone is frustrated. 2 months of effort has yielded little progress towards the goal identified by the VP of Engineering.

Widgets Inc. has a conversion problem, too

By a strange coincidence, the exact same situation has also come up across town at Widgets Inc. Brenda, the Director of e-Commerce, has been asked by her VP of Engineering to reduce load times for the checkout page. Brenda meets with Carlo, the tech lead for the Checkout Squad that owns that page.

She explains that they need to reduce load times for the checkout page, as the slow load times appear to be impacting conversions.

Carlo sets up an initial meeting with the architecture group, and they conclude that the best approach would be to optimize the database queries.

Carlo and his team get to work, but after a few days they realize that database queries only account for about 20% of the page load time. The team do a bit of analysis, and discover that a lot of the page load time is spent on calls to a slow backend service used to provide a list of related products — the checkout page has a “people who bought your stuff also bought this stuff” cross-sell section which is powered by that service. Carlo’s team also discover that there are several large third-party javascript files which are not critical to the page but which block the checkout page’s initial render time significantly.

Based on this new information, Carlo’s team come up with a new plan. They will modify the checkout page so that the related product section is populated asynchronously; after the initial page load. They’ll also make sure that the checkout page’s 3rd party scripts are loaded asynchronously. These changes take a couple of weeks to implement, and once they’re done the team are impressed to see that the checkout page’s time-to-interactive has gone down from 3000ms to 1200ms. This is a big win, and both Brenda and Carlo are delighted with the outcome that the team delivered.

Why Widgets Inc. won

It’s clear that Widgets Inc. were more successful than Acme Corp in meeting the same overall objective passed down by their respective VPs of Engineering. What was the difference between how these two organizations operated to achieve that objective?

Carlo — the Widgets Inc tech lead — was provided a high-level goal — reduce load time for the checkout page — along with context as to why — it’s impacting conversion. In contrast, Tanisha over at Acme Corp was just told to optimize database queries, with no broader context as to why. That additional context was available to Carlo’s team. This enabled them to realize that their initial plan was flawed, and come up with an alternate plan that would still achieve the broader intent, but in a more effective way. Because Widgets Inc. has a culture that empowers autonomous teams, Carlo’s team were able to quickly react to new information and execute on a new plan, without needing to set up additional meetings with Brenda or the architecture group. This doesn’t mean they didn’t solicit advice, but they didn’t have to wait for an OK before moving forward with their new plan.

It’s also interesting to observe that it’s likely that neither Brenda (Carlo’s boss) or the Widgets Inc. architecture group would have come up with an approach as effective as the one Carlo’s team did. Carlo’s team spend their whole lives in that checkout page, and have a deep understanding about the page that their leadership don’t have. This applies both in a technical sense — they probably know a lot about both browser performance optimization and the backend services they rely upon — as well as in a domain sense — they probably have a good sense of how valuable the related products cross-sell is vs. speeding up the checkout page load time. On the flip side, the leaders at Widgets Inc have a broader perspective which allowed them to notice that conversions have gone down, and eventually correlate that to the checkout page.

A culture of Mission Command has allowed Widgets Inc to take best advantage of both the higher-level vision of the organizational leaders as well as the on-the-ground expertise of the delivery teams.

How to make Mission Command work

Succeeding with a Mission Command philosophy requires some cultural aspects to be in place within the engineering org:

• Failure is OK, as long as we learn from it
• Assumptions should be challenged
• Value Outcomes over Output
• Understand the Why behind the What
• It’s reasonable to change the plan in the face of new information

If you try to introduce Mission Command without some or all of these cultural elements in place, you will likely struggle to reap the full benefits.

Further Reading

I first learned about Mission Command from the excellent book Lean Enterprise. There’s some additional background in there, as well as broader advice on how to introduce Mission Command ideas into an organization.

Turn the Ship Around and Art of Action both talk in much greater detail about Mission Command, but in the broader context of general organizational leadership. You can also cheat and watch this 10-minute video, based on a talk by David Marquet (the author of Turn the Ship Around), which apparently summarizes a lot of the thinking from his book.