In-Depth

Hitting One Out of the IT Park

How IT can look to baseball for better management strategies.

• By Jeff Angus
• 03/01/2007

"Sometimes you can observe a lot by just watching."
-Yogi Berra

While you managers of information technology are justified in thinking that the daily, real-time madness in which you must operate is about as tough as it gets -- almost Mayor-of-Fallujah tough -- don't despair. In fact, you should feel lucky.

Yes, lucky. Because successful IT management is almost exactly like successful management in another industry that has the most sophisticated, evolved techniques in North America. That industry is also the most open, transparent test bed for management theory in the world. And what is this great incubator of management ideas?

Baseball. If it works in baseball, it's probably going to work for you, and there are several critical baseball management techniques that you can adopt in IT to increase your competitive advantage.

Why Baseball?
IT typically faces a fierce confluence of requirements. There's the struggle to establish and apply meaningful metrics. There's the necessity of acquiring and maintaining a highly skilled staff at competitive rates. Finally, there's the seemingly impossible need to produce right now while simultaneously building for a future that is unpredictable but is also based on a rational range of probabilities.

It's ugly, but that identical set of requirements has been a given in our national pastime for more than a century.

Baseball is not only an engine for adapting and driving competitive change, it's also the world's most open, transparent profitable endeavor. If, like so many high-tech managers, you wanted to emulate a corporate hero such as Jack Welch or Bill Gates, you would have a heck of a time. Their decisions are based on data you never see, are made behind closed doors and have results that are, for the most part, hidden. In baseball, tens of thousands observe every choice in real time. All the historical and real-time data is thoroughly available -- not a single datum can be fluffed by Arthur Andersen. Succinctly put, there is no Enron in baseball.

Baseball management, like IT management, needs to measure and analyze performance and master a competitive field where, as renowned author Tom Peters says, the talent is the product. IT managers must also possess the right skills in recruiting the right people and maintaining their knowledge. They need to adapt not only to the constant state-of-the-art, often subtle changes that happen every day, but also to big changes that occur irregularly.

Baseball has all the challenges IT does with some scalding extras. In baseball, competition is a zero-sum crucible: There's an immutable number of wins to go around, and every win results in a loss. In baseball, every management decision being transparent means hundreds of thousands of backseat drivers second-guessing every move managers make, and doing so publicly. Trust me, as a management consultant with a lot of decades on me, I can tell you that's tougher than your situation. Methods and processes that work in baseball will work in your somewhat easier arena. With that in mind, here are three of the more important baseball management techniques you should borrow and tweak.

Crafting Rules: Baseball's "The Book"
Most IT organizations are either too rigorous or not rigorous enough about applying rules for making decisions. Baseball knocks the stuffing out of most IT shops' decision making because it goes by "The Book" -- a set of guidelines designed to be flexible in patterned ways. There is no physical book: "The Book" is collected knowledge passed from a manager to any interested player a little at a time during a game, practice or over drinks after work. Watch wildly different baseball teams and you'll be surprised at how uniform the unwritten guidelines are.

Take the most absolute injunction in "The Book": When on offense, never make the first or last out at third base.

