| Like a lot of thought models it depends how you apply it as to whether it is any use. OODA came from an adversarial practices. So often the intent is to be competitive vs the adversary. But if your adversary is inert - a problem to fix - then your time pressure to "get inside their loop" is gone. But of course you have other time pressures - assumedly management or someone screaming for you to fix it. Or maybe it is a memory leak that you know will hit a critical point. From my reply to a sibling comment: 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. |