OODA for operational excellence

I think I’ll start with a story. The story that I wanna start with, it’s the complexity that is starting to creep in not just in the development world, but also the operations world. Everything is moving at a break-neck pace. We have Kubernetes, and that’s just the tip of the iceberg, which in itself is super-complicated… And hundreds and hundreds of other projects which keep shipping maybe every week. So how do you deal with that complexity? How do you just never mind about implementing it and shipping it in your infrastructure, but just paying attention to what’s going on? It’s impossible.

So one thing that I try to do is focus on the important stuff, and ignore the rest. But what is the important stuff? How do you know? Not to mention that you can’t always just pay attention to what is happening; you still need to get on with your job, you still have requirements… We know that some of them are silly and they don’t really make sense, and there’s a lot of energy that that will take.

So in my search for certain models or approaches that would help deal with the complexity and the ever-increasing speed was Agile. This was maybe ten years ago… And that worked well for a while. But how do you apply Agile to the world of ops and the world of Kubernetes, when everything is changing almost every day? No, actually it’s definitely every day.

[04:14] So in that search, I came across Ben Ford and commando development. He had this really interesting concept of OODA loop. Observe, Orient, Decide and Act. I had a very simplistic view of the OODA loop, and Ben opened my eyes. I was like, “Whoa, there’s so much to it… And are you telling me that I got it wrong?” Yes, I did. Not only that, but there’s so much to it that maybe can help us with the complexity, maybe can help us stay focused on what is important.

So I have Ben joining me today to talk a little bit about that. That was my story, Ben. What about yours? How is your story with the complexity, and development, and practices…? Tell us a little bit about that.

Yes, it’s great to be here. I love talking about this stuff, so I’ll happily dig in. I had a bit of a non-traditional route into technology. I learned to code aboard an amphibious assault ship when I was serving in the Royal Marines way back in 2003. I was on the way to Iraq, I was bored on the ship, and I was wondering what was gonna be next after my armed forces career… So I picked up a couple of books, one on Python, one on Linux, and taught myself to code, very rudimentary.

Fast-forward 5-6 years and I was working as a software developer, back in the day when you used to order a real server from people and have it installed into a data center… And the pace of getting a company up and running then was six months, probably a couple hundred grand in upfront cost… Markedly different from where we are now.

I was pretty happy being a developer. I thought my time in the Marines was a fun diversion that I had that maybe makes my CV stand out a little bit, but not very relevant for my day-to-day life. And then that continued for a while, and then I started to run into this complexity as well. So I had to go from being a happy, functional programmer, working in finance, to learning about DevOps, and learning about continuous deployment, and all of these other things.

And then that sort of also starts to come a little bit unstuck, because then you’ve got decision-making and strategy, and all of these things that you can have a really good CI/CD pipeline and a really fast feedback loop on the technical front, but if the business doesn’t have a way of holding the complexity within which it’s operating, well then you’re kind of in trouble, because decisions are wrong, or are not being taken…

So I guess at that point, maybe five years ago, I started to come across some authors who were applying concepts from the military to business. And that opened my eyes. I’d already started to see some links with rudimentary – I started to pick out some rudimentary links between Agile and the way we used to do things in the military, and then these guys started writing about it from their experience. I only served for five years; I had an early career in the military, but never done any of the more command-based things. But these guys were writing about the principles of combat, and I thought “Yeah, you know, there really is something to this.” So I basically started pulling on that thread and I haven’t stopped since.

The OODA Loop is the concept that holds all of this together. It’s the concept that explains pretty much everything else, when you dive into it deep enough and you get beyond the superficial explanation. Even Agile has its roots in the OODA loop. Steve Blank, who wrote about lean startups, all of that stuff, 15 years ago - that all comes from the teaching of John Boyd. So OODA really is at the heart of everything. At the same time, it’s well-known, but it’s – it’s well-known as in it’s widely-known, but it’s not well-known as in it’s well understood. So here I am, to explain what I’ve found over the last few years of exploration.

[08:10] I’ve found that fascinating from the perspective of your course, the Algorithms for Leadership, which - I didn’t know at the time that I will have you on the show; I wasn’t even sure about when the show will start, or what it will be about… And as I start discovering more about that course and more about some of the concepts that you present… By the way, some of them are extremely compressed; and this is your word. So it took me a couple of replays just to understand what is being discussed. And there is so much to it.

People, when they think of OODA, they imagine those four words arranged in a circle, and there’s like an arrow that goes from left to right. And most people, that’s where they stop. That’s it. I’d like us to dig a bit more into that. But before that, I’m wondering if someone is listening to this and they’re wondering “Hm… Shall I spend the next hour listening?”, why would they care? Why would someone care about this? It is the complexity that’s the obvious one, but is there something else to it? I think there is.

