Hacker News new | ask | show | jobs
by ghgdynb1 1918 days ago
I'm not sure, I'm not an expert in this and I've never been in the military.

However, I bet there's little to nothing uniquely good about OODA over the alternatives you mention. My guess is that having a standardized rapid decision making framework is valuable compared to the frantic scramble that might take place otherwise.

2 comments

> My guess is that having a standardized rapid decision making framework is valuable compared to the frantic scramble that might take place otherwise.

Having been in the military and received specific training on tactical decision making, I can say that this is a pretty good take on why OODA is taught.

When you're in any situation where you need to maintain positive control on the outcome, the biggest problem you can run into is when the situation changes in an unexpected way (insert classic Napoleon paraphrase "Plans are the first casualties in contact with the enemy"). The reason why the OODA loop is specifically used, rather than other permutations of the same idea, is that it's very efficient. For the classic HN crowd, a good analogy or application of OODA would be a PID loop, or any other event-driven feedback system.

Observe: has the situation changed? If not, continue with the current plan, else orient.

Orient: how can we change to match the situation, given who we are and what we're doing? If there are no positive changes to make, keep observing, else make a decision.

Decide: can we make a decision based on our new orientation? If not, return to observe, else act.

Act: perform the decision, then return to observing, paying special attention to the outcome of the actions.

Using this loop properly, at each stage you're still ready to go back to observing, and less likely to get mired in back and forth decision making without a solid reassessment.

This thought pattern is especially helpful in small team leaders, as they often have the flexibility and direct observational abilities to make full use of the information at hand. It tends not to work as well for single individuals and large organizations (in my experience), for individuals because of the incomplete information, and for organizations because of the signal delays in information and enactment.

A couple of additional benefits of OODA loops, not editing my original because I'm on mobile:

It really helps prevent micromanaging, because it encourages the team leader to only change orders in response to a change in what they've observed.

It's very useful in after action debriefing ("debugging" for the HN crowd), because specific questions can be asked about where in the OODA loop a fault occured. Did you observe something incorrectly, or miss noticing a key detail? Did you incorrectly orient yourself because you didn't understand the purpose of what you were doing? Did you make a bad decision, or the wrong decision? Did you do everything else right, but your team failed in taking action correctly? Utilizing this framework gives granularity and introspection to you decision making process.

It prevents undermanagement, as you feel compelled (and justified) in responding to a changing situation, rather than fighting with yourself about taking action.

"after action debriefing" = retrospective. A critical part of agile processes that's often ignored. It permits not just the examination of the product under development, but the processes that are in use.

It's a crucial difference between most organizations and proper "learning organizations". Most organizations (here I mean from team on up to large corporations) do not sufficiently introspect and retrospect to discover their own flaws (and we all have flaws). Learning organizations incorporate those two activities into their culture and methods in order to properly react to their competition and satisfy their customers.