Follow Slashdot stories on Twitter


Forgot your password?
Security IT

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?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Intelligently Moving From IT Into Management?

Comments Filter:
  • Give up the keys (Score:5, Informative)

    by Anonymous Coward on Tuesday April 29, 2014 @01:45PM (#46869957)

    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.

    • by alphatel ( 1450715 ) * on Tuesday April 29, 2014 @01:52PM (#46870067)

      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!

      • Management is all about psychology.

        Slapping clients on the back.

        Getting them to open up their wallets and... SHOW YOU PICTURES OF THEIR GRANDCHILDREN!

        Slapping employees on the back.

        Getting them to open up their wallets and... SHOW YOU PICTURES OF THEIR GRANDCHILDREN!

        As long as you continue to think like a gearhead, you haven't made the necessary mental and spiritual transition which is necessary to become a true manager.

        You need to start thinking like a shrink.

        Or at least like a father.
        • +1 Amen

        • Perhaps you need to think like a psycopath? []

          Don't get me wrong, management is about all you said but you left out two things: manipulating and using people.

          Yep, it is a cynical view but in the real world, you meet your goals as a manager or you get fired. Many times, you have to sweet-talk undesirables to do things for you, knowing very well that you don't mean a thing you say.

          As George Burns put it: "Sincerity - if you can fake it, you got it made"

          That is why I hate management and prefer coding or doing ot

    • by swv3752 ( 187722 )

      Trust but verify.

      Give full sudo or equivalent for the first month or two, but keep root/administrator separate and stored securely. Review the logs regularly. After a month or two, you should have enough trust to hand over the reigns, but spot check occasionally.

      • Because he'll NEVER figure out how to get root access with only full sudo!

        • sudo su -
        • by swv3752 ( 187722 )

          It is not about preventing his access, just that you can track it. Sure if he is super competent, he can hide any nefarious doings, but if he is that good, he doesn't need to even work for the original questioner.

          Could I hide a one time action to hide something nefarious as a system admin? Probably. Could I do it everyday and not arouse suspicions? Not likely. I doubt I could both perform my job and leave evidence in the logs and hide nefarious doings long term.

          My manager holds regular one on one meeting

        • by Minwee ( 522556 )

          Because he'll NEVER figure out how to get root access with only full sudo!

          Apr 29 16:19:45 REALLYSECURESERVER sudo: newguy : TTY=pts/4 ; PWD=/home/newguy ; USER=root ; COMMAND=/bin/bash

          Right. Just like nobody will ever figure out what that log message means.

          • Because he'll NEVER figure out how to get root access with only full sudo!

            Apr 29 16:19:45 REALLYSECURESERVER sudo: newguy : TTY=pts/4 ; PWD=/home/newguy ; USER=root ; COMMAND=/bin/bash

            Right. Just like nobody will ever figure out what that log message means.

            Once you have root, modifying logs is easy.

    • Make sure to negotiate a generous golden parachute. If the new guy screws up the systems, bail out immediately while the company's still solvent.

    • by CAIMLAS ( 41445 ) on Tuesday April 29, 2014 @04:12PM (#46871609) Homepage

      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).

      • 2) The fuckups...They're better suited for desktop support roles or development.

        Oh no you don't! Don't send those fuckups over here to development either.

      • by Xest ( 935314 )

        "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"

        Yes, because if there's one thing development needs it's people who make a mess of things, can't follow best practice and can't even do a simple job like running a network.

        What the fuck?

        • I'm a developer and deeply grateful that running the network is somebody else's job given that I can't even seem to figure out what in a windows 7 reinstall/re-update has completely nuked my wireless connectivity on my silly little home network. Never assume the other guy's job is easy. Even if you know a thing or two about how to DIY.

          • by Xest ( 935314 )

            Erm, I worked as a network administrator for 7 years before I became a developer professionally. The whole reason I made the jump was because it just wasn't challenging.

            In terms of complexity of problem solving, software development is way further up the chain of complexity than running a network. It's just inherently far more complex having to know how to design systems, having to develop configuration schemes, having to implement, and test and maintain them, than it is to just do one small facet of that -

    • When you got the job, your boss entrusted you with these privileges. Now that you are the boss, it's your turn to entrust someone else with it. Otherwise you'll never be able to really sit upstairs.
    • ^this.

      By all means, audit the guy every so often to make sure he's doing a good job. But give him full authority to do that job.

    • I was just going to write the same thing: if you hired someone you trust, trust that they are going to do the job well.

      I like the three month transition plan given by Capt.DrumkenBum below, but I'd also like to add that you should try not to take too much pride or ownership in your existing systems. If new guy is going to change them and has good reason, be supportive, even if it feels personal. New guy has to run the ship now, let him run it the way it works, and works for him. Even if you have to say

    • Agreed. You hire the admin and hand over the keys. You are probably being asked to be more strategic and that should not include owning superuser. I would encourage a process which does not allow steady state administration using root/administrator. Those should be special cases (even when you owned the privileges). More restores are because a user made an administrative mistake in an over-privileged sessions than because of hardware errors.
  • by Trailer Trash ( 60756 ) on Tuesday April 29, 2014 @01:49PM (#46870013) Homepage

    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.

    • by Capt.DrumkenBum ( 1173011 ) on Tuesday April 29, 2014 @02:11PM (#46870311)
      When I took over my current position, I leaned heavily on my predecessor. It wasn't until he took a months vacation that I finally had to make the job my own.
      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.
      • by unimacs ( 597299 ) on Tuesday April 29, 2014 @03:10PM (#46870949)
        One recommended change an auditing company made to us in regards to IT is that each member of the staff take at least 5 consecutive business days off each year without any contact with the organization. That's forces the staff to make sure they can adequately cover for each other.
        • by Collective 0-0009 ( 1294662 ) on Tuesday April 29, 2014 @03:20PM (#46871027)
          I heard that is required in the banking industry... to ensure someone isn't doing some cooking of the books. I like the idea for both reason. You force the department to handle a "hit by truck" incident once a year and you get to see all the dirty laundry.
          • I heard that is required in the banking industry... to ensure someone isn't doing some cooking of the books. I like the idea for both reason. You force the department to handle a "hit by truck" incident once a year and you get to see all the dirty laundry.

            When I worked in banking, the requirement was actually 2 consecutive weeks...

            • I still work in banking and I believe it's not still required, but a lot of banks still enforce it. I do enjoy the two weeks off though!
        • Good idea.
          The last time I took a week off, 2 days in my phone started ringing off the hook. I was in a museum at the time.
          I correctly diagnosed the problem over the phone and told them what to do to fix it, but when I got to work the following Monday. The problem still had not been fixed. I don't think anyone did any work that week.
          Sadly, they learned nothing.
      • A good manager knows how to motivate this employees to do their work well without the manager stepping in and doing the work for them. I say ease into it and shows him the ins-and-outs of how you do things, but be ready for his own opinions especially if he's had more training than you. Ultimately you have to be a team player and learn to let go more, but s/he is still a rookie and as a manager you do have a right to check in on his/her progress.
  • by Anonymous Coward

    You're a suit now. Even if it's a small shop you have no reason to touch the network after your responsibilities are over. If you don't trust the guy you're hiring, find someone you do.

  • by Anonymous Coward

    Interview carefully, budget sufficiently for the position so you get the right person. And then GIVE THEM THE JOB. If you half-ass the handoff, it undermines their confidence and everyone else's confidence in them.

    • This. I am in the hell of being the replacement, and my boss won't do more than dribble the responsibilities out. 2+ years, and I still am grasping for more, yet he is drowning, and won't give up any control.
  • Intelligently? No, first you need to get a lobotomy.

  • by ip_freely_2000 ( 577249 ) on Tuesday April 29, 2014 @01:58PM (#46870159)
    You hire someone and hand over a COPY of the keys. Rule #1 is that you ALWAYS know admin passwords and whatnot. That's not only for your comfort, it's part of due dilligence as your new guy might be hit by a bus on the way home after his first day. Then you step out of the way and do the important job of running the company. If you're not comfortable with this, reexamine your career path. It's time to let it go.
    • I'm surprised no one mentioned this so far. DOCUMENT EVERYTHING. Any IT person worth his salt should have thoroughly documented the configuration, standard software loadout, group policies, audit policies, etc... such that if one does get hit by a bus, the organization won't be crippled. Having handed over the keys on more than one occasion, I can honestly say that ip_freely_2000 is right, maintain a couple of your own hooks in case the new guy doesn't work out, but take a step back and enable him to do his

    • You hire someone and hand over a COPY of the keys. Rule #1 is that you ALWAYS know admin passwords and whatnot. That's not only for your comfort, it's part of due dilligence as your new guy might be hit by a bus on the way home after his first day. Then you step out of the way and do the important job of running the company. If you're not comfortable with this, reexamine your career path. It's time to let it go.

      This is very good advice, but I'd like to elaborate a bit on this. First of all, somebody, but not necessarily you (I have no idea how things work in your company) does need to know those passwords besides the new guy. I'd also like to suggest that you make that requirement an up front part of your interview process to find your replacement. Find out if the guy has a problem with it and explain bluntly that it's not negotiable and he will be expected on his first day as one of his very first duties to tu

  • by Anonymous Coward

    I am an IT analyst working for a school district. There are 3 of us on the IT team and we collectively manage and administrate all things IT for 7 district buildings.

    When I first became employed here about 4 years ago, the day I walked in the door I was handed a key-ring with GM keys to all the buildings and was given a domain admin account. It is worth mentioning that I was completely green. I had never seen a server in the flesh nor had I ever logged into (much less administrated) a domain account. I was

  • You are challenged by a common struggle for IT professionals who start technical and move up through management. When moving up from within, it is very important to challenge yourself to let go of the old role and start anew. Your starting point when you hire someone should be that you trust and have confidence in them to run the shop under your direction. By retaining any sort of privileges, you would undercut that confidence and place your relationship with your IT staff on crutches.

    Develop your abili

  • by Anonymous Coward

    A year ago I was hired as the sole system admin to take over the role being held down by a manager. I was slowly given access and responsibilities and expectations, starting with both some of the easiest and the some of the most problematic systems first. The advantages were I got to acclimate to the environment by accretion, and my manager was relieved of the most tedious of the day-to-day management tasks. Today I not only have full access and responsibility for all of the Linux servers, but am participa

  • You need to teach everything you know to your new sys admin and then let him fly on his own. Sooner or later every bird must leave the nest.

    As a manager, you also need a backup plan if he should get hit by a bus or leave the company one day.
  • My Experience (Score:4, Insightful)

    by Collective 0-0009 ( 1294662 ) on Tuesday April 29, 2014 @02:02PM (#46870225)
    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.

    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 .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.

    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.
  • Problem (Score:4, Funny)

    by SuperKendall ( 25149 ) on Tuesday April 29, 2014 @02:06PM (#46870255)

    Intelligently Moving From IT Into Management?

    Sentence does not parse.

  • If you were interviewing for the position, would your first thought be, "I so don't want to work there as that guy is going to be second guessing my every move, countermanding my decisions, ruining my job satisfaction and making me regret ever joining there"?

    It's not your baby, it's your job, let it go. Think if it like a rebellious teenager, you've invested all you can in it, you are done. Now it's time for the cruel world to influence it for better or worse (which is subjective anyway). Others have sug

    • If you were interviewing for the position, would your first thought be, "I so don't want to work there as that guy is going to be second guessing my every move, countermanding my decisions, ruining my job satisfaction and making me regret ever joining there"?

      I would contend that any new sysadmin who is thinking the above is the last bloody person you want working for you.

      The days of the IT prima donna are over in most sane places, and the company needs to look out for its own interests, and not merely coddl

  • by Anonymous Coward

    Give it up, give them the keys and keep a copy for yourself. Done, end of story, there is nothing else to discuss. If you can't do that, you need to get out of management right now! That's what being a manager, a good manager, is all about. Hire and surround yourself with people you trust and THEY do the heavy lifting and work, you manage them because no matter how much you trust them and how good they are, you still need to be their parent/manager/teacher/guide. But they DO the work, NOT you. If you d

  • If the new admin is competent, there's no reason to not give him full access to everything. If he needs to be trained, then ease him into it. Not giving a competent admin full access is one of the biggest mistakes you can make, as it doesn't instill confidence, and breeds miss-trust. The second biggest mistake is never allowing the guy who needs a little guidance or training to ease into the job.

    In other words, you have to let go, and let someone else do the day-to-day operations. Managing an organizati

  • by dysmal ( 3361085 ) on Tuesday April 29, 2014 @02:13PM (#46870337)

    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.

    • Heh. Reminds me of the time one of my bosses (aka president of the company) decided to reboot a Linux server. By using 'sync sync sync reboot'. In 2009.
  • Give the new sysadmin full administrative access to everything he/she will need to do the job. By all means, make sure you retain administrative passwords and keys, but only use them if the unthinkable happens (your sysadmin gets hit by a bus or you have to fire him/her). As other posters have said: expect mistakes, expect the new sysadmin to be less than perfect, steel yourself to accept 'good enough'. Listen. Don't let the shit flow downhill; your job as a manager is to give your staff (even a staff o

  • Ease into it ... (Score:4, Interesting)

    by gstoddart ( 321705 ) on Tuesday April 29, 2014 @02:19PM (#46870413) Homepage

    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.

  • by Charliemopps ( 1157495 ) on Tuesday April 29, 2014 @02:22PM (#46870441)

    My rule of thumb has always been "What will happen if I get hit by a bus tomorrow?" and so I'm already pretty much set. I could walk out tomorrow and everything would be fine. The new guy might be slower and not get things fixed as fast, but he'd be able to do it. I think you need to take the same approach. The whole "Well, he can just call me if he has trouble" isn't going to work if you're on vacation or something. As a manager you should be prepared for anyone in your company to leave, including yourself.

    If you have processes that require personal knowledge to complete, then you need new processes. I think this change will be very good for your company. All the things you're worried about now are things you should have been worried about all along, they're just out in front now. Are you going to hand over super user passwords to the new guy? What if he gets hit by that bus? What if your buildings flooded? You need to think long and hard about these sorts of things.

    I read an article years ago while I was in college working at McDonalds part time that said McDonalds had been so successful was because their processes were made in such a way that they could take anyone that was ambulatory and had an IQ above 60, put them behind the grill and they'd be able to do the job. I thought about it while at work and sure enough... how to make the burgers was graphical... you dont even have to be able to read! Now that's a well planned process. This wont work for IT obviously, but that's kind of the way you need to approach it. Also, the easier the process, the cheaper you can hire. Make everything super easy, then hire a smart guy and he'll have lots of time to use his smarts for things other than finding super user passwords.

  • by lazarus ( 2879 ) on Tuesday April 29, 2014 @02:38PM (#46870617) Homepage Journal

    What you need are good processes and a common way of expressing how these processes are adhered to. Get yourself ITIL certified and make sure that either the person you hire is certified or that is the first thing you have them do. You don't have to be a big shop for this to be relevant.

    On a day-to-day level you need to be the person who is accountable for any and all changes, which mean you must approve them. Yes, you are handing over the keys, but not permission to run roughshod over the environment.

    Also, a good manager "inspects" but does not "micromanage". If you keep this principle in mind and establish some good processes, you will be golden.

    • by CAIMLAS ( 41445 )

      ITIL certified? Seriously?

      Understanding process control is one thing, but ITIL is stupid governmental nonsense and requires markedly more than 20 people in a shop to properly implement.

      Meaningful process determination can be determined through effective interviewing and early monitoring/guidance alone.

    • by Dahamma ( 304068 )

      Actually, he's asking the wrong question because IT and management are not mutually exclusive. IT is a field. Management is a position.

  • I don't think that word means what you think it means.

    Intelligently move into management?

    Seriously, this is Slashdot you are asking, you've already FAILED at the intelligently part..

    I get the impression that you've already agreed to the new job and now are having second thoughts but cannot take it back. If this is true, stop messing with Slashdot and HIRE your replacement. You have no choice, learn to sit on your hands and if you don't learn this quick, you are going to always have TWO jobs which you wi

  • Read this book Sudo Mastery [] And wean your new hire on to the access he or she needs while weaning yourself off. The information in this book also comes in handy when it comes to pointing fingers when something administrative goes very wrong. It's only 144 pages, but worth every page.

    This is assuming you run *nix based systems, you did not specify your infrastructure.
  • by wannabe ( 90895 ) on Tuesday April 29, 2014 @02:48PM (#46870729)

    I can appreciate your situation and need for advice, but if you are asking these questions here on /., you may need to step back a bit a lay some ground work. I've been where you are and made the transition and here's some hard lessons I've learned.

    First, if you are at a point where you are trying to hire a person to replace your technical function, understand that you are on a path to grow beyond a single person. This means that while you were capable to deal with the technical responsibilities, your management function facilitated the ease at which you could accomplish things. Your replacement will not have the flexibility of authority you enjoy. This means that new processes and procedures will have to be put in place to accommodate that. This also means, as you go through that exercise, you will determine that a single person will not have all of your qualities. This means there will be more hiring on the horizon. Plan accordingly.

    Second, your instinct is to not allow your baby to be in the hands of another parent. Get over that impulse quickly or you will burn through competent staff very quick. Oversight is good but micromanaging is not. A good sysadmin / network admin is worth the money paid - a mediocre admin can often have a negative value to your operations. You are hiring someone to do a job - hire the best you can find and afford and let them do it. If you don't or think you know best, you are setting yourself up to play with the B-team or worse.

    Third, I don't know your line of business, but now is a great time to begin setting up an infrastructure for auditing and monitoring. If you want to be a real company and not fly by the seat of your pants, understand that IT is a solved problem with many best practices that can be adopted and audited for success. IT operations, Software development, information security all have standards associated that can help ease your transition. Once you fully implement that, you will find your IT operations run smoother and you become a much more attractive organization to various clients and contracts.

    In short, embrace your role. You are a manager and are in charge of strategic vision. You are not a tactician nor are you a technician. Understand your role and do it to the best of your ability. The big part of that is hiring people who will execute your vision.

  • Seriously, the more information you can document into runbooks, the easier his ramp-up will be. Don't be afraid to be verbose, and work with him to fill the knowledge gaps.

  • Will you still have management responsibility for the IT functions of the company? If so, then you need to have regular meetings with this new staff person. Major purchase requests, major network, sever, and backup changes should still be discussed with you. Disaster planning, IT budgeting, information security you should be heavily involved in.

    But day to day operations you should keep your nose out of once you are comfortable that they know what they're doing. Let them do their job. At the same time,
  • by W. Justice Black ( 11445 ) on Tuesday April 29, 2014 @02:57PM (#46870825) Homepage

    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 :-)

  • Seriously, my suggestion is develop policies as well prior to just handing everything over to some new person. Put in change control processes at least for the first year and then as you get to know that person and their skills you can untangle yourself from the IT specific duties. I've never actually moved from IT to what seems to be a completely different function from IT (even if some of the budget revolves around IT purchases) but even if you were becoming CIO, for example, you would be in the same po
  • As you put it, does it make sense? We made a partnership with those responsibilities, yeah, we do our part which is quite boring, you are having all the fun...poor us. Does it makes any sense? IT is a big responsibility, and many businesses have gone under due to IT mismanagement. Plus, it gets time to an IT admin to get used to the infra-structure. Ideally you should manage the IT department, or create one if it doesnt it exists formally. Either way, the idea of you leaving town and leaving a substitute ov
    • by ruir ( 2709173 )
      About credentials, I manage a network a medium-sized network of linux servers, and even I dont use and dont know the root password. First thing I did when tooking over sysadmin responsibilities was nobody used root anymore, and started logging in with their own account. So I have logs, accountability and knows who is doing what.
  • I wasn't able to get a replacement for myself, but the team was big enough that I was able to 'help' for a while though I mostly just took on the things the rest of the team didn't want to do so they could focus on the important tasks. So I got rather familiar with RT (that's Request Tracker, not Windows RT). In the end, my boss didn't give me the budgeting or hiring repsonsibilities I wanted, and he eventually let me go.

    I'm now still quasi-technical, but more like an IT analyst with the ability to simult

  • You should develop a hand-over plan. Once hired, the new admin and you should agree upon certain aspects of the plan. 1. A very thorough background check should be performed. The further back, the better. 2. During the vetting process make sure more people than you interview the candidates. Trust your qualified team members, even if pulled from the user pool. 3. Once hired and on-boarded, turn the keys to the kingdom over to the admin. That is why you hired him/her, to replace you as IT Mgr. An untru
  • I'll agree with almost everyone else on here -- never leave yourself in a position where one person can wreck everything if they decide they're having a bad day. Look at the Terry Childs incident. You can debate the reasons why he did what he did, but the facts of the case are clear. He set things up such that he was the only one who could bring back router configs should they reboot by not storing them in NVRAM. Since he was allowed to do this, his refusal to hand over the console passwords one day essenti

  • Start with the basics; document operational procedures, implement a change management system (can be as simple as an issue tracking spreadsheet) and hand them over to the new person for comment. Start handing over the responsibilities that impact your time the most (As you are going to be training a new person, demands upon your time are going to go up for at least the first 2 months). This process will dictate the level of access you give them (but use common sense). Micromanage until you get a good feel
  • by raymorris ( 2726007 ) on Tuesday April 29, 2014 @03:52PM (#46871379) Journal

    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.

  • Do a complete offline backup snapshot, on media inaccessible to the newbie.
  • Learn to use them. You out them where there should be a comma.

  • The new guy will never be as good as you are. That's just how it is. He'll make mistakes, he won't take things seriously enough, etc. etc.

    As the part-owner of the company, you're just going to care more. That's OK. It's your job to take the future of the business seriously. His job is to keep the servers up and running. He should be good at that, and take that seriously. It's not his job to be you.

    If you don't turn it loose, they'll quit. Any self-respecting professional will. Micromanagement makes people s

  • Intelligently Moving From IT Into Management?

    Not possible.

    Especially given:

    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.

    There is a chance that you are ready and all there is to it is for you to find a capable replacement for yourself. But there is a ever-so-slightly greater chance that you aren't ready, that you'll be a micromanager, making yourself and subordinates totally miserable.

  • I think he said "Being responsible, I will direct: and will be responsible for nothing that I do not direct".

    If the new guy thinks you're looking over his shoulder all the time, he'll (rightly) think you don't trust him. And you're either fully trusted or you're not. If I was hired into a position and had the boss checking on me all the time, I think I'd walk. (Well, maybe not - I have bills to pay - but I'd be annoyed).

    And as someone else else, if you hire the right guy, you've got no problems.

  • Sir, you can hire me, sir. Hookers and blow go on company's american express, sir. The secret clone army is paid in cash, sir.
  • Share the keys with the new sysadmin, but retain your own access.

    You know how to fix things, just keep that possibility, it may be useful

  • As I moved from programmer to team lead to manager to director, I had to delegate more and more of my technical responsibilities to others. As an accomplished programmer, I missed many of my old duties, in which I had excelled. But along the way, I realized that my real value to the company was no longer in the code I could personally write, but in my ability to build a team and help them be successful. I still write code for fun at home, but on the job, I have learned to let others do the hands-on work,

  • "Don't let them promote you. Don't let them transfer you. Don't let them do anything that takes you off the bridge of that ship because while you're there, you can make a difference."
  • I find it telling that everyone here focuses on the technology. You should be focussing on being a good manager, building your management, leadership and recruiting skills. 80% of staff leave because if their manager, only 20% for other reasons, so treat it with the same passion and requirements as you did becoming a lead technical person. With the right skills, finding a good person is easier, developing is easier, their likelihood of leaving is less, and you can be a more valuable asset to the organisa
    • by ruir ( 2709173 )
      The problem as insofar I see here, is not exactly "moving" to other responsibilities, is only lack of planning and timing of the handover of it. Should be done gradually and a compromise made, and not overnight. Those things take time. Maybe with the help of a plan, or even, god forbids, the help of external consultants.

"The number of Unix installations has grown to 10, with more expected." -- The Unix Programmer's Manual, 2nd Edition, June, 1972