Week of 2021-11-15
This one is a bit weird: the pieces string into a larger story that I am hoping to tell over the course of the next few issues -- with more illustrations than usual. It’s like this newsletter is being temporarily possessed by the rogue spirit of an unfinished slide deck. The preliminary title for the series is “Jank in teams.”
The OODA Loop
One of the lenses for which I tend to reach frequently is the OODA loop. First articulated by John Boyd in the context of combat, it’s found its way into various other spheres of strategic thinking. The way I hold it is probably different from how The Mad Major intended, because I apply it in non-confrontational contexts. Here’s the basics.
Conceptually, our interaction with the environment outside can be viewed as this continuous cycle of observing, orienting, deciding, and acting -- also known as the OODA loop.
When we observe, we try to gather information about the environment. What is happening? What are the circumstances? What are the changes? Trends? What are the constraints?
Then, like clockwork, we move on to orienting, or making sense of what we’ve observed. We try to look at all of the existing information we might have, smash it with the new one, and synthesize a model of what’s happening.
Once we’ve convinced ourselves that this is indeed the model, we decide. We try to roll the model forward in time and predict what will happen next, forming our hypothesis for the final step.
Once we have the hypothesis, we act within the environment. The all-important feedback loop takes us back to the first step. Acting is just a test of our hypothesis, and we need a way to keep refining that hypothesis.
So we jump back into observing. What happened after we acted? How did the environment react to it? What does that tell us about it? And on we go, cycling through the OODA loop.
One significant part that I often see missed is that there are actually two interrelated loops. As mentioned above, the environment cycles through a loop along with us. Suppose that you and I are playing a simple turn-based game. Applying the OODA loop lens, I am part of your environment. It’s easy to see how both you and I are cycling through two loops. You observe my actions, I observe yours. We both orient, decide, and act based on the actions of each other. Being turn-based, our game synchronizes our OODA loops. I can act only after you act and so on. Now, imagine that you could take five turns while I could only take one? That would give you a massive advantage. You’d be running … err... loops around me.
This is a valuable insight that’s not easy to grasp when just looking at a picture of a loop. Outside of this cyclical sequence of steps is another loop -- the one of the environment.
If I am cycling in lockstep with the environment, I never have to worry about keeping up. I have the advantage if I am cycling much faster -- I can be five steps ahead, anticipating what comes next like a magician. Of course, if my OODA loop cycle is a few times slower than that of the environment, I am like that sloth from Zootopia, hopelessly out of touch with what’s happening: the environment is zooming past me.
It is my experience that these situations are rare and I am not going to spend much time considering them. Instead, I want to study the situation where most organizations find themselves: the two loops cycle at nearly identical speeds, and the organizations struggle to get their OODA loops to go faster. Which brings us to the concept of jank.
🔗 https://glazkov.com/2021/11/14/the-ooda-loop/
Jank
I first learned about jank when I joined the Chrome team. It’s a weird slang word with multiple meanings, so I am going to use a narrower definition, custom-crafted just for this narrative. To get there, I will make a brief detour into the land of rendering Web pages. Hold on to your hats.
Suppose you are visiting a site. I’ll be the browser in this story. You just clicked on a button, and I need to play out a lively animation as a result. Like humans, browsers are mesmerizingly complicated, but at a very high level, the animation is a sequence of frames -- pictures of the intermediate states between its beginning and end. Each frame is rendered -- that is, created on demand in a very brief moment of time. For example, to play out an animation at a common-for-computers rate of 60 Hz (that’s 60 frames per second), I have just under 17 milliseconds to render each frame.
Rendering itself is a multi-step process, usually called a pipeline (does this start to remind you of something?) To produce a frame, I must go through each step in the rendering pipeline. Think of it as a clock that ticks every 16.667 milliseconds. If I was able to fit all the steps between the two ticks, I have a frame of animation that I can show to you. Yay!
However, if going through the rendering pipeline takes longer than that, the next tick will arrive before I have the frame ready. Bad news. Despite all the work that I’d done, you won’t see this frame. It’s dropped. Worse news: because I had to finish all the steps (those are the pipeline rules), I accumulated a deficit -- my work on the frame that follows begins with the negative time balance. For example, instead of 16.667 milliseconds, I might only have 12. What’s the likelihood that this frame will get dropped as well? Pretty high.
As a user, you will see this phenomenon as “jank”: instead of a smooth animation, it’ll look like a stuttering janky mess. Put very dryly, jank is the observed effects of a regularly scheduled pipeline-like process not fitting into its allotted time budget.
Wow. That is very dry. Let’s see if we can make it a bit more useful by applying what we learned here to the OODA loop. Let’s unroll the OODA loop.
🔗 https://glazkov.com/2021/11/14/jank/
OODA, unrolled
Putting jank and the OODA loop next to each other, it’s hard not to see the similarity. Both have two timelines racing against each other. Both describe one timeline trying to go a bit faster than the other -- and there’s one timeline that consists of a repeating sequence of steps.
The question that got me excited was: “What does jank look like for the OODA loop?” To answer it, I did some light reframing to express the OODA loop as the timeline view that we’ve learned from rendering animations.
In this timeline view, the environment’s OODA loop becomes the ticking clock. Within each tick of this clock, we fit the familiar pipeline-like process: observe, orient, decide, act.
This setup is not exactly the same as having two independent nested loops, interacting with each other. However, since we’re most interested in situations where the nested loops are closely matched, this simplification works well enough. Here, the environment sets the pace and we try to match it. With each tick of the clock, the next round begins.
In this framing, the OODA jank is the situation when the cycle of the inner OODA loop is taking longer than the one of the environment.
Since I’ve just concocted a different way to look at the OODA loop, I might as well add another twist. Unlike in Boyd’s original military context, OODA jank is not lethal for most organizations. It is something that happens commonly, perhaps many times over. Team jank is not great news, but most of the time it’s not existential, either. Deadlines get missed, but things still get delivered. People are late to meetings, but they do show up. Product launches get delayed, but most often, still happen at a later date. Human systems aren’t mechanical. They tend to be more resilient to jank. When rendering Web pages, a late-to-render animation frame is completely dropped. In organizations, being late just means reduced effectiveness, a miscalculation and wasted energy.
As a result, organizations typically feel jank not as one specific incident, but rather as cumulative effects of multiple instances. Perhaps we can use this newly-minted framework to dig into these effects?
🔗 https://glazkov.com/2021/11/17/ooda-unrolled/
Stay tuned for next week’s episode of “Jank in Teams,” coming next week. Oh wait. Is that Thanksgiving week? Drats. Well then, maybe two weeks from now.