We Don’t Need Another Hero
Tina
Turner sang, “We don’t need another hero.” She sang it in the only bad “Mad Max”
movie ever made. Think about it.
Peter
Senge and other management experts, with whom I would be loathe to pick a fight,
aver that we should abandon the cult of the hero-leader when thinking about our
CEOs.
My
buddy, an extremely smart guy, twenty-five year IT veteran, and senior
technologist at a huge financial services firm, also told me outright that
Information Technology organization at his firm didn’t need any heroes—it just
needed a more disciplined approach.
Well,
Mad Max 3 could have used a stronger hero. And a lot more car chases.
And
Mr. Senge may be right in his domain. I’ll leave that to other analysts. But his
thinking is dead wrong if applied to Information Technology.
And
my buddy … my buddy was appointed the first Chief Enterprise Architect at his
firm. He accepted the position, but declined to perform the heroic quest. He
left the position after a few months. He has since fought off several itinerant
black knights superbly, but the forces of darkness gather just beyond the
horizon, and a hero to go slay them is yet to be found.
Now
pay attention: If you’re in executive management at a large ($1B+) organization,
you damn well do need to ensure you have a few IT heroes. And you better be sure
your CIO is grooming them or hiring them, or your strategic IT initiatives are
doomed to the usual late deliveries, cost overruns, poor performance,
scalability problems, and the integration worries.
Information Technology
is like…
Why
does serious IT need heroes? Let’s approach an answer by asking a more basic
question: “What is IT like?”
Keep
in mind that our domain of discourse in WITDW is IT at Fortune 500-sized
organizations. We’re talking about the conceptualization and design of large
scale applications and the enterprise infrastructure that must envelop and
nurture them. (I’ll call this enterprise IT, or EIT for short.)
So
what is EIT at this level like? Well, the word “engineering” is used a lot in
IT, as in software engineering and systems engineering, but it’s
pretty easy to see that EIT has nothing much to do with real engineering. (This
probably explains why all the electrical, mechanical, civil, and chemical
engineers I’ve seen try to run IT organizations have had to abandon their prior
beliefs and start from scratch, usually after some very hard lessons.) The
reasons should be obvious:
·
The pace of
change is vastly different:
The tools, materials, and design principles of EIT change at a far faster rate
than those of engineering. After passing through a plateau of stability in the
70s through mid 80s, when mainframes and their standard software dominated
corporate computing, the very basis of computing has changed radically every few
years: Intel and Unix servers, two-, three-, and then n-tiered client/server,
distributed objects, Enterprise Java Beans, Web Services, MS.NET, and on and
on.
·
The breadth of
assignments for your staff building your EIT is oftentimes astonishing:
During an real engineer’s career at, say, Boeing, he or she designs: aircraft.
An individual in your IT shop may work on, over a few years, billing systems, HR
systems, customer contact systems, real-time fraud detection systems, and
manufacturing systems.
·
As a result of
these two compounding influences, we find the EIT staff tackling unknown
business problems with unknown tools and technologies every time they
start a new project.
There
are other, more subtle differences, but those above go a long way to explaining
why new airliners fly the very first time but your new billing application
crashes: real engineers have a reliable body of practice they can reuse over a
lifetime, with significant changes only over decades. Your IT staff have to
learn it as they go.
The
relevance to our quest for a hero? IT at this level is not a linear,
build-on-your-successes, engineering-like process. It is an inherently risky
process. Unless your enterprise has zero business competition, you do not
have the luxury of incrementally upgrading your systems with only 100%
proved-out technologies. You must take intelligent risks with new
technology. You must, from the huge array of available technologies, select a
coherent set that enable evolution towards a rational IT environment that
allows the rapid development and integration of crucial business applications.
[There's a situation that happened so often in my days in the various Marketing
Divisions of Giant Computer Company that we used to ruefully joke about it: a
customer would tell us they wanted the very latest and greatest technology --
enterprise class Unix servers when they first emerged, say, to replace their
mainframes. Fair enough. And then in the RFI they would request ten reference
customers already using this new technology to do the same thing they were
planning. In their own industry, preferably. They wanted the new technologies'
cost savings or other advantages with zero risk, or, at worst, plausible
deniability if problems ensued: "GCC told us Eastern Airlines is using this same
technology, and they're the industry leader."]
Back
on topic: I have usually seen these technology selection tasks approached in two
ways. They’re both wrong.
Method one: Senior managers make the decisions based on a few vendor briefings
and perusal of trade publications. If they are really diligent, they get a
consulting study.
Method two: IT prima donnas (see below) make careful, analytical decisions that
optimize their own technology domain with nary a thought to the effect on the
overall enterprise.
I
would propose that there is a better method, that someone must make difficult
decisions on technologies based sometimes on partial data. Someone must use a
combination of detailed analysis and holistic understanding of the enterprise
and technology to devise a real, workable enterprise architecture that supports
and integrates your systems.
Someone must be responsible for the overall success of the IT mission from
startup to delivery, without whining and without excuses.
Someone must be a hero.
Heroes vs. Prima
Donnas vs. Poseurs
Now
listen closely: The last thing you want to do is confuse IT heroes with their
superficially similar evil cousins: IT prima donnas and IT poseurs.
The prima donnas are the guys who are actual experts in some aspect of
technology and believe that this gives them license to make all decisions
related to that technology while totally disregarding the impact on the
enterprise. These gurus believe other staff not expert in their arena are
idiots. They are narrow-minded technology bigots. Despite this, PDs are valuable
resources, but they need to be reined in. Brutally. We’ll talk later about who
should be doing the reining.
These
prima donnas are at least sincere. The poseurs are not. The poseurs are the guys
who are always talking about some emerging technology while staying well above
the fray of building real systems right now. They give briefings and
write white papers and perhaps articles for technical publications about the
stuff which is in the labs or perhaps in Release 1.0. (Now don’t confuse these
guys with the smart folks who actually invent new technologies. The
inventors are obviously a vital part of IT.) The poseurs are guys that read the
journals before anyone else, latch onto the next big thing, and then talk about
it authoritatively.
There
is an easy solution for the poseurs: assign them to your ‘IT Futures’ or
‘Advanced Technology’ department. Then abolish the department.
Enter the Hero
So
who’s your hero? The Chief Enterprise Architect, among others. He (and other
senior technologists who see the big picture) are the guys who have to deeply
understand not just one technology, but several. Who have to make the hard
decisions about when the benefits of a new technology outweigh the risks. Who
think about the good of the enterprise, not just one business or technical area.
We’ll
talk much more about this battle-scarred warrior in future columns—where he came
from, what motivates him, what weapons he deploys. And how you might find one to
save your village from the forces of evil…. |