In the 1950s, there was a man named John Boyd who 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 be moving the fastest. The key to victory is to be able to create situations wherein one can make appropriate decisions more quickly than one’s opponent. He called this idea the OODA loop. The idea was to
- Decide, and
…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.”
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.
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 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.
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 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 issues I see in engineering organizations is focusing on shipping big projects, where you learn the result of the project at the end. You often miss the mark. I think focusing on projects as the unit of delivery is fundamentally 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.
Alex Kroman wrote a blog post a long time ago that disappeared from the internet, and I basically stole this post by rewriting his post from memory. Then I remembered archive.org, and as I was writing up the credits found his original post!
Images are courtesy of Wikipedia.