Stock your organization with these seven IT miracle workers, but beware the dark side of their superpowers run amok
IT superheroes can't fly -- at least, not without an airplane. They don't possess X-ray vision or super strength. They won't be found wearing capes or spandex (at work). But the geeks who save the day time and time again for enterprises around the globe exhibit some extraordinary powers.
Some tech heroes have an instinctive ability to suss out problems and conjure up solutions. Some are quick-fix artists who do their best work under pressure or when all seems lost. Others are tireless workers who will not quit until the battle has been won, or insist on doing things the right way every day, no matter the cost.
[ Bring peace to your IT department by avoiding IT turf wars. | Find out which of our eight classic IT personality types best suit your temperament by taking the InfoWorld IT personality type quiz. | Get a $50 American Express gift cheque if we publish your tech tale from the trenches. Send it to firstname.lastname@example.org. ]
Most organizations can't function without at least one kind of IT superhero -- and usually more. But beware: All heroes have fatal flaws, and sometimes a hero is not what he or she seems. Relying too much on geek heroics can backfire badly.
Here are seven geek superheroes, one of whom could be a supervillain in disguise. No need to put out the bat signal to find them -- just look inside your IT department.
Technical degrees from top schools and high-level certifications are all well and good, but to be an IT superhero sometimes you just gotta go with your gut.
"What's important is your ability to feel your way through things," says Anthony R. Howard, a best-selling author ("The Invisible Enemy: Black Fox") and independent technology consultant for Fortune 50 companies and the U.S. military. "Old-school geeks like me who have been living and breathing this stuff for 20 years can just sense what's wrong and how to fix it."
For example, in 2007 Howard was called in by a major bank that had suffered a catastrophic failure of its primary storage array.
"For four days, they called anyone they could think of to figure out why their storage array was down," he says. "Finally they called me. Before I even touched the array, I had figured out the problem."
It turned out the bank's tech team had installed a new disc tray into an older array. The new tray was incompatible, bringing the system to a screeching halt.
"After doing IT for so long, I had a kind of sixth sense about what it could be," he says. "There were only a few things that could cause a fully redundant array to go down without a power outage. I went with my gut."
The failed array cost the bank untold millions of dollars in downtime. Afterward, all but one of the bank's tech team was fired, says Howard. The guy who told the truth about what went wrong, instead of trying to cover his assets, was spared. (See IT superhero No. 7: The Lone Geek.)
But there's a downside to relying only on instinct: Guess wrong, and your intuition can come back to bite you. Howard says you need to back up your gut feelings with facts before you go public with your theory.
"You want to follow your hunch, but back it up with the facts before you broadcast it," he says. "Even if you end up being wrong, no one can fault you because you've substantiated it."
Due to downsizing, many tech pros have been forced to do the work of two or three people, notes Mike Meikle, CEO of the Hawkthorne Group, a boutique management and technology consulting firm. Even when basic admin or support duties have been outsourced, once the outside contractor or managed service provider hits their contractual limits, the spillover falls to this hero.
"They're like the guy in Fantastic Four who can stretch his body and cover anything," Meikle says. "They fill the gap when your outsourcers hit their allotted support time or contractual bureaucracy stalls progress."
Often geeks have no alternative but to push hard until the job is done. After Chile's Puyehue volcano erupted last June, Iron Mountain network engineer Chris Preister flew to Buenos Aires and worked around the clock for four days migrating his company's network, getting out moments before the airport was shut down.
"There's no magic or voodoo to it," he says. "It's just hard work and commitment."
This dependence on heroes bleeds over to development, when teams are often pushed too hard to make unrealistic deadlines, says Steven A. Lowe, CEO of Innovator, a consulting and custom software development firm.
"Some IT heroes push through and code for 70 straight hours and sleep under their desks to meet deadlines," he says. "The problem is that their mental acuity starts to degrade after so many hours in front of a keyboard, and they start to make mistakes."
Their fatal flaw? Burnout. Even the most powerful IT hero can get stretched too thin and will snap -- usually into another job, says Meikle.
"The danger to the business is if they say they need it in three months and you get it done in three months, they'll want the next project done in three months too," adds Lowe. "They forget that IT got it done because everyone was working 90 hours a week. That's not sustainable. Relying on heroes can be dangerous."
"The dirty little secret of many acts of IT heroism is that the hero hacked the solution," says Innovator's Lowe. Instead of doing it by the book, this hero plugs a patch into the code to get it working right now.
Lowe recently consulted with a company whose dev team inherited a 100-line script to control document display. The script was a hack from day one, but fixing it was never a priority. "Every time a new machine came online, its IP address got hard-coded into the script," he says, "so the script gradually grew to over 800 lines. It's unmaintainable and will have to be redone eventually."
Production systems are particularly susceptible to this sort of hacking, Lowe says, because when the software fails, productivity stops, which costs the company money by the minute.
"That script is now 800 lines of special cases and hard coding with no comments," he says. "It's unmaintainable and has to be redone."
The danger with this kind of hero is that the technical debt you build up via short-term fixes eventually catches up to you, Lowe says.
"In some environments you spend every day putting out fires," he says. "You try to reach a point of stability but it never comes, because the fire you put out last month is causing a new fire this month."
It doesn't always take extraordinary intuition or superhuman dedication to make an IT hero. Sometimes the circumstances demand you rise to the occasion.
In 2006, independent IT consultant Jason Wisdom took a consulting gig with the insurance division of a large bank that needed to update its legacy mainframe accounting package to generate new types of reports. Naturally, the bank's CFO wanted the solution done as cheaply and quickly as possible.
Prior to hiring Wisdom, the bank's tech team dove in and started coding. After a couple of months, they hit an impasse. Meeting after meeting passed and nothing got done. Even after they brought Wisdom on board to help come up with a strategy, the team argued for weeks about whether to scrap everything and start over.
"Sitting in those meetings was starting to give me a headache," Wisdom says. "So I finally said, 'Give me a day, let me see what I can do,' and I left to work on the problem. That afternoon they were still talking, but I had the solution."
Donning his "calculus hat," Wisdom reverse-engineered several formulas from the mainframe system, then tested them with sample data to make sure they gave the correct results.
"It was the perfect combination of pressure to get things done quickly, the freedom to do what I wanted to do, and four or five people really hoping I would come through because it was more than just my job on the line," he adds.
The problem? The company wanted the solution to be cheap and fast, but still expected it to be good. Eventually it was good, says Wisdom, but at that point it was neither cheap nor fast.
Here is where an IT department rife with Icemen can turn overconfidence into projects all too often overbudget.
"The amount of rework required drove the total cost of the project far higher than it would have been had they done things properly from the start," he says. "What they should have done is hire a business analyst, technical lead, another developer, and a database administrator. Instead they wanted one person who could do all that. They were being cheap."
Some supergeeks have the ability to improvise solutions at a moment's notice using nothing but plastic bags, duct tape, and their own creativity. "Kind of like MacGyver, only without the mullet and the bad sunglasses," says Meikle.
Meikle was working for a state agency in Richmond, Va., when Hurricane Fran came bearing down upon his city in 1996. His CIO located the big three-ring binder with the agency's disaster recovery plan inside, blew off the dust, and cracked it open.
"The plan called for the agency head to take off in a helicopter and 'monitor' the situation from the air -- in the middle of a hurricane," Meikle says. "The contact phone numbers in the binder where from years ago and many of the individuals had retired or moved to different roles. Essentially the plan was useless."
They improvised. Meikle and his team covered all the critical hardware and filing cabinets with plastic trash bags and created a communications plan on the fly. Then they hunkered down and waited out the storm.
"Fortunately the building roof leaked but held and the agency was saved from disaster," he says. "The disaster recovery plan was put back on the shelf where it probably remains today."
But relying on improvisation is a bad long-term strategy. At least hurricanes give you a time to prepare; with other disasters, not so much. As with Captain Instinct, the Improviser's Achilles' heel is a tendency to simply wing it.
"A lot of times when disaster strikes and you have no plan, you're struck trying to rebuild without any idea how to do it," he adds. "You can improv, but it's no substitute for planning ahead."
Call it the Scotty technique. As in the original "Star Trek," when Commander Scott told Captain Kirk the warp coil array was damaged beyond repair (yet still managed to fix it before the next commercial break), some IT pros look like heroes through the time-honored techniques of underpromising and overdelivering.
That's partly because, in many organizations, IT departments have to exaggerate how bad the circumstances are in order to get the resources they need, says Wisdom.
"In some organizations IT will not get any type of support until it cries wolf," he says. "It's like in the movie 'Full Metal Jacket.' When the troops needed more soldiers they'd ask for a tank, because if they knew if they just asked for soldiers they wouldn't get them. The culture forces them to scream bloody murder in order to get attention."
But while the Distorter can prove to be an asset to your department, navigating interdepartmental politics and championing IT's value and needs with relative ease, this IT superhero can turn supervillain quickly, given the Distorter's tendency to take credit for your successful projects -- even if they did everything in their power to keep them from being successful.
Lowe says he was working for a public energy agency in the early 2000s that needed to adopt Microsoft's .Net framework for office automation. The agency was largely a Java shop, but for this scenario .Net did things Java couldn't do, he says.
"Our department manager backed us to the hilt, but the vice president of IT opposed it every step of the way," says Lowe. "She made us do three pilot programs. They all passed with flying colors. In the end, the VP had to admit that .Net was the tool we needed. Then she transferred the department manager who'd pushed for the initiative and took all the credit."
Distorters gone supervillain not only breed discontent, they also hide the sources of real value in your IT department, says Meikle.
"When someone else is getting credit for your hard work -- especially when you're pulling double or triple work loads -- you tend to jump ship. Or the company won't understand the benefit you're providing so they'll outsource your function. Then when customer service or production support go south, they'll have no idea why."
The least-sung heroes are perhaps the most important of all. They may not possess outstanding technical chops or great instincts. They might not be able to reverse-engineer mainframe code or get handy with plastic bags and duct tape. They simply do it right, every time -- and they speak up when something is wrong, no matter whose feathers get ruffled.
"They're the guy or gal who always does things the right way, no matter what corners their bosses ask them to cut," says Lowe. "They're usually also the people who stand up and say, 'We shouldn't be doing it this way; it's going to cause problems down the line. We should take the extra time to do it right.' They may not always be recognized or appreciated for that."
As in the example with the bank's failed storage array, only one person had the guts to say what his own department did to cause the problem and how it got fixed, says Howard. In that instance, that hero got rewarded by being allowed to keep his job. Not all organizations work like that.
"If you're the lone geek, you've entered a thankless realm," Howard says. "You can't walk into the arena expecting a lot of glory -- it's not there. You need to be part of this world because you're passionate about technology and helping people find solutions."
Copyright 2009 IDG Magazines Norge AS. All rights reserved
Postboks 9090 Grønland - 0133 OSLO / email@example.com / Telefon 22053000
Ansvarlig redaktør Morten Kristiansen / Utviklingsansvarlig Ulf H. Helland / Salgsdirektør Jon Thore Thorstensen