I think it’s interesting to get that high-fidelity that tends to be lost over time, and I think you’re doing a very good job of capturing it, not only in spoken form and written form, but also in a presentational form. That’s what really attracted me. You present these concepts really well. They’re incredibly compressed, because they may sound simple, but there’s so much behind them. And I like how everything unpacks. So why do you care about this stuff as much as you do?

That’s a great question. So my journey in technology took me into functional programming. So I went pretty deep down the rabbit hole of pure functional programming, and I became a Haskell programmer, and built systems with Haskell… Which requires a mindset shift. You choose a different set of very fundamental abstractions when you program in a functional language. So I wanted to find a similar small set of abstractions that compose well, that are cohesive, and that all kind of pull in the same direction. And for me, the OODA loop is… Because it’s so fundamental - like with functional programming, you’ve got very, very fundamental, well-defined, small building blocks. And because they are that shape, you can use them absolutely everywhere. So the way I think of stream programming now is the same way as I think of adding numbers, because that’s the same underlying abstraction from the programming sub-culture that I come from.

And the way I think about handling complexity, at both a strategic and a tactical, immediate feedback loop levels - I now have the same mental models to think about both of those, and to teach… So it’s one mental model that you can apply to multiple things, and that’s why it’s so compressed. It’s so compressed because you unpack it and it unpacks in a different way in one context, and a different way in another context, but it’s the same thing underneath.

I think that’s super-powerful. If you think about Linux and UNIX, and how it stood the test of time, those really simple tools that compose in infinite ways… And I think most people think they’re just one OODA, but what blows their minds is there’s OODA loops inside OODA loops; turtles all the way down. Think about that, but replace turtles with OODAs. I think it’s amazing how well they compose and how well they apply to not just development, but also operations, and most importantly, which was my entry point, business. That was like a whole new – like, “Hang on… Do you mean the same problems that apply to ops and dev apply to business as well?” And the answer is yes.

[11:57] And you go a little bit into that, because there’s so much - like, team of teams… I think that was like a super-powerful concept. Red team thinking, and a couple of others… But I think I’m already jumping a bit ahead of myself… Because the one word that kind of unifies them all from my perspective is the operational excellency, or operationally excellent. Which one would you pick?

I would call it operational excellent. In fact, I was toying with that very phrase for quite some time to explain what all this stuff is. The OODA loop is observation and orientation, which is information coming in, and then it’s decision and action, which is the kind of execution side of things… And those things together, having a good OODA loop and having an understanding of how these OODA loops compose actually is operational excellence. You’re operationally fit for your environment and you evolve with your environment because you continually learn from it and adapt to it. And that’s the definition of agility. So operational excellence, agility with a small a, and not consultants in sight - take your pick, but it’s the same concept.

I really like that. I really like that because it’s a simple concept that composes in specific ways, and the excellency is in how you compose that. And by the way, there’s not consultant that can tell you how to do that. It’s a discovery process. It always depends, it always changes; guess what - whatever works this year will not work next year. And unless that’s in your DNA as a company, as a team, good luck to you.

Yeah. And that’s where so many businesses come unstuck. I don’t know where I heard this phrase - I will always say that it’s not mine, but I do really like it, so I say it a lot… A digital transformation is what you need when you’re falling asleep at the wheel of evolution. You’ve forgotten how to build these structures and communication systems - and algorithms for leadership, as I call them - you’ve forgotten how they work, and they’ve fallen apart, and you’ve got poor commander control of your company, or whatever dysfunction you have… Which means that you are no longer adapting to your environment, which means that you drift further and further away from being operationally excellent, which means that you drift closer and closer to company and organizational death, eventually.

When I joined your course, typically they happened in the evening for me, being based in the U.K. So I think 7 o’clock plus, after 7 o’clock; 7 to 8, 8:30… And after a long day, you can imagine that maybe sometimes I’m not paying as much attention as I would want to. That’s why recordings - they’re amazing. So when you mentioned that phrase, I really loved it; that woke me up. I thought, “So hang on… Do you mean that you don’t want digital transformation, because it’s maybe too late, and you’re just trying to rescue something? What about learning about adaptation rather than transformation?”

So I took a note, and I thought “When my mind will be rested, I will unpack this.” I’m still to go back to that. I think there’s so much there.