You never want to make the first out at third base because a runner who has reached second base safely only has a 20 percent better chance of scoring that inning if he makes it to third (and a 100 percent less chance of scoring if he doesn't). The "last out" rule is simpler. You never want to make the last out at third base because the odds for scoring with two outs from third base are only 5 percent better than they are from second base. Most plays that will score a run from third with two outs will also score that runner from second base 95 percent of the time, so the risk of getting thrown out is almost inevitably greater than the nano-reward.

But even though the rule says "never," baseball managers understand that in any individual case, it's not an automatic "don't" decision or even a "don't, unless your chances are better than 95 percent" type of decision. Opponents understand the same metrics you do. You have to go for it sometimes when they don't expect you to.

Why? The act of going occasionally when the chances are below break-even actually changes the chances. Nothing that involves life-forms or Windows computers is predictable, and if you insist on reproducing the same decisions autonomically, the way too many IT and engineering managers do, you miss out on data you can collect that might inspire something better than the standards -- although that beats having no standards at all.

When I worked for a few years at Microsoft in the early 1980s, the company had no rules on decision making whatsoever. Almost none of its managers had management training, and few had even a shred of management aptitude. When it came to what looked like less important decisions, most just guessed. When it came to the more important ones, they typically tried to model their choices on "What Would Bill Do?" Almost nothing operational was written down. The place was really a futility factory, cranking out waste at the same prolific rate at which today's Chinese prison factories crank out cruddy, fragile home electronics for export to North America. The tragedy wasn't so much that so many poor decisions got made, but that, as in so many IT shops, no one cared to track and codify past failures as guidelines for future decisions. It was all, to use a favorite word of both Mr. Gates and Steve Ballmer back then, "random."

My next gig with Boeing Computer Services proved to be the polar opposite. Every department had Brobdingnagian-like procedure manuals consisting of thousands of pages of specs for behaviors supported by people who codified and updated everyone's "books by the foot" reification of management diktat. Rigid prescriptions like these often fail, but managers are nonetheless forced to follow them. Even when someone figures out how to skirt the diktat, he still burns up energy to evade and cover for it, energy he could apply to getting torque.

IT shops inevitably struggle with this in implementing a piece of enterprise software when a consultant comes in with a "Best Practices" manual. That manual doesn't recognize that every client's context is very different, and it wants to make you into a clump of cookie dough it can cut to its spec. Well, circumstances require variations. It's management's black-and-white adherence to the all-or-none rules that make decisions brittle. Baseball proffers the alternative.

Baseball decisions are stochastic because "The Book" is designed around stochastic guidelines, and yours should be, too. Stochastic is neither random (drawing an equal amount from every possibility no matter how unlikely) nor deterministic (always choosing the same decision with the single highest probability of historical success).

Stochastic decision making tends to keep you and your team fresh and alert. It gives you insights into how alternatives work (and don't) and may give you early feedback on how change is tweaking your environment.

Here are some action items to consider: Start tracking your organization's "The Book." Is it too rigid? Have individual rules already proven a failure in some cases? Can you tweak it into more stochastic guidelines? Start accumulating your own guidelines. Can you make general rules of thumb that are basically true and contained in explanations short enough for proteges to remember?

Measuring Performance ... of the Right Things
IT is burdened with the need to measure productivity and a history of craptastically dysfunctional metrics with which to do it. Baseball has a great lesson, in this case, from its too-slow adaptation to using good measures.

When I worked at Microsoft, for example, I was the single most prolific developer in my department of roughly 20 people. I was prolific for quantity but also had imperfect quality, although the imperfections in my work were easily fixed. We had plodders, too -- those people who produced tiny quantities of perfect output. The manager, a guy I'll call Stewk, was a black hole for metrics. He was superdense and no light ever emerged from his efforts. But when bonus time came around, rather than try to balance quantity and quality, he went straight for the emptiest, most meaningless metric of all: hours of overtime worked, as allegedly measured by a piece of clever Unix spyware that timed keyboard activity on contributors' terminals. The more time a person lost to disorganization or rehashing, the greater the bonus.

One of the founding parents of American baseball was actually a 19th century Brit who went by the colorful name of Henry "The Exeter Executioner" Chadwick. He was credited with inventing baseball's scorekeeping model and the metric "batting average" sometime around 1871. In the ensuing century the game changed radically in every respect. But still, until just four years ago, batting average (BA) was assumed to be the gold standard of numbers that best illuminated offensive prowess, when it's really about the sixth most useful.

That's nasty, because in 1947, almost the midpoint between Chadwick's invention and now, Branch Rickey, then general manager of the Brooklyn Dodgers, hired a professional statistician, Allan Roth. Roth quickly examined reality and found a bunch of better and more easily tracked metrics, most notably "on-base percentage."

How did Roth find out the standard metrics were wrong and others were better? By tracking actual outcomes, good and bad, against measures -- good, basic problem solving applied against evidence, just the way all performance measures should start. Baseball was too slow to internalize the changes, though in the last four years, every team now employs "sabermetricians"(those who use numeric analysis to differentiate performance and apply the knowledge gained to improve processes and reward the right behaviors).

Actions items to consider: Try to dump Stewk-like metrics of lines-of-code-per-day or support-calls-processed-per-hour (which reward shoddy service instead of concrete results). Experiment with numbers that correlate with outcomes, and be prepared to tweak them as you learn more.

In baseball, newcomers don't get thrust into the most high-leverage life-and-death situations immediately. They get exposed to the organization's behaviors and expectations and processes in the minor leagues, where failures have lower impact and new employees can be vigilantly observed.

In baseball, unlike most IT shops, managers understand that management means the manager changes behavior and processes to make the most of the talent at hand.

Action item to consider: I'm not suggesting you send rookies off to training, where they produce nothing, and keep them from actual work. Put them on less-critical projects where the difference between excellence and barely good enough won't savage your goals and objectives. And invest in seeing what they do well and what they do poorly. Then act on that knowledge by applying remediation (training or redefining their work so you generally keep them away from the things they don't do well).

Baseball has a stream of lessons pouring out of it every day, even greater than the flood of Windows updates. If you observe closely, everything you need to know about IT management can be learned from baseball.