I like where you’re going with this, but having worked a lot with OODA and other feedback mechanisms applied to organizations, I’d like to share something I’ve learned that it reads to me a bit like you may be missing or not fully grasping.
Again, this may not be how you are thinking, but this sounds to me a bit like you are thinking as if OODA can be reified rather than it being purely a process. Certainly like any process it must be embodied in an organization, but there’s a big difference between carrying out a process and having it exist. OODA loops are not created or setup so much as they emerge from individual actions guided by what OODA suggests you should do next. As an implementer I’ve made the mistake of thinking I could just “set up OODA” (or in the organizational process I typically think of this as kaizan in the sense used in the TPS) by telling people about it, scheduling meetings to carry out the steps, etc.. Yes, you have to do those things, but it’s far more important to be cranking the gears than it is to put the gears in place.
So again I basically agree with you, but want to make clear in case it isn’t already that very little of the challenge is noticing and wanting to see OODA used and most of it is doing the things to work through it.
Agreed. I was thinking that an OODA loop (or something similar) is an interesting lens with which to view the process of trying to solve the problems of AGI. Mainly as a guide for what might be lacking and where you might put your efforts to get new information or improve the flows of current information.
I like where you’re going with this, but having worked a lot with OODA and other feedback mechanisms applied to organizations, I’d like to share something I’ve learned that it reads to me a bit like you may be missing or not fully grasping.
Again, this may not be how you are thinking, but this sounds to me a bit like you are thinking as if OODA can be reified rather than it being purely a process. Certainly like any process it must be embodied in an organization, but there’s a big difference between carrying out a process and having it exist. OODA loops are not created or setup so much as they emerge from individual actions guided by what OODA suggests you should do next. As an implementer I’ve made the mistake of thinking I could just “set up OODA” (or in the organizational process I typically think of this as kaizan in the sense used in the TPS) by telling people about it, scheduling meetings to carry out the steps, etc.. Yes, you have to do those things, but it’s far more important to be cranking the gears than it is to put the gears in place.
So again I basically agree with you, but want to make clear in case it isn’t already that very little of the challenge is noticing and wanting to see OODA used and most of it is doing the things to work through it.
Agreed. I was thinking that an OODA loop (or something similar) is an interesting lens with which to view the process of trying to solve the problems of AGI. Mainly as a guide for what might be lacking and where you might put your efforts to get new information or improve the flows of current information.