Yeah. So just to dig into that a bit more… The other problem that digital transformation has is that it’s implemented top-down. So the leaders wake up one day and they go “Oh no, we’ve lost the ability to keep up with the tech upstarts.” Banks are a classic example. “Oh no, Monzo is a thing, and Starling is a thing, and we’re a big bank and our technology is terrible, and it costs us orders of magnitude more to develop technology.” So the leaders turn around, and the shiny-suited consultants turn up, who claim to be able to fix their problem with a simple toolkit. And what happens is they say “Right. Great. We’ll have some of this digital transformation, please.” So they try and introduce it top-down. But the problem is that anything like this has to be implemented bottom-up. It has to be implemented at the point at which your people are in contact with the environment. They are the ones that are shipping code, the ones that are talking to customers.

[16:07] So the problem with bigger organizations isn’t really the digital transformation at all, it’s the fact that there is no link between top-down and bottom-up. They’re two different worlds, they can’t talk to each other, and no amount of millions of pounds spent on consultants is gonna be able to fix that. And that’s the kind of inconvenient truth that the Agile industry as a whole - with a few exceptions, but the vast majority of simplistic frameworks and nonsense that are sold to senior leaders that don’t really have a clue, that’s why the money gets wasted, because of that fundamental disconnect of pushing something down from the top, versus having something emerge from the bottom.

Okay. So let’s imagine that a big company approached you, saying “Hey Ben, we are in the pickle. We need your help. You really know your stuff… Help us.” What would you do?

That’s a great question. That’s a really, really good question. And there’s several problems with that. One is that somebody who comes to an organization assuming that they know the context of the organization is gonna be bitterly disappointed. So the first thing is that I would have to tell them “Look, I can’t fix your problems for you. I can give you some mental models, I can give you some abstractions and some understanding about the real mechanisms of what’s going on… But if you’ve been having people in shiny suits turning up to your office and saying that they can fix your problem for years - that’s not me. I’m not gonna claim I can do that. What I can do is offer different fundamentals, different abstractions, and I can offer some external perspective.” Because anybody who’s trying to change a system from within a system is necessarily looking in and down. They are part of the system; they care about the progression of that organization. Whereas if you get somebody who comes in as an external perspective, they can bring some detachment from there and they can say “Well, you know, you’re treating this like X, Y and Z. But actually, have you considered that it’s maybe A, B and C?”

So I think that’s what I would say… I would hopefully make them understand that their mental models about what is possible in the world of technology are perhaps a little bit out of date, and you need to give your organization some space… Because there’ll be people in every organization - every big organization that’s failing at IT, you’ll have passionate people in your organization who actually are very current, and very aware of best practice, and are very aware of new tools and new opportunities, but they’re just drowning in this overwhelm of top-down pressure. So I think I would be almost like a catalyst to help free those people up and to help build the links of communication between top and bottom by having a common set of mental tools.

So the way I hear it is you’re almost saying that you would be focusing on the operational excellence, which is the combination, first of all - you need to know the principles, and then how do you combine them and how do you make them relevant to your org… And I can’t really tell you how to do that, it’s something that has to be emergent; we need to discover that. And more than me, you need to discover that. You need to figure out what works for you. And all I can do is advise you when the things are combining in ways that make sense, versus when they don’t make sense. And I think what we’re touching up on here is a little bit on the entropy as well, that you’re trying to deal within a system. It’s too chaotic. Nothing makes sense. Things are just breaking down left, right and center… And we’re talking about the interactions, the communications. Don’t think technology, because technology is a people problem, an interaction problem. You can make your functions run in milliseconds - what good does it do if they can’t be sold, or people don’t find out about them? It’s like an irrelevant thing.

[19:58] I think that’s a really powerful thing, in that you’re focusing on the interactions, principles, of course, and the interactions between those principles, and the applicability, I guess, to the specific context which needs to be discovered. And by the way, that changes all the time.

Yeah. An analogy I use all the time is martial arts. I a bit lapsed at the moment, because of injuries and the pandemic and stuff, but I used to train in Brazilian Jiu-Jitsu, and there was no way that somebody could just give me a book on Brazilian Jiu-Jitsu and say “Alright, go sit in your garage for six months, and I’ll see you in six months and you’ll be a black belt.” You have to actually train in the situation that you’re learning the skills. Even just watching an expert do it is not doing it. So you have to do the thing in order to learn the thing. And you learn by doing, and you do by learning. And learning Brazilian Jiu-Jitsu and rolling with a higher belt or a lower belt is an OODA loop. It’s exactly the same mental abstraction of Observation, Orientation, Decision and Action. Actually, there’s a different pathway through OODA, which we talked about on the course, which is actually far more relevant to immediate combat-oriented things like martial arts… But for the purposes of this, it’s an OODA loop.

