Hitting One Out of the IT Park
How IT can look to baseball for better management strategies.
"Sometimes you can observe a lot by just watching."
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
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
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.
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
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
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
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
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
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.
Development: Starting in the Minors
Several of my clients suffer in their IT efforts when they throw a new employee
into the deep end on an important project only to have the newcomer botch the
effort. Too many IT managers like the trial-by-fire approach, ignoring the fact
that their departmental jockey shorts burst into flame too often. Baseball has
a clear alternative that works as consistently as any people-management method
can: "Starting in the minors."
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
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.