jade rubick

What can air combat can teach us about software project failure?

2020-10-13deliveryvelocity

Colonel John Boyd invents the concept of the OODA

In the 1950s, John Boyd revolutionized aerial combat. He was known as “40 Second Boyd”, because he had a standing offer that he could start from any position in the air, and defeat his opponent in 40 seconds. He never lost his bet.

He was influential in a lot of ways, but one of the things he’s known for is his theory of how to gain tactical advantage in aerial combat. The way to gain advantage is not to have the fastest plane, or to move the fastest. The key to victory is to be able to create situations where you can make good decisions more quickly than your opponent. He called this idea the OODA loop. The idea was to

  • Observe,
  • Orient,
  • Decide, and
  • Act

…faster than anybody else. He said, “Time is the dominant parameter. The pilot who goes through the OODA cycle in the shortest time prevails because his opponent is caught responding to situations that have already changed.”

Focusing on speed in engineering teams is a mistake

War metaphors only go so far, but there is a lot of relevance here to engineering and business. The speed at which we iterate is more important than how fast we are going. Too often, we focus on how much output a team has, or whether they ship a project on time or not. But it’s far more important that they’re observing, orienting, deciding and acting quickly and effectively.

If you’re able to do something small and learn from it, and do that over and over again, you’ll usually come up with something far better than something big with less feedback. If you make a mistake with small increments, you’ll have lots of chances to correct yourself. With the big monolithic approach, you only have once chance to get it right. [Narrator: you won’t get it right].

Fast feedback loops + good sensing == great outcomes

So, we need to focus on things that speed our feedback loops:

  • Keep scope small.
  • Decide things quickly. Don’t overthink decisions that are reversible.
  • Coordinate effectively.
  • Build trust with each other, so we can act quickly.
  • And we have to be well oriented and have excellent context.

We can do this in our individual actions, as individual contributors, and as managers. And most importantly for engineering, we must do this in our projects, because it enriches the value of engineering organizations immensely to deliver things in faster, smaller loops.

One of the most common failures I see in engineering organizations is shipping big projects, where you learn the result of the project at the end. You often miss the mark. Focusing on projects as the unit of delivery is flawed. Instead, break things into pieces, and focus on validation and learning as often as you can during the course of the project. The results will be far superior.

Part of the reason this is so valuable is that velocity is a vector: it combines movement with a direction. Incremental delivery helps ensure your direction fits your customer needs, so even if it were less efficient to be incremental, the results are almost always better.

Thanks to Alex Kroman for this post. He wrote a similar blog post a long time ago that disappeared from the internet. I basically stole this post by rewriting his post from memory. Then I remembered archive.org, and as I was writing up this thank you found his original post!

Images are courtesy of Wikipedia.

Comments powered by Talkyard.