Now, there’s two things which I’d like us to get to. The first thing is the real OODA loop diagram, the one that you haven’t seen, and then Ben’s OODA loop diagram, which I think is the best one you’ll ever see and you have definitely not seen. So even if you’ve seen John Boyd’s original, this is better, up to date, and I got so much value out of it.

And the second thing - I would like us to walk a bit down the stack. So we go from business, we go strategy, operations, tactics. I would like us to spend a bit more time on the tactical area, which is where you have a lot of experience, right? The real combat experience - I’d like us to spend a bit more time there.

We’ll be taking a closer look at the OODA loop now, the components. How does it apply to the high-level, to the business, and how do we traverse the stack all the way from strategic (Is this strategic?), operational and tactical.

That’s right, yeah.

Okay. So I’m thinking about the business, maybe the management, products… What is in the middle?

I have the middle layers as kind of like the organizational level. So the strategic – and you can look at these as timeframes as well. So the strategic timeframe is whatever the business-level decision-making cycle is. The operational level is how yo decide to integrate what the business wants with what the people that do the work can provide, so sequencing and making bets and biting off projects, and then the tactical side is the days to weeks of building, shipping, getting feedback/building, shipping, getting feedback. That’s how I would split it up.

That makes perfect sense. And the ops people, the dev people, the DevOps people, mostly individual contributors - they tend to be at the lower tactical side, the people doing the actual work. Then you have the more strategic ones at the top, which is your senior staff – is it staff? No, it’s not staff. What is at the top, top level? The C-suite? That’s too high up. That’s the tip.

[24:11] Yeah, so I guess like your VPs and directors, or the middle tier… I mean, it depends how big the company is, I guess. If it’s a startup, then the lead developer is that person in the middle, and maybe they’re the marketing, or something like that. But that middle layer is the integration of a grand strategy which has to be necessarily a little bit vague, because you can’t really project out six months about specific, concrete things that you’re gonna do… So it’s turning those strategic goals into concrete, specific things that we wanna achieve, and sequencing the work to achieve them. That’s the operational level for me.

Okay. And how do the components in the OODA loop map to the high-level, and how do they map, like, OODA loops within OODA loops as you go down through the levels, all the way to the tactical, the day-to-day?

So we’ve got the traditional OODA loop, the full John Boyd diagram. One myth in the OODA loop is that Boyd never drew that simple circle with OO and D and A on it. He never drew that. He drew the version which is, I guess, the next level down that you come to, which is observation feeding forward into orientation, which feeds forward into decision, which feeds forward into action, and then a whole bunch of feedback lines that go from action and decision back into observation, along with outside information, unfolding circumstances and unfolding interaction.

And then there’s these two other funky little lines called implicit guidance and control, which are how your orientation shapes your observation, and how you can sometimes by-pass decisions with direct actions when you’re in a domain of familiarity. So how does this map to the different levels that we’ve just talked about?

If you think of a company as an entity, almost like an organism - I’m just gonna call it an organism, because actually organization and organism back in the 15th century were the same word… So let’s consider this as kind of like a biological entity that’s separate from its environment, so it needs to take energy - and in the case of an economy, that’s money - and it needs to turn that into an internal structure that will keep it self-sustaining. And it does that by deciding how to use the resources that it has in such a way as to turn that money into more money by paying people to do work, and selling the results of that work.

So the strategic OODA loop of a business is observing the macroeconomic conditions, how the environment is changing, how the tech ecosystem is moving, how customers are changing - all of those things, all of those form the observation. And then how the results of your products are services are landing with the market. The orientation is then how does that change what the business understands about its place within the ecosystem and what it wants to do. Decisions are the kind of big strategic decisions that you get from companies. You know, “We’re gonna try and enter this market” or “We’re gonna exit this market” or “We want to try a different way of doing this, or a different way of doing that.” And then action - well, action is not something that’s directly done at that level. Action is something that is – individuals take action; companies do not take action. So that is when you then start moving down the stack, and those decisions then need to be turned into actions that are atomic and that individuals take, somehow.

The way I think of actions, it’s almost like the – well, one of them would be shipping. You’re shipping value all the time, which - it’s almost like at the end of taking that action, unless whatever value you have built, you’re getting it out there so that people can use it - customers, end users can use it - your action is not complete.

Yes.

[28:02] The more you can act, the quicker you can act, the better off you are. But it’s not just the action part, is the loop as a whole has to be complete, because it’s not sufficient to act. But there’s something really important which I took away from your course, which was “Don’t start with the observation, start with the action.” Why is that?

So when you dig into – bearing in mind that Boyd passed away in 1997 and he was the most active during the ’80s and ’90s, I guess… And you consider how far science and understanding of cognition and complex systems has moved on since then, it still absolutely astonishes me that the OODA loop maps so well onto all of this emergent research.

