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.

Wildcard

[DrugCheese]

Yeah I turned off all the environmental controls in the server room.

Wildcard, bitches! Yeeehaaw!!!

It's a joke.

[AnonymousClown]

The site hung up when I tried going to the third page, but what I read was a joke.

This article belongs on one of those Onion wanna-be sites.

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.

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.

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.

How about ditching the silly names

[Gothmolly]

If you take someone on your team because he's an "uber hacker" or a "Sherpa" then you are spending too much time diddling and playing WoW. Get a good team of professionals with complimentary skills, but don't give them stupid handles.

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:Prefer to be like Batman

[Nerdfest]

... and a backout plan ... just in case.

Ugh..

[The Living Fractal]

What a horrible idea. Not trying to emasculate nerds here, but I think it's pretty safe to say that the "A-Team" embodies a certain degree of testosterone-fueled machismo that just doesn't really work when you're trying to debug 30,000 lines of code by noon on a green screen.

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.

Re:Ugh..

[Belial6]

Bingo! That's exactly what I was thinking. IT is full of 'Munchausen by proxy'.

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.

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:This is how they see you, IT grunts

[AnonymousClown]

F'N A when you're right ....

The other thing is if you don't fit into those pidgeon holes, they won't even hire you and just say "you don't have the skills" or "you don't fit in" and then bitch and moan as to why they can't get "qualified" people.

Re:This is how they see you, IT grunts

[dkleinsc]

The observation is easy: If you want to change your professional role significantly, expect to change companies.

And it's not simply "management sucks", it's that management doesn't understand you, so they're doing their best to muddle through, and they seize on information like this because it's all they have, and once they think they understand you they're probably going to keep that understanding of you. They don't have a lot of time to spend understanding each employee, so once they think they've figured you out they aren't going to try to repeat the effort.

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.

I quit reading

[codepunk]

I quit reading as soon as I ran into the comments by the VP of Tata Consulting. The article pretty much lost any sort of credibility right at that point.

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.

We actually are forming a serious IT A-Team...

[DRAGONWEEZEL]

Basically, it's problem resolution.

Most people are used to takign tickets, they take a ticket and they fix an incedent. Sometimes an incident is just stupid user error, sometimes it's a config error.

However, every now and then, there is some ghost error that you can't replicate, but exists intermittently on an enterprise scale. The "A-Team" where we work is supossed to be an advanced troubleshooting team, who's other duties are re-allocated so they can focus entirely on one issue.

These aren't your stnd network and desktop geeks. This is the best person from every IT team. A PM, a network guru, a server guy, an analyst, an app admin, a developer or two, and a super user or two (for out of the box ideas). You switch roles, exchange ideas, and generally dig deep until you either find the problem or reach the back of the CIO's teeth.

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.

Trained Monkeys

[sycodon]

Notice that each position called for people with very explicit experience.

This illustrates very nicely what I am finding in the job market: No one seems to want people with lots of diverse experience who are flexible and adaptable. Instead, they want trained monkeys that have years and years of experience in one thing.

Thinking for yourself is verboten. Just take the specs and churn out code, or diagrams, etc.

I think this is just asking for trouble, especially in smaller companies. How many trained monkeys can also install and configure a database, then design and create the tables? Not many. So you need to bring in a DBA trained monkey. And monkeys that can actually talk to the users are exceedingly rare.

While trained monkeys have their place, I think they need too much supervision. If they get out of their monkey experience, they are lost and grind to a halt.

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.

But it makes perfect sense to them.

[khasim]

Just how is something supposed to get coded, if nobody explains what should it be?

They don't want to have to explain because they don't KNOW what they want.

They only know the end result that they want. Success and fame and more money.

Translating that into real-world products is beyond them. So they want people who can do that for them. They want magic. They want people who can read their minds, predict the future and turn out world changing products ... and then give all the credit to their "manager".

Why would someone like that work for a manager like that?

Everyone would like to have Superman working for them. Or a whole team of Superman.

But why would Superman need YOU?

At a certain point, everyone else is an idiot.

[khasim]

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.

Think back to your school years. You progress through 12 years of school or whatever. Now compare yourself to someone who's repeated the 3rd grade over and over while you've been moving on.

In most of the sciences (yes, we're talking about computer science) there are a few people who know a LOT and LOT of people know very little.

If you keep learning, you WILL leave more and more people behind you.

Now, how do you feel when you're working extra weekends because those people who decided NOT to continue learning have broken something and YOU are the only one with the knowledge to fix it?

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.

Humour article

[Frankie70]

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

Been There, Done That

[Terje Mathisen]

15+ years ago I started exactly such a team for my then employer (Hydro, Norway's second largest corporation), I ran it until Hydro was split into multiple independent units, some of them sold off.

They way I set it up was to pick one or two top guys from each of the crucial departments (LAN/WAN/FW, Oracle & MSSQL dbs, Java, C#/.Net, C(++) developers, Unix & Win* admins, etc.).

Each of these departments got the money to hire some extra help, in return I could grab any of the required people for a specific assignment with 2 hours warning. From then on we'd all work on nothing else beside the current task.

I had one requirement for the group (business unit/division) that declared such an emergency: They had to designate one person to work with my team full time, and that person would have authority to accept any kind of change in the project, both technical and economic.

This requirement alone reduced the number of "emergencies" by 75%. :-)

So how did it work?

Pretty good actually: With a total of more than 100 such projects over a 15-year period, we had just two failures.

Terje