All Posts in Leadership

|In: Leadership|Last Updated:

Pessimists, we’re told, look at a glass containing 50% air and 50% water and see it as half empty. Optimists, in contrast, see it as half full. Engineers, of course, understand the glass is twice as big as it needs to be.

Which explains a major source of friction in IT-related projects: Different umwelts.

Umwelt is a century-old concept introduced to ethology, the study of animal behavior, by Jakob von Uexkull. It’s the recognition that every animal exists in a unique perceptual universe that’s closed to human beings other than through inference: Much of a bee’s world is ultraviolet; a dog’s nose does a lot of what we use our eyes to accomplish. Then there are the electric fish I used to study, which perceive their world through a sense we lack entirely.

Oversimplifying just a bit, IT project teams consist of (at least) one professional optimist, one certified pessimist, and a collection of engineering types. They have to collectively commit to a plan and stick to it, but their umwelts differ.

The optimist is the business sponsor. Corporate executives are supposed to be optimists — they’re supposed to see possibilities as certainties … as real, and motivate everyone around them to envision them as real, too.

It’s hard to be chronically optimistic if your mental habit is exploring the complexities that make even seemingly simple projects difficult. This is one reason it’s very hard for many business executives to understand why IT projects cost so much. “It’s a simple process!” you’re likely to hear a business executive complain. “Why do you IT people have to make it so expletive complicated?”

Engineers — the core staff of your average project — are, for the most part, realists. They understand that the “simple process” really consists of the simple process itself, which takes care of maybe 80% of the situations the project is supposed to address; the most common exception to the process, which takes care of 80% of the rest; and another 327 exceptions, some of which the business really needs to deal with, and the rest of which nobody has had the time to combine with any of the other exceptions to simplify things.

The project manager is, of course, the pessimist. Project managers have to be pessimists, because there’s a short phrase that describes optimistic project managers perfectly: “Chronically over budget.”

Project managers have to be pessimists, because they’re the ones who are held accountable when unanticipated problems, like a key developer being hired away by a competitor, occur. These things happen in every project, of course, so good project managers anticipate them.

Project managers have to be even more pessimistic, because in addition to being held accountable for these anticipated unanticipated problems, they’re also the ones held accountable when harder-to-predict unanticipated problems arise, such as a serious bug in the development toolkit. So the best project managers make allowances for unanticipated unanticipated problems in their plans, too.

Project managers and business sponsors are supposed to meet weekly to review progress and discuss issues that arise as the project progresses. Many of these meetings are entirely dysfunctional. The project manager, who is working from a perfectly reasonable plan, collides with the business sponsor’s entirely predictable expectations. It’s an umwelt thing. The solution is to get the umwelts to converge, which is a matter of creating a corporate culture conducive to good project management.

Project managers can’t succeed unless they work in a project-management-friendly corporate culture. But project managers have projects to manage — they’re too busy to have to influence the corporate culture. That’s where you, as the head of IT, have a role to play. It’s your job. That’s why they pay you the big bucks.

There are three major elements that must be present in a project-management-friendly culture:

  • Appreciation that the overhead added to projects by use of good project management disciplines is worth the effort
  • Understanding of the complexities of software development
  • Recognition by both project managers and business sponsors of each other’s umwelt. Which is to say, they don’t need to understand each other instinctively, but do need to understand that a different umwelt isn’t wrong. It’s just different.

Project managers need strong business sponsors just as much as business sponsors need strong project managers. It’s up to you to make sure the enterprise has an ample supply of both.

Comments

|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