So the reason I say we should start with action is because that’s how cognition works. You and I are sitting here, and we are seeing each other because we’re looking at screen, we’re seeing the diagrams that I’ve written, feeling sensations as we sit on chairs and whatnot… And all of those sensations need action in order to work. So we don’t see anything properly unless we’re moving our eyes slightly, especially if that thing is moving. And those actions are unconscious, but they are almost required to kick off the process of cognition.

So if you’re sat in an environment and you’re sat absolutely still and you’re not allowed to touch anything and you’re not allowed to look at anything - well, you can’t learn anything about that environment. You have to take action in order to kind of set off the ripples that you then start to detect in the rest of the OODA loop. And the diagram that’s your favorite of the ones that I’ve drawn - action sets an expectation. That’s where you start to see where this kind of intermingling of all the different parts of the OODA loop, and the fact that it’s not just a circle through Observe, Orient, Decide, Act… Because action itself, the process of even taking an action, creates changes in your orientation, which then shape your observation, and then by the time you observe the outcomes of your action, what you observe is different based on your expectation. So we just cannot avoid being entangled with our environment in that way.

So to those that are listening to this - just listening to this, something’s missing, right? You feel like “Where’s this diagram? What are you talking about?” So unless we publish the diagram, unless you look at the show notes, unless someone drew the diagram, you couldn’t really imagine what we’re talking about. I mean, you could, but it would be an imperfect image of what Ben means or what Ben refers to.

Of course, we’ve shared the diagram, so look at the show notes if you wanna see it… But more importantly, it proves a point, in that if you can’t see it, is it real? Does it even exist? Maybe we’re talking about an imaginary diagram… Which we’re not, by the way. It’s real, and it’s very good.

Yeah. And actually, Boyd’s OODA diagram - from my understanding, he was kind of pushed to draw this. Someone said “Look, you need to write it down.” So Boyd transmitted most of his learning through an enormous six-hour lecture that he used to go and give to generals. And that encompassed the history of military doctrine, it encompassed a lot of science, he was big into physics and understood Heisenberg’s Uncertainty Principle, and Gödel’s Incompleteness Theorem, and the Second Law of Thermodynamics - those are the three pillars of his OODA loop. And when he was asked to draw this stuff - bearing in mind this was the mid ‘90s - the diagram that he came up with is constrained by the medium with which he could transmit it back then. So that’s one of the benefits that we have now, of FIGMA and SVG and better mechanisms for drawing things.

[31:56] As I’ve mentioned before we started, I’m playing around with some 3JS so I can really properly dig into how these interactions work… So in some ways even the original diagram that he drew was an abstraction. It was an incomplete picture of everything that he was talking about. You read into many other people that had studied Boyd and you get a far more nuanced and complete picture than you ever will just looking at his diagram.

I think that’s super-powerful, and I’ll take it one step further. First of all, you have this static thing, stuck in the 1950’s. The best it could be for the time given the constraints. Then we have your diagram, Ben, which really is a work of art; you have to see it, it’s amazing. There’s so much information there. It’s almost like you need to read the background to understand some of the relationships, and the shapes, and the lines… It’s just amazing. But there’s the visual element as well, which it doesn’t have; it’s static. What about the motion, the time?

Now, let’s take that a little bit further. This is me dreaming. Five years from now, ten years from now. It may never happen. What if you could see these loops happening in an org, and the actions being mapped to these things, so you can almost have an appreciation of how the different parts of an org interact? Imagine whatever happens in your org being represented in these diagrams; all the commits, all the code going out, all the bugs coming in, all the money going out and coming in. If you could visualize that, what would that mean for your business? Just imagining that - wow. I would love to be part of that one day. I think it’ll be amazing.

Yeah. And that’s the thing - if you look at the business through this lens of abstraction that we’re talking about, you have the opportunity to build something like that, because you can express those abstractions. I’ve given presentations about how similar the OODA loop is to things like event sourcing. Because observations are events, right? They are concrete things that have happened. We put subjective filters on those things, but they are concrete things that have happened in the environment.

Likewise, the left-fold of the events that create state in event-sourcing systems is an orientation of a form, right? It’s “How do we integrate the observations or events that we’ve seen in our environment, and how do we integrate them with the state or internal orientation that we have, and turn them into a change in that orientation, a change in that state?” And then the decision and action side of things is the command side of event sourcing.

So I actually think that with the rise of event-driven architectures, and you mentioned Kubernetes in the chat before this - all of that data flowing through the systems that we have now, it is actually within the balance of possibility that we could have a real-time 3D time-based picture of the internal workings of our OODA loop. And I agree with you that I think that that would be incredibly powerful.

