The A-Team of IT — and How To Assemble One

snydeq writes "InfoWorld's Dan Tynan offers insights into building a crack special ops team ready to tackle the toughest IT assignments. From Air Support (think: the guy who shares a cigarette break with the CFO), to Infrastructure Sherpas, to Über Hackers (Mohawk optional), each of the seven essential members of your IT A-Team must bring his or her special blend of expertise, connections, and temperament to ensure the success of mission-critical assignments. 'Remember, there is no Plan B.'"

Comments

step 1

[thanasakis]

get a big cigar and practice saying "I love it when a plan comes together" while smoking it

Re:step 1

[SimonTheSoundMan]

I'd just employ Moss, Roy and Jen.

Re:step 1

[fridaynightsmoke]

I'd just employ Moss, Roy and Jen.

TEAM players each and every one of them. There's no room for people who can't act as a team on my team.
TEAM! Team team team team team! I even love saying the word 'team'. You probably think that's a picture of my family, nyah-ah. It's The A-Team.

Re:step 1

[Average_Joe_Sixpack]

In 1992 a mediocre COBOL unit was sent to prison by a civilian court for a fraud they implemented but were oblivious to. These men eventually escaped from minimum security house arrest to the Des Moines suburbs. Today, still ignored by the government, they survive as free lance consultants.
If you have a mainframe - if no one else bids on the job - and they are all you can afford - you can definitly hire: The C-Team.

The guys in sneakers are more like a real team to

[Joe The Dragon]

The guys in sneakers are more like a real team to base things off of.

Prefer to be like Batman

[dcollins]

Always have a backup plan.

Re:It's a joke.

[Kalidor]

You made it to the third page? The article lost me when they tried to get advice from effective team leads on someone from TCS. It would be so funny if I didn't have such sad vivid memories of the ineffective team leadership displayed every time a Morgan Stanley employee cuckolded any of the management / leads.

This is how they see you, IT grunts

[dkleinsc]

That's why you should read this. Not because it provides useful information to people on the tech team, but because people in the business of managing IT departments really take this stuff seriously. They will try to shoehorn the people they have into the stereotypes, archetypes, and roles they know about, and once they've assigned you to a part, you're going to be doing that part until you leave or the show ends. And if you don't fit one of the parts, they're going to consider you useless.

This sort of thing is especially true for managers who didn't work their way up through the ranks, so they're now faced with a bunch of geeks who are exacting, relentlessly uncovering BS, demand facts and figures, and speak in a jargon they can't understand. It can also be a big issue for the CTO, because even if the CTO is someone who does understand the geeks, the CEO doesn't and often demands that the CTO make the geeks follow a plan they can understand.

Re:It's a joke.

[spun]

Sure, you think it is a joke, but maybe they are just trying to hide from the federal government that is hunting them down for a crime they didn't commit!

I wonder what "The A Team" of IT would look like?

They would be unable or unwilling to kill any process, no matter how corrupt it had become.
They could build a Cray out of old disk drives and EISA cards, but if they tried to hack you they would accidentally hit the Pottery Barn right behind you.
Most of their proposed solutions would involve tossing someone or something onto or into something else.

ridiculous

[roman_mir]

you know this entire article is ridiculous because it's full of stupid shit like this:

You don't even have to explain what you want or provide a document. They just complete the job."

.

The entire article is written as if by somebody who just watched 'Charlies Angels', 'Swordfish', 'True Lies' and 'The Core' and decided to write about this subject as if those movies actually represent reality.

Re:It's a joke.

[somersault]

Yeah it was a load of crap, I skimmed it and saw this

Here the challenge is to find someone who mixes the requisite coding chops with a measure of humility, says Minco's Adriana Zona.

"You want the genius guys who aren't arrogant," she says. "They want to impress you, so they do in an hour what would take standard developers a week. But the most important thing is they don't challenge you. You don't even have to explain what you want or provide a document. They just complete the job."

Though extremely rare, the humble coding genius can be found via word of mouth, says Zona. She also weeds out the arrogant ones by asking prospective employees to rate their skills on a scale from 1 to 10.

"A good developer will never say 10," she says. "Technology changes so rapidly no one can possibly know everything. But the arrogant ones will. And a nonhumble developer will destroy your department."

A good developer doesn't need to "know everything", they just need to know how to use a reference manual and be able to adapt and learn. Sounds more like she just prefers people with no self confidence who are desperate to impress others to feel validated - people that she can order around.

Good developers will require specs and explanations otherwise they will probably waste a lot of time barking up the wrong tree. I certainly have made incorrect assumptions in the past about the direction a project will be heading or how the end user will be wanting to use things, so now I make sure to discuss issues where there is any doubt.

It's also great to have a specs document to refer back to if someone comes to you and says "where is [feature]" or "we need this feature!". I try to be accommodating, but it's really not a great idea to be adding features in halfway through the first implementation of a project. Any new features can be added into version two. Or if the "new feature" turns out to be an essential oversight, you may have to rethink the whole project from scratch.. but if they didn't put it in the original specs, it's their own fault.

Very unrealistic

[vadim_t]

In my understanding, an "A-Team" isn't something that gets created by management, it's a group of people who happen to work together so well that they keep sticking together, because it works great for them. I don't think that's something you can build to a formula. At most you can try to find such a group in a large organization.

