Why   IT   Doesn't   Work

Home
Up 
   

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

 

     

 

Send this page to a friend:     

Copyright © 2005 Why IT Doesn't Work
Last modified: 11/28/2005
No Project Managers were harmed during construction of this site.