Statement of facts. Things that have happened, with certain properties, and deriving relationships from those properties and visualizing them in a compressed format - that’s what an OODA loop is. You zoom in, you zoom out, you have the high level, you can dig into specific things, even individual events if you want to… And I think we’re getting there. I think the building blocks - I can almost start seeing them shaping. I think Concourse was the first continuous integration system that put the pipeline at the front. You just threw some YAML at it, and it would produce this nice pipeline that you could make it so big that it would crash the system… But it was infinitely scalable. And we have seen this, for example, in GitHub Actions, Argo CD with workflows… I think this is really well where you start thinking about visualizing pipelines, and it’s not just CI/CD; it’s not just running your tests, your builds, it’s not just pushing code out there. It can be used for so many more things. And I think the concept is really powerful.

[36:17] And then you have your UNIX tools. It’s all based in the pipes. Combine them. And the relationship between the different – not just the individual blocks, but also imagine the links. They don’t have to be straight, they don’t have to be solid. You can change the shape of them, you can make them thicker, thinner, whatever. And I think a little bit of this, which is what gets me excited, is that we have seen this for years - actually decades, now that I think of it - in the Erlang VM. All the message passing, all the interactions between the different components, the trees of the processes, the applications… Everything. The crashes - when something would crash, you could visualize that in the observer, when different applications would go down.

You love functional programming… Well, I love Erlang. I haven’t tried Haskell. I should check it out, for sure… But I can see the intersection of all these things. And isn’t it nice to explore and experiment? What should work be, Ben? What do you think that work is, at a very low level, at a very basic level?

That’s a great, great question. And just to build on your point earlier about Erlang - we look at this from a technology and a developer-centric viewpoint of pushing code out and shipping… And that’s the decision and action of an organization’s OODA loop. But there’s a whole load of people who also look at the inward sense-making, situational awareness part of that loop, which operates in exactly the same way. That’s people that look at marketing, and attribution, and data, and understanding the effect that the organization is having on the environment in some way.

So as much as our CI and CD reflects how we think about shipping code, you can use exactly the same abstractions to think about sensing the organization’s effect on the environment as well. And what work should be is that system understood as a cohesive system.

As a developer, you shouldn’t be constrained to thinking that you’re done when you ship. You should have a visceral, embodied understanding of what happens to that piece of code, what difference does it make to your customers. What ripples do you send in the environment once that feature or that change lands? How does that make you better at deciding what to build next? That’s the OODA loop. That’s pure OODA. And having the integration of those different understandings at different levels is exactly why I think OODA is such an important concept. Because - to go back to your original point about complexity - the more complex an environment gets, the more important you need to have this internal/intangible ability to operate and ability to sense your environment. Because the further you get away from that, the more vulnerable you are to the people that do or the companies that do build that ability.

That’s right. A comprehensive understanding, feeling that what you do matters, understanding “Where does it fit what you do?” Experimenting. You’re not working, you’re experimenting. You’re trying to figure out how what you do works. And a very, very small slice of that is shipping. But I would even say it’s not even the tip of the iceberg. I don’t know what to compare it to, but it’s so small, so tiny. And this is something which I am very passionate about. Even though we call this Ship It, it’s insignificant in the big scheme of things. And my mission is to make you understand, listeners, how small and insignificant it is. It’s essential and important, but it’s such a small piece. And don’t think that if you ship, you’re done. No, no, no. It’s not even the beginning.

[40:13] I really like your diagram - this is another one, about perception; the ripple effect. And it applies so well to this, because it’s really difficult to understand and to map your action to something that someone else does, like your end users do.

Yeah.

You have a better way of explaining this… Maybe we’ll put that diagram as well. You know what - maybe at this point it’d just be easier to join the course, right? I think it’ll be easier, because there’s so many other things; I’m picking and selecting, but it’s so compressed. It just makes sense as a whole, and the conversations - I think they’re the most valuable ones. So if you think this is good - well, you should see some of the conversations part of the course, which were my favorite part of it. The diagrams as well, but the conversations - unique. And you cannot recreate that, because it just happens based on the people that are there, and how they feel. Some were tired, like me. Other switched on, like Ben. But it was a good mix.