And of course, they have the most unrealistic requirements for the developer:

"You want the genius guys who aren't arrogant," she says. "They want to impress you, so they do in an hour what would take standard developers a week. But the most important thing is they don't challenge you. You don't even have to explain what you want or provide a document. They just complete the job."

Just how is something supposed to get coded, if nobody explains what should it be? That kind of thing only works for independent coders who already know what they want to do, and community open source projects where nobody tells you what to do, you just do it, and if it's good it gets merged. But that's a very un-business-like development model.

A more realistic IT crew

[bl8n8r]

We have Snow White and the Seven Dwarves in Windows support. Bert and Ernie (both guys are gay) in the Mac Support dept and then Gonzo and Beaker in Unix/Linux systems department (one of them doubles as Oracle admin). They just hired a new IT manager, promoted from HR, who looks and acts a lot like Miss Piggy.

Re:A more realistic IT crew

[locallyunscene]

And where does Animal fit in in all of this?

The client.

Intrinsically unstable

[petes_PoV]

Your first hurdle is trying to reign in those egos. Once geeks get above a certain level of (in their own minds, at least) elitism they tend to presume that everyone around them is an idiot. Put two of these people together and tantrums are far more common than any actual progress. Next up is the politics. Who works for whom? Does the network geek take orders from the database wizard? Can the storage guy tell the hairy-arsed windows hacker what needs to be done? Even if you can walk the tightrope of keeping everyone calm - there will almost certainly be tears before bedtime when it's time to apportion the recognition (or blame).

Finally, people with bleeding edge skills need to continually push the limits in order to keep those skills sharp. Does your organisation have enough crises happening frequently enough to stop these people getting bored? (If so, please tell me the organisation's name - I'll sell my stock immediately, at any price). Shorthand secretaries used to often leave jobs where they felt their abilities weren't being used - in the fear that they'd get rusty and their speeds would drop. Real geeks tend to be attracted by the next sparkly, shiny opportunity much more than staying put in one single job for long periods of time.

I cant see this sort of team being a practical proposition - except in the movies.

First rule of forming an A-Team of IT...

[Tetsujin]

First rule of making a team of this kind: You don't need a demolitions expert.

I know, you'd think any kind of team like this would need a demo man, but in fact, at least 80% of the time, high explosives are not the correct answer to your IT woes. This is the voice of experience talking.

Re:It's the A-ITeam

[Ukab the Great]

I pity the foo who bar baz

OT in a big way

[GodfatherofSoul]

But, I watched Breakfast at Tiffany's a few years back with George Peppard as the male lead. He has one of the epically greatest monologues at the end. Kind of a shame that he'll be more remembered for the A-Team than that performance.

Re:Ugh..

[Atrox666]

Yes these dramatic measures generally are a symptom of bad IT.
If you have an administrator that's always saving the day, 9 out of 10 times you should fire them. You'll find out that most of the looming disasters that were happening will stop happening. A white knight can't justify their existance if there is no peril.

Humour article

[Frankie70]

The article is supposed to be a satire.
Look up the author

Re:Ugh..

[Anonymous Coward]

Careful

Do you really think its the IT admin who overhears why a dev release is broken and then fixes it that he is to blame?

Try dev's who don't understand cluster systems then put the payment gateway in place with a fixed IP address to one server, when the wrong node of the cluster goes down its the admins fault for fixing it? Get real. I can only assume that you have NO real world experience in being an admin. Your probably one of the dev's who makes this mistake.

I am in the rather unenviable position of being an infrastructure guy who moved into coding. To be honest I am shocked you monkeys keep your jobs, its only cause management cant tell the difference between good code and bad code. Christ the amount of coders who don't even understand OO let alone classes.

The amount of times it has come to the few hours after release and I have a bunch of code-monkeys asking why it dose not work, to find basics like "C:\documents and settings\someidiotdev" in their source code. GRRRRR. Static IP address's no use of DNS, no thought of the firewall. I once had a contractor brought in to redesign the payment gateway and say to me "What is PCI?"

You wanna know why IT is crap as a whole? It's cause 90% of you should not go near a computer. Management puts out adverts at low pay so they can increase immigration and lower wages for the industry. Then we get the glut of "programmers" we have now being paid a poor wage with their day-care degrees that taught them nothing about IT in a business environment. IT is crap because the elite mad it a blue collar job and employed blue collar employees.

So no, these dramatic measures are a symptom of bad middle management and even worse upper management. Pay decent staff a decent wage and IT will rock.

Re:Trained Monkeys

[Americano]

It makes me so important to the companies that they start having problems letting go when I decide to leave

Where's your documentation? Your replacement should be able to refer to that and figure out what you did.

If an ex-employer keeps calling after you've left, explain to them patiently that "after date X, if you want help, it'll cost you $200 per hour for consultation, my minimum billing increment is 1 hour, and I will not agree to provide more than N hours of support per week to you on my off-hours."

If you try being a nice guy, they will take advantage of it, and not bother to figure out things on their own. If they know that calling you to answer a single question is going to cost them $200 for the 5 minutes it takes you to have the conversation on the phone, they'll have more incentive to figure out the answer before wasting your time.