Slashdot Mirror
Ask Slashdot: Intelligently Moving From IT Into Management?
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?"
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.
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.
Do you have ESP?
I maintained my role as IT Manager, with full responsibility, the entire time. But you shouldn't. Senior Mgmt + IT - Proper Support = job sucks. It does sound like you will have the proper support... we never replaced my position in the IT department.
.252, you are really cooking. Now you have all the non-conforming parts. Took about 15 minutes. Knocking out queries like that made people around me think I was some sort of genius. Yes you can do that in Excel if you can get the component items in the time frame, but it's not as easy. You know your company and the business processes, the data structures, the nuances of the data, etc. Your new guy won't get that for at least a year.
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.
I finally updated my sig, but now it's lame.
Intelligently Moving From IT Into Management?
Sentence does not parse.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
Trust me on this. Even when you've interviewed your candidate, the last thing you want to do is hand over the keys to the kingdom and let the new guy have at it to do whatever he/she wants.
Years ago we hired someone who was meant to be part developer and part sysadmin.
His development skills were showing to be so lacking, and some of the things he thought he wanted to do started to make the people who had been doing the admin duty a little nervous. We didn't let him have full access to the systems for a while.
He was describing making some pretty reckless changes, that he couldn't convince anybody of why we'd do them, and kept saying how he disagreed with how we did things, or said things which made us all think he was a cowboy who had no real sense of why things were done the way they had been, and why we couldn't just re-do everything to look like the way he had it at his last job.
Eventually we more or less decided we couldn't really trust him, and he got neither development tasks, nor sys admin tasks from us. Eventually my manager had to show him the door, because he started getting really aggressive and agitated that the people who had been the admins for several years weren't prepared to just hand him the passwords and let him do as he pleased. But, this was based on the stuff he himself was saying, which more or less amounted to "I don't care, as the admin it's how I want it to be". Yeah, no there skippy.
The more he tried to do things, and the more we saw the results of the tasks we had given him, we became quite convinced he had bullshitted his way into the job, and was trying to take the opportunity to prove (to us or him I don't know) just how much he really knew.
You may need to disengage, but don't do it all at once. Because you're just putting yourself and your company more at risk.
Once you're sure you can trust the new person to do the job, and under the constraints/rules you've laid out ... then you can pull back a lot more.
Lost at C:>. Found at C.
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 :-)
"Time flies like an arrow; fruit flies like a banana." --Groucho Marx
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.