It’s a very intangible thing, isn’t it? We’ve got a bunch of individuals, a bunch of people there, with their own energy and their own experiences of that day, and that creates an intangible – we compose those people together in a group and then we have a discussion, and that creates an intangible kind of understanding of the concepts that we’re talking about, that lives within that group. And then that groups goes away, and talks to other groups, and it spreads, or it doesn’t… And different people bring their different perspectives… I mean, the most valuable thing to me of exploring all this stuff is what I learn from people who have a different understanding, or a different depth, or a different perspective. And I’ve got probably about six hours’ worth of YouTube conversation that I’ve either been part of or joined, that has built into this kind of understanding. This conversation has opened up a few more things, like the Erlang VM; I hadn’t considered that one before. So yeah, it’s great. You just have to dive in and explore.

Talking about diving in and exploring - we are going to talk about the recommendations that Ben has around the books, the videos… Basically, all the follow-up material that you may want to look into, that goes really well with this conversation. So we can start with books, or YouTube videos… Wherever you want, Ben. Take it away.

Cool. Let’s cover books first. One book that I’m overdue a re-read on actually, which is really the book that started – well, it didn’t start me on the journey, but it really made some links fall into place for me was Team of Teams by Gen. Stanley McChrystal. That is just an incredible, nuanced overview of what an organization has to do when its environment is moving faster than it’s capable of dealing with. And I can see that Gerhard has a copy.

[44:15] I had to.

Yeah. It’s a great book. And the follow-up one – so Team of Teams is the conceptual “Why this is important.” It’s about the dynamics. And then the follow-up, One Mission, is a bit more about the specifics. So those two are very good. Extreme Ownership by Jocko Willink is a must read as well.

The Fundamental Principles approach I agree with. I’m not sure I completely agree with the principles that they’ve picked out as the most important.

Turn the Ship Around is also very good, on servant leadership and mission command… Although none of these books mention the concepts that I talk about by their kind of conceptual names. They have their own models and whatnot.

Red Team Thinking… You know, the whole point of the course is that leadership is as much of a system as it is a skill, and Red Team Thinking is a fantastic set of tools for doing the strategic leadership system. It’s a bunch of communication protocols and practices that mean that you get this better situational awareness at a strategic level. And then I’ve got a whole bunch of books that we probably don’t have time to dig into here, about cognition and – I will mention one that I read recently, “A Thousand Brains” by Jeff Hawkins, which is about the mechanics of cognition from his research at Numenta… That’s an amazing book. That will change the way you think about not only what goes on inside your ears, but how the concepts can apply to businesses as well.

And there’s another book which I would like to mention - it’s by Ben Ford, which is “The OODA Loop according to Ben Ford.” [laughter] That will be a self-published book, I’m sure. Maybe Gumroad. I’m really looking forward to that… Which will be the print version of the course maybe.

Someday.

Someday.

It might be a live, online, 3D diagram illustrated version of the course perhaps… But yes, I definitely have something like that in me at some point.

Yeah. I’m really looking forward to that. In the meantime I’m going to read all the other books. That’s my plan. That’s what I intend to do; talking about turning the ship around… Which is, by the way, a great book; I read it and I can definitely recommend it as well.

In the meantime, if you’re not into books, Ben has some amazing YouTube videos. So if you think this is good, which it is - again, let’s be honest - some of the videos that Ben has are really good. You have also a show, The OODA Loopers, or The OODA Something…? Can you tell us more about that?

So one of the things that’s come out of this exploration for me is meeting other people that are interested in the OODA loop across a variety of different fields, including serving police officers, and firefighters and whatnot… And the way we’ve been interacting has - luckily, for everyone - been in the form of videos; so conversations like this between two and seven people, I think, bringing people in with different perspectives and trying to integrate those perspectives and those experiences - many within the tech industry - to attain a deeper understanding of OODA Loop. Because it’s the concepts that are really important; it’s not what you call it, it’s not how you draw the diagram, it’s the understanding that you extract from it and the kind of compression that you learn in order to apply the ideas.

So I’ve been collecting some of the best resources that I’ve found and conversations that I’ve taken part in into a YouTube playlist which is probably about eight hours’ worth of video by now… Because at the end of the day, no matter how much you listen to somebody that knows what they’re talking about about any subject, you still have to dive in yourself. You still have to make your own mental links, you still have to build your own understanding, build your own mental models, try things out, break things, put them back together again… And there’s really no better way to do that than this format that we’re having here, and conversation… And that’s what I’ve been doing quite a lot of lately.

[48:08] So if someone wants to start doing, implementing all the learnings, all the principles, where would they start, or how would they actually start? Step number one. Step number two.

