“Feedback” is a rare word: Even though it’s widely used in business it hasn’t entirely lost its original meaning.

Among engineers, feedback (more precisely, negative feedback) is an essential component of control theory: Adding the inverted output of a system to its inputs stabilizes the system’s ability to track changes in input values. The equations used to express feedback describe and predict the behaviors of a wide variety of physical and natural systems.

Then there’s the way people in business use it: “Gimme some feedback.” It’s close enough to the mathematical meaning to be recognizable — you decide, act, and then listen, using what you hear to adjust how you act. It works.

Unless …

Since the speed of light isn’t instantaneous, all feedback channels are delayed. According to control theory, if feedback delays approach the speed with which system inputs change, feedback no longer stabilizes the system. Instead, the system becomes chaotic.

This isn’t an academic issue. It affects everything you do, because at its most fundamental core, leadership is about making decisions and turning them into action. Leaders don’t have to make the decisions themselves, nor do they have to do all of the acting, but they’re responsible for making sure decisions get made and actions taken. Good leaders do their best to make sure the decisions are wise, and the actions well-executed.

None of which will matter a bit if feedback delays become overly long. Once they do, the feedback will apply to a situation that’s no longer what it was when the decision was made. In plain English: Dawdling can throw an entire organization into chaos.

When you’re responsible for the success of an organization, nothing is as important as the organization’s ability to decide quickly and well, and act with speed and precision. As an IT leader this insight affects everything you do: operations, capacity planning, systems integration, new development, and the design of the underlying architecture that enables all the rest. Strategy is fun, but it’s your ability to execute that’s the gauge of success.

Which brings us to the “OODA” loop. OODA stands for Observe, Orient, Decide, Act. Developed by Colonel John Boyd as a fighter pilot and adopted by the Pentagon after the Vietnam War debacle made the need for radical change inescapable, it’s the basis of success in modern military planning, and probably in many political campaigns. It’s receiving increasing attention in business planning circles as well. (Thanks to Curt Sahakian for first acquainting me with this concept — if you’re interested, http://CEO-Notes.us/samplearticle.htm introduces the subject nicely).

A central tenet of OODA theory is that in any competition, whichever side has the shorter OODA loop wins. That’s an oversimplification, of course: No matter how fast your OODA loops are, bad decisions and inept action will still lead to failure.

Nor is OODA limited to direct competitions. Evolutionary theory and current ecological research demonstrate that species whose rate of adaptation is slower than the rate of change of their environment become extinct irrespective of competition with other species.

The success of OODA adds considerable weight to a number of ideas that have been simmering in business and IT circles for some time.

The first is the most obvious: Delayed decisions are by definition bad decisions. This doesn’t mean decisions should be uninformed and stupid … note that “observe” and “orient” precede “decide” for even the quickest cycles through the process. It does mean organizations must excel at recognizing when their information gathering and analysis reach the point of diminishing returns. Even more important, it means uninvolving yourself in most decisions, because if everything requires your involvement or approval, your capacity limits the speed of your organization’s OODA loops.

The next is well-accepted by now, although many IT organizations still ignore it: Projects should be short. No matter what you’re trying to accomplish, no planning project should be longer than two months; no implementation project should exceed six. This doesn’t limit the scope of your overall goals — it merely dictates how you go about achieving them. At the risk of over-using military planning as a guide to business planning, military strategy can have a lifespan of years, but each mission must be crisp and brief.

The last is paradoxical: OODA requires IT to use careful, deliberate techniques for making decisions about long-term strategy, architecture, infrastructure, and other matters that enable but don’t drive specific action. Do them well and it becomes easy to decide and act quickly and nimbly.

Do them poorly and all the intelligence and effort in the world won’t matter. Your organization will still be slow and stupid.