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?"
Be there for him... (Score:5, Insightful)
Be there for him, but not looking over his shoulder. Also remember that he'll make mistakes, just like you have over the years. It's difficult but you'll find yourself more effective when you learn to delegate.
Re:Give up the keys (Score:4, Insightful)
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.
Keep your own administrative access, but since you were barely qualified to be a sysadmin in the first place, just learn to let go. The organization will be better for it while you move back into finance where you belong.
Colonel Meyers: Are you new to the infantry, Major?
Maj. Malcolm A. Powers: Yes, sir. Just came over from supply.
Colonel Meyers: Were you good at that?
Maj. Malcolm A. Powers: Yes, sir!
Colonel Meyers: Well then, stick to it because you're a walking cluster fuck as an infantry officer. My men are hard chargers, Major! Leutenant Ring and Gunny Highway took a handfull of young fire pissers, exercised some personal initiative and kicked ass!
My Experience (Score:4, Insightful)
I would however, keep the title. You need it to keep the passwords and system access. Maybe in that small of a company it won't be a problem. If you are like me, then you probably don't feel you are the best manager in the world, but you have the ability to access data better, faster, and more aptly than your manager counterparts. You do not want to lose this edge. You want to be able to run a quick query to pull: all component items from all 123ABC parts produced in the past 6 months with a serial number that starts with 2, of class 43, and started on second shift. That's impressive, but when you combine it with the inspection system to determine which ones had a hole that was reported as less than
Also, you want to be in on the projects going on in the company. You have no idea how much insight you gain into the various departments because IT reaches all departments and those projects that cross departments are a great place to find poor processes and figure out what's really wrong with the department. Also people talk to the IT guy (even manager) much different than the other managers/bosses.
There is quite a bit of precedence for you climb. There will only be more in the future for the reasons stated above. It used to be the CFO that was involved in every department and was a shoe in for CEO. It's now the CIO that is the shoe in.
Re:Be there for him... (Score:5, Insightful)
So be there for the new SA, but make sure that after a certain point it all becomes his responsibility.
Something along the line of:
First month, training
Second month, I will help
Third month, I will answer questions. If I remember
Past third month, Moral support.
Sounds like my bosses boss (Score:4, Insightful)
My bosses boss was the sys admin here. He's moved up over the years. He still keeps his hands in the sys admin stuff on occasion. You know what happens? He fucks things up in the process! Things have changed in the past 5 years that he isn't aware of and so shit breaks when he tries to help.
Do yourself a favor and do one job and do it well. Give up the keys and let someone else sink or swim. If you don't stand aside, you'll be a liability more than an asset.
Re:Be there for him... (Score:4, Insightful)
Re:Give up the keys (Score:5, Insightful)
Trust is earned.
You've basically got three kinds of sysadmins, in my experience (though obviously there's a spectrum).
1) The jerkoffs who don't do their job and squander company time. They don't fix things, they don't improve things - insofar as it's not visible to management. These are the kinds who put in backdoors and may put in needless obfuscation to maintain their relevance.
2) The fuckups. These are the ones who needlessly make a mess of things by not following basic best practices. They're better suited for desktop support roles or development. They may be good, damn good, but they're not systematic enough to be good admins, and overlook crucial things (like, "oh, I'll just leave this point-to-point tunnel up without encryption and get back to it later").
3) Everyone else. Doesn't matter how good they are and how fast they are at doing it, but they follow a couple basic rules: be thorough, be diligent, and always try to improve.
You'd know pretty soon which kind of administrator you've got. Start with a short term contract. Give them a limited scope of responsibility - a zone, like a set of specific systems or a project, such as something like upgrades and/or documentation. Maybe give them a problem to solve. Give them something that's intentionally expansive but of limited impact for them to work on and see how well they do.
If they do well and don't surprise you with something atrocious (oh, I don't know: can't convert MB to GB would be a hard stop for me - I've seen it), let them stay on.
But they really do need to see how the shop runs and be your PFY for a bit, first. There are very few people who can jump into someone else's baby and drive it like a pro, it's going to take a long time for even good sysadmins to catch on (my replacement is still catching up after I left 3 years ago, and I was only there for a year, thrown into more or less the same environment he was: his approach has been to slash and burn whereas mine was more granular due to less levity in outages).