Sharing responsibilities within a SysAdmin team

Question

I used to work in a small System Administration team that consisted of 3 members. We each had our own area:

• E-mail
• Server build and monitoring
• File sharing

I am not sure if this is typical but it is what I got used to. In my current place, there is more of an emphasis on knowledge sharing and becoming an expert on one thing is discouraged.

My questions:

1. How are the responsibilities divided among the SysAdmin team members you've worked in (is there perhaps a standard name for it)?
2. What are the negative and positives of those systems you've worked in? Specifically with regards to productivity and coverage.

I'd like this to be a community wiki. I might be at the verge of a job search and this could potentially be some valuable information.

Answer 1

I currently also work in a 3 man IT Dept.

I've got the title of IT Infrastructure Administrator, though frequently its 'The Hardware Guy'. My two colleagues are developers but we all share knowledge through idea-bouncing, a local wiki and chat-room reserved for the three of us.

I really depends on what your network is there to deliver, if its just a user network for connectivity then perhaps you can play to your strengths while helping each other out, in my case we need a full time dev for our bespoke code, a system analyst to 'work' the code and keep it tip-top and me, the hardware guy that looks after all the infrastructure behind it all.

It's crucial your team plays to its strengths, our full time developer has a PHD and is fantastic at Perl, so why would he spend his day and priorities fixing EBKAC/PICNIC errors with users? On the flipside, if you put me in the codebase and asked me to fix bug X I'd be helpless, yet I'd in my element managing the RAID5 array on our backup server.

In you situation I agree with the suggestion that no-one should become an expert at either, In my mind, if you can manage the e-mail system, you're clever enough to manage the file server too, it just boils down to a matter of responsibilities

Answer 2

So the job listing I answered for my current job actually listed the title as "IT Generalist." I work for a Managed Services Provider - basically I'm outsourced IT. We have specialties within what we do - I, for instance, do most of our Exchange work - but we all pick up the slack where it's needed. In larger organizations, such as my best friend just went to work for, there are teams that are responsible for specific areas of the infrastructure. He's on the web services team, maintaining the servers that drive the web application. There's a helpdesk team there, and also a more generic infrastructure team that deals with non-client facing systems. This works for them because they have 3000+ employees and a large IT staff.

There's definitely a place for specialization. That place, to me, is within a very large team. If you have 30 admins, you can afford to have 5 of them be the mailserver group. There's coverage if one is out sick or on vacation, and enough institutional knowledge that if one leaves, the infrastructure won't crash.

In a 3 person org, such as you were in, you HAVE to be more of a generalist. You may well be the best Exchange admin on earth, but when the fileserver goes down and Bob The Fileserver Guy is out on paternity leave, management is going to turn to you to fix it. So you need to have the knowledge to figure out what's going wrong, and make a stab at fixing it. Throwing your hands up in the air and saying "I'm the email guy" does not help your organization (or impress your boss).

If you genuinely love one aspect of IT - networking, Linux Samba administration, or whatever - great. Specialize in that. But know that you need to know how the rest of your environment works or your organization runs the risk of lack of coverage, and, more importantly to me at least, your troubleshooting will take much longer. Also - products change, concepts don't. If you love email and admin Exchange - great. Concentrate on the email aspects of things. The next version of Exchange may kill the product line, and then where will you be? I tend to view generalization as a hedge against unemployment a bit too.