The A-Team of IT — and How To Assemble One 246
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.'"
It's a joke. (Score:2, Interesting)
This article belongs on one of those Onion wanna-be sites.
Re:Ugh.. (Score:5, Interesting)
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 (Score:5, Interesting)
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.
Been There, Done That (Score:3, Interesting)
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