I mean, that’s gonna be very contextual compared to where you are. Let’s take a few hypotheticals and thought experiments maybe. So if you’re in a startup that’s growing rapidly and is now lacking structure that you would need in order to scale, which happens all the time, especially nowadays as it’s possible to finance business and grow it so much more quickly… Very often those business, they - and this is a mistake I think many tech businesses make - look at the world through a DevOps lens, or they look at Lean, and all these things. And actually, when you take a step back, those businesses - the ability to build and ship code is very rarely the problem anymore. The tools and the infrastructure that you have available to do that now - you could build the beginnings of a company in a weekend, because you can use things like Vercel, and GraphQL, and Hasura… You’ve got zero ops, zero requirement for any ops. It’s just literally build code and ship, build code and ship.

So the problem that we have now is that those companies grow to a certain size, and then the internal communications protocols and structures don’t keep up. So that’s where I would urge people to start looking now, is to take some of the resources that I’ve shared, have a look at the YouTube videos… You know, take my course and understand that in a world of complexity it’s the whole system that you need to consider, rather than thinking that you need to fix this little bit that you think is broken. If you’ll fix that bit, you’ll have a knock-on effect to something else that needs to be fixed, and you need to get and keep ahead of that in order to survive in this exponential environment that we’re in.

That’s something which - I wanna say I was disappointed, but it was like an eye-opening moment. There’s no silver bullet here. There’s no set of things that you can take, apply as they are presented and you’ll be successful. That’s not how this works. You need to understand the principles, you need to try a few things out to see what sticks and what doesn’t, and iterate from there. It’s a continuous refinement process, and there’s no book that can do that for you, no course, nothing. It’s you. It starts with you.

So step one, become aware of these things. Step two, maybe accept that you may want to start applying some of these things and see what stands out… And step number three, start doing it. And go through it really quickly, because guess what - you have to go through these steps over and over again, almost like an OODA loop. Not once a day. Many times per hour. Maybe even more often. There’s no time period which is right or wrong for an OODA loop, by the way.

No, absolutely not. Because even if you do build this kind of internal fluency of communications - well, you’re changing, your environment is changing; you’re adding new people, they’re coming in with their own ideas. People leave. The system changes. Even in the Second World War, when the Germans came up with the Blitzkrieg concept and they rolled over Europe - well, guess what. At the time, the U.K. was building a special operations executive, and they built small, compact teams that could go and do exactly the same thing to the German war machine, and that’s what they did.

So it’s this constant cycle and constant process of – optimization is not the right word, because that implies efficiency. But it’s this constant optimizing your effectiveness for the environment. Even if you employ somebody who has done something very similar to what you’re doing in your company right now, and you ask them what should you do, their information will be out of date; it will refer to a world that doesn’t exist. So you just have to build these structures yourself. There’s no way around it.

In other words, don’t hire the expert. It’s a lie. It’s contextual, right? The expertise is contextual.

[52:13] It is.

And unless that expert is willing and open-minded to change his perception and to learn with you, it’s for nothing, all that expertise. You can’t transplant ideas, you can’t take guilds or squads or whatever you wanna call them and make them work in your company as they are. That doesn’t happen, and that’s not how it works. And whoever tells you that’s how it works, I would take it with a grain of salt, or two, or three.

And not give them any money.

Exactly, yes.

That’s a good point; expertise is still important, because – it’s like the process of evolution. Evolution only works when there’s some genetic material to pull apart and put back together, and in the knowledge economy that genetic material is expertise. But the thing that we forget is that expertise is contextual, as you said, and it’s the pulling apart and putting it back together that’s the most important thing. And if you just try and blindly apply stuff that worked… I mean, this was true ten years ago, but it’s even more true and even more critical now to understand. If you’re trying to blindly apply stuff that worked before, it won’t’ work as well as you hoped, and you won’t have any clue. Whereas if you build the capabilities and the communications and the decision-making processes and all that stuff that does allow you to sense your environment - well, if it doesn’t work, it doesn’t matter, because you’ll be able to adapt and overcome.

Ben, this was a pleasure, a genuine pleasure. I’m seeing this as the beginning of something. I’m seeing this as a loop that will continue. I’m thinking six months from now I would love to catch up again, on the same show maybe, and see where we are then. See what we have learned, see what we have taken apart, what we have put together, and most importantly, what we have shipped… Because I know you have something really special in the pipeline. We should not tell the listeners what it is; you should follow the journey closely if you’re really curious. And if you’re not, that’s okay; it’s not a problem.

But I’m really looking forward to speaking to you again in six months, roughly. It’s just a guideline. Thank you, Ben. This was great.

Anytime. It’s been great. It’s great to have you on the course, it’s great to essentially share this journey of understanding with you. This conversation has been fantastic, and eye-opening, and yeah, I’m definitely up for doing another one.

Thank you, Ben. Have a nice evening, a nice day, morning, whatever it may be, and keep iterating. Keep looping. Get better. See you, everyone.

Thanks, everyone. Bye.