Ask Slashdot: Intelligently Moving From IT Into Management? 125
MightyMartian (840721) writes "I've been working for an organization now for over seven years, my best run yet. A couple of years ago, the company went through some major changes and I bought in as an owner and as a managing director; my responsibilities encompassing administration, finance and IT. It's a small (20 employee or so, plus nearly that many with subcontracting companies) organization so needless to say I retained my direct IT responsibilities.
My fellow board members have decided that I need to detach myself from the day to day IT operations and take over more management duties; in particular in the finance and budgeting end of things. Right now I'm in the process of interviewing a new IT system administrator who will, over time, take on most of my IT roles. However, since this has been a one-man shop for seven years; namely my shop, I confess some reservations about handing over the keys and moving permanently up to the top floor.
Does anybody have any suggestions on the level of permissions for servers, networks and infrastructure I should start with? Do I, for the moment, retain some of the critical functionality; like superuser passwords, and slowly move the new system administrator into his or her role, or do I move more quickly, give him the basics and then let him fly on his own?"
My fellow board members have decided that I need to detach myself from the day to day IT operations and take over more management duties; in particular in the finance and budgeting end of things. Right now I'm in the process of interviewing a new IT system administrator who will, over time, take on most of my IT roles. However, since this has been a one-man shop for seven years; namely my shop, I confess some reservations about handing over the keys and moving permanently up to the top floor.
Does anybody have any suggestions on the level of permissions for servers, networks and infrastructure I should start with? Do I, for the moment, retain some of the critical functionality; like superuser passwords, and slowly move the new system administrator into his or her role, or do I move more quickly, give him the basics and then let him fly on his own?"
Give up the keys (Score:5, Informative)
If you can't trust your sysadmin, you shouldn't have hired them in the first place. Anybody capable of doing the job, with a reasonable background, should be given the opportunity to show their mettle without being arbitrarily restrained.
Do a Proper Disaster Recovery Plan Together (Score:4, Informative)
OK, so if you're asking this, there's no way you've done a proper disaster recovery plan--folks that have done those have sufficient documentation in-hand that someone else should be able to pop in and do the job.
So this is a great opportunity to do that. Together. You gain confidence in your IT minion while s/he gains confidence that they're flying right. And any keys to the kingdom are nicely stored where they should be, so any authorized IT person can get at what they need.
The first step is to get the lay of the land and prioritize services. Gather the keys/passwords/whatever together (make sure your AAA story is good, etc). Come up with what your backup/restore stories are. What do you do if you need to restore one file (the "oopsie" moment)? What about a dead drive/server? What if a plane hits your data center? etc, etc.
Make no mistake--you're in the middle of a disaster RIGHT NOW. You're losing your lead IT staffer to promotion :-)
Been there, it can be hard. Short trial period. ?s (Score:4, Informative)
It can be very hard to let go, to trust the new person with your baby. I think it's generally true that "Whoever can be trusted with very little can also be trusted with much, and whoever is dishonest with very little will also be dishonest with much", so I didn't hand over everything on day one, but I tried not to delay unnecessarily once someone has proven themselves. Maybe give the new person full reign on a NEW project or system, something that won't wreck the company if it blows up. Similarly, maybe a just non-critical systems for a few weeks.
The other thing I tried to do that helped both the new person do the job and helped me feel better was to frequently communicate about how often the new person is asking questions. I try to guide them to ask questions when they need to (don't guess when you don't know), and also trust their knowledge when they do know. So I tell new people I plan to get questions from them. Even if they are an expert in their field, they aren't an expert on OUR systems. Also, experts talk to other experts. I'm part of several groups, standards bodies and FOSS development efforts, where highly competent people discuss ideas. So they should feel free to ask questions when needed - if they didn't any questions in their first week that would signify a problem. Conversely, I had one employee who would keep asking the same questions. She would check with me even when she knew what needed to be done. I had to encourage her to trust her own knowledge.
Knowing that my people ask intelligent questions about the areas they are responsible for, I know what I can trust them with. In those areas where they ask "dumb" questions and really don't know the answer, I know I shouldn't give them that specific responsibility outside of a learning projects.