Teaching "Juniors" to be Administrators

Have someone who knows what they're doing document a manual task in sufficient detail to allow a level helpdesk person to perform it. Have them perform these tasks; possibly under supervision, but certainly with some sort of audit log of what they did. Review their work afterwards for accuracy. They should be encouraged to communicate any issues with the procedure, any unexpected output or unclear instructions, etc. They should also be encouraged to stop if they encounter something unexpected, and pass it on to an admin. You may choose to have them present when the admin diagnoses the problem.

Helpdesk staff who are capable of following basic instructions accurately are possible candidates for junior admin roles. Staff who contribute improvements to the instructions (e.g. clarifying ambiguities, noticing and clarifying issues with unexpected output) are even better. Staff who can do all that and suggest process improvements (while also having the discipline to communicate their suggestions without trying them out on production systems first) are definite candidates for admin roles, and may actually have a career ahead of them.

People showing this sort of promise should definitely be present when an admin is diagnosing (non-mission-critical) problems, and encouraged to discuss how to automate the process. You'll soon know whether or not the person is ready for a junior admin role!

There is a lot of overlap with this question. Just take that as a list of thing things you need to teach.

One important thing to do is to correctly assess their readiness level so you can respond appropriately. I created a cheat-sheet for myself that is based a model from Management of Organizational Behavior.

• If junior is unwilling or unable you need to provide specific instructions and supervise performance. Do: Tell, Guide, Direct, Establish.
• If junior is unable but willing or confident you need to explain decisions and provide opportunity for clarification. Do: Sell, Explain, Clarify, Persuade.
• If junior is able but unwilling or insecure you need to share ideas and facilitate decision making. Do: Participate, Encourage, Support, Empower.
• If junior is able, willing and confident then you need to turn over responsibility and implementation, he may no longer be junior. Do: Delegate, Observe, Entrust, Assign.

I suspect the more promising junior candidates will be not be unwilling, if they are unwilling to learn you may be fighting a loosing battle. As the saying goes, you can lead a horse to water, but you can't make him drink.

Keeping in mind their readiness level, start assigning them tasks. Try to give them tasks that are just a small bit beyond their comfort zone or current ability. Then help them grow their skills to accomplish the task. Don't use them purely to do the stuff you don't want to do, (write docs, review logs, etc) give some tasks that you think they would find interesting on occasion. When there is minor outage take advantage of it and encourage the junior admin to take lead for solving the problem.

I started out working at a helpdesk at a university, so I have some advice and warnings --

First, depending on your hiring practices, not everyone who gets hired for the helpdesk would make a good sysadmin. Honestly, some of the ones we had didn't make good helpdesk employees, either. (why they thought it was a good idea to water a plant that was sitting on top of a monitor, I have no idea; and why our manager thought it was a good idea to hire people who'd get a chance to practice their new English skills might've been useful to help with our foreign students if they actually had some experience with computers to go with it)

Anyway, the point is -- there are some people that it might not be worth going out the way to help. If you keep an eye on them, you should find out who are willing to ask questions and do enough troubleshooting to find the root cause rather than try to get rid of people as quickly as possible.

Due to the size of our shop, we only officially had four classes of employees -- 'helpdesk' (fielded calls and walkins), 'technician' (handled hardware repairs), and 'senior staff' (effectively, the sysadmins), and 'management' (useful to send the belligerent folks to, as somehow my manager could turn any conversation into a discussion of her grandchildren within 30 minutes, which would confuse the users into submission).

Anyway, the way walk-ins were handled basically worked as such:

1. Person with a problem talks to someone on the helpdesk staff

2. If the helpdesk staff can answer the question, they do.

3. If the person's a new user to software that we supported, we gave them a print-out of the appropriate FAQ or user guide. (yes, now it's considered a waste of paper, but this was the mid-90s).

4. If the helpdesk staff member couldn't answer the question, they could attempt to confer with the other helpdesk members working at the time (normally 2-3 per shift). If we still didn't have a resolution, the helpdesk would relay the message to the senior staff.

5. If the senior staff might either answer the question, or ask to have the user come back to their cubicle for more questions. This was the important part -- this was not a hand-off. (unless the senior staff member thought this was so unique it was unlikely to come up again). This way, the helpdesk person heard how to troubleshoot the problem, so they could deal with it in the future.

So, I think the problem these days is that a lot of shops don't want to tie up too many people on a single call -- so level 1 helpdesk transfers the calls up the chain, but don't hear how to deal with these new issues. Look at how to your deal with users, and see if there's a handoff that prevents the junior folks from being involved so they can learn on the job.

With our system, senior staff members have more interaction with the junior staff, and can quickly assess who's actually learning as they go, and who's sending back the stupid questions. A couple of us got recognition as junior staff members for taking it upon ourselves to update all of the handouts (FAQs, user guides, keyboard maps, etc) convert them from some format our old Wang used to Word Perfect (and later HTML) and build a document management system to track version, when each one was last updated and reviewed (but deemed still correct), etc.

I ended up getting promoted into our newly formed web development group, and our UNIX guy suggested I get a copy of the "Unix System Administration Handbook", and I ended up effectively apprenticing as I later moved to take over responsibility for our gopher/web server (which at the time wasn't considered to be a critical server).

I think the most important thing would be to stimulate learning and gathering of knowledge. Google, wiki's, repeating steps from a manual, that all nice, no offense meant, but what really matters is to know and to want to know.

Knowledge is not something you acquire by just following steps in a manual. Knowledge is something you have to gather for yourself by reading, combining, trying out, experimenting...

So, stimulate reading Serverfault and Staveoverflow, and sites like that. Give them a virtual environment to practice in. Give them tasks, both real (supervised!) and in the virtual environment. Stimulate them asking you question about what happens under the hood, not only where to click.

Most importantly: choose someone who is eager to learn, but also is able to admit mistakes. An eager learner will accomplish in a month, what takes people who have to learn a multiple of that.

Of course, learning comes at a price. Courses cost money. Learning time is not (directly) productive, it's an investment, an investment in better co-workers or employees. Make sure you choose the right courses if you decide onto going that way though. Don't pick the 'MCSE in a week' kinda thingies. That's not going to help much.

John Dalton has absolutely invaluable advice. I would just add that one of the best places to start involving the level 1 person is in basic infrastructure changes such as servers and/or switches. Have them step through basic physical setup, configuration, and observation of the process to add the servers to the domain (or switches into the network).

Once they have basic level knowledge of the network (where things are, how things are connected, TCP/IP etc...) then you can build on that. I think it's important not only to instill in them the proper way of doing things (not trying things on production) but also build their knowledge level from the ground up and not necessarily assume they already know "things".

I think specifically avoiding external training is a rather strange goal. With the wealth of knowledge available online you can become quite the expert for little to no money. Perhaps by external training you mean expensive training or classroom training, which certainly isn't right for everyone. My recommendation would be to look no further than Microsoft's website for all their sysadmin reports, white papers, and demos. Someone who really wants to make that leap up from Level 1 support should have no problem finding the necessary knowledge to get them there.