All Posts in Strategy and Tactics

|In: Leadership|Last Updated:

“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.

Comments

|In: Leadership|Last Updated:

In the end, there are only two places you can create new business value in corporate America: You can increase profitable revenue, or you can decrease unproductive costs. Everything else — product quality, process throughput, customer satisfaction, is a discussion about methods.

Given a choice, revenue growth is more desirable than cost reduction for reasons that are, I hope, too obvious to require enumeration. So here’s my question: If this is so, why is the preponderance of IT investment devoted to the latter?

The answer is easy: Revenue is riskier.

For a cost-reduction project, the only significant risks are faulty design and failure to complete the project. If the planned business change is well-considered and delivered, cost reduction is guaranteed, since the entire scope of the effort is within the control of the business.

Revenue enhancement projects, in contrast, call for changes in customer behavior. In particular, you need them to buy more of your products and services, more expensive products and services, or both. Your business’s influence over the behavior of its customers is limited under the best of circumstances.

But wait! It’s even worse!

It’s pretty easy to demonstrate the connection between a cost-cutting effort and actual cost reductions. One way or another it isn’t all that hard for companies to measure process costs, so when you change a business process you can tell whether overhead and unit production costs increase or decrease. As there aren’t very many extraneous factors to take into account, you can be confident improvements came from the change in process and technology.

Revenue? Except for direct-response marketing, companies can’t even evaluate the effectiveness of advertising campaigns. Don’t believe me? Imagine you’re in charge of General Motors for a moment, trying to resurrect the Cadillac brand. It isn’t going well. (Everyone who’s in the market for a Lexus or Mercedes, or who just salivates when one comes into view … spent much time drooling over Cadillacs lately?)

Is the problem bad advertising? Maybe. Or, it could be the styling. Or the comfort, drivability, and performance. Possibly, consumers just have long memories, recall just how bad their last Cadillac was, and see no reason to give GM another chance.

Who knows? It could be that half the product line consists of SUVs, inconsistent with a luxury car image in consumers’ minds. Or, it could even be simple irritation over GM’s decision to call one model “Escalade.”

It’s even possible that the problem begins with your biggest competitive differentiator, OnStar, which mostly helps owners when their Cadillacs break down. (If you were GM, wouldn’t you be busy marketing OnStar to owners of every other car brand? What a great campaign that would be: “You own a Ford? You’ll probably need this!”)

Yes, customer surveys can answer each individual question. They can’t, however, determine whether the advertising campaign itself yielded useful results.

So. You’re in charge of General Motors, and you have two major capital proposals in front of you. One is to implement a customer relationship management program focused on Cadillac owners. Its goal: To reduce the customer defection rate, while supporting direct marketing efforts through better customer segmentation. How much improvement will it drive? There’s no way to predict, of course.

The other proposal is for a supply-chain optimization program that will reduce the total cost of parts and raw materials by 10%. How sure is the 10% claim? Since half the benefit comes from reduced carrying costs on inventory, it’s a very safe forecast.

It’s your company and your bonus. Which proposal do you approve, assuming you only have the budget for one of them?

Is there any question at all? Which is why revenue so often takes a backseat to cost in large corporations. Revenue requires courage, an appetite for risk, and to a certain extent a willingness to take things on faith. All that’s needed to cut costs is an implement with a sharp edge to it. So when times get tight, cost-containment always trumps revenue enhancement. That’s too bad, because no matter how much you cut costs, eventually a lack of revenue will kill you.

You don’t, of course, run GM. You run an IT organization. This is all very interesting, but how does it affect you? Lots of ways, unless you think company strategy is something that happens to you rather than with you. For example:

Chances are pretty good the CEO will ask your opinion as to whether your company should invest in CRM, assuming you haven’t had this conversation already. How should you respond?

You could say, “Industry statistics show disconcertingly low success rates for CRM projects. In my judgment we’d be better off investing in cost-reduction programs like supply-chain optimization and internal process re-engineering.”

Or, you could say, “CRM is risky for the same reason all revenue-enhancement efforts are risky. Even worse, we’ll never really know for sure whether we’ve succeeded or not. Still, we need to fix revenue and this is the right way to start.”

Which is the right response?

How should I know? It’s your company, after all, and in business there are no one-size-fits-all answers.

I just know it’s a tough question.

Comments