| The OODA loop is explicitly as you said > Observe - Orient - Decide - Act The "Orient" step is usually done inside of your existing mental framework (Boyd is pretty explicit about this, see the blue box in your linked wikipedia article). Now if you are a great troubleshooter operating in your field of expertese, your "orient" step (and mental framework) might be sufficient to find and solve the trouble. Think an experienced engineer noticing some issues in a junior's code submission. But OODA is not so good for solving problems where you need to extend your mental framework. Your proposed: > Observe - Understand - Plan - Do could very well be a good approach, but it is not at all OODA, especially if the Understand phase involves a re-evaluation of your mental framework for the problem. Hence all the "whys". You are questioning the situation and the way you think about the situation. |
OODA is often thought of in a "do or die, moments count" context (given it's origins...) where learning lots of stuff is often impossible hence irrelevant. But with a longer time scope you can learn more. And given 10 minutes a person familiar with the environment can learn a lot about an issue, without having solved it necessarily.
Applied to troubleshooting, so often the Decide and Act bits are about gathering more information! Hence my "logs" or "expt" examples. Maybe it is breaking out a debugger, or gathering stats on A vs B, but each Action gets one step closer.
The main reason I like to think of it this way is to prompt "stepping back". By being able to say "Where am I at in the loop?" it gives permission to yourself to mentally step back from the coalface for a minute while still not giving up on the issue.
And every time I have seen successful leadership in resolving a problem it is effectively someone acting kind of like a "flight controller" making sure the workers OODA loops at least don't mess each other up and better yet are collaborative. IE keep them bubbling until someone says "I've got it!".
For me, OODA is valuable in the post incident review. You can lay out every step and figure out how to get there faster.