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.
Trust them, delegate the responsibility to them, thats what a responsible manager would do.
Ask them for their plan on how to handle things, ask for how they are going to ensure it is going to plan. What metrics they will use etc. How they will reduce any risk.
Make your self available to answer questions at regular times. Have different meetings where they describe to you how its going.
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?
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.
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.
Get over yourself.
Here's the deal. You're not just a partner, you're the frigging managing partner. Your job is to make it rain money, bitch. Go shmooze, go get some fat new clients, and make fat-stax for the crew. If you wanted to be a techie, you shouldn't have bought yourself a company.
Just make sure you are backing up critical data and configurations as often as possible (and checking/testing them yourself) so that you can fix anything the new Admin breaks. Once you've built up an acceptable level of trust, let it go completely.
I hope you are hiring someone with experience. Honestly, how difficult can your environment be if you did it by yourself? If you restrict the new employee right off the bat he may not have the resources to be successful. Make sure you conduct you interviews in a manner so that you are getting some to fill your shoes. You should be able through your professional experience be able to ask the right technical questions to keep the bullshitters out.
Intelligently? No, first you need to get a lobotomy.
Table-ized A.I.
...... say "fuck it" like everyone else.... no matter what you do, not matter how much you plan and no matter who you hire.... it will never be what you wanted, what is needed, what is best for the customer, etc...... Why the hell do you move from IT to finance anyways? Simple... not cause you are so freaking good at it, but it pays you to do so! So just shut up and move on, what ever you try, it will never be what you want! Just like everyone else! Just care about you and that is it, just like everyone else! (the ones that are still at the bottom of the chain do not count, since they are there cause they got kicked down or never got up (and a really.... REALLY few of them out there just moved back on their own and there is no comment to those).
and get some popcorn to enjoy the show
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 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 shocked at the time. I thought I'd be given a limited access account to get started with and then given more tools as I proved myself. Fast forward to today and there have been no cataclysmic errors on my part, so I suppose it wasn't the wrong decision for my superiors to have trusted me with the keys to the kingdom.
Granted, your situation is a bit different being in the private sector and considering he will be flying solo. I would take into account your gut feeling towards the new guy. Does he seem stable/dependable (which I would hope since I assume you hired him) and does he possess enough knowledge, both about the technologies in general and the specific oddities of your unique environment, to take the reigns without flipping the cart? If so, then I would consider giving him all the keys as both as sign of trust, and so that he doesn't have to try and find time to pester you to log in and do something that needs doing with higher permissions.
TL;DR: If you're letting go of the reigns, give them to someone else.
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 abilities to hire well and trust your hiring decisions. Be willing to take a chance: become uncomfortable with your new role. You should have reservations, not about departing from your old role however, but instead about all the changes and unfamiliarity that come with moving to the "top floor". Good luck. It sounds like you are in a great position with a bright future.
In a small environment like that, and with your background, you should have all the Administrator passwords (stored in a safe place) and the new administrator should always make sure you have them. If he is off sick, you then have the options to use them in an emergency.
Having the passwords does not mean you should be using them. Leave that to the new guy, and if he has any trouble with anything, he can always come to you at that point.
Your login account should be changed to the same level of your peers. With you having some common read/write,file scan access with your team, and others you need to share things with.
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 participating in new projects, planning upgrades, participating in re-architecture planning meetings, handling the on-call duties, and introducing new technology to the environment in the form of new software tools and new programs I write. By being allowed to take on tasks and problems as they presented rather than have everything thrown at me at once, it allowed me to both learn the environment and build trust with management and my peers.
Give him all the easy stuff, change the backup tapes, user support, ensure that the documentation for everything is up to date. Because if this guy doesn't work out you'll be knee deep in managment while trying to train his replacement. As the new guy takes to tasks give him more complicated work, the idea is to build a level of trust in his abilities before you hand over anything critical enough to bring down the network and cause a great deal of downtime.
It might be easier to outsource this piece altogether if it isn't a core copentency of the company. I mean a local IT support shop, not overseas.
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.
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
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 suggested you need to let it go already, so you obviously can't see your own short-coming in this regard.
If it helps, go on vacation, travel out of the country, only respond to inquiries from your replacement in that time, never check in or up on them. If it all goes south, they will fix it. If mistakes are made, they will learn and grow. You, however, need to stop looking backward, and look forward instead.
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 don't give it up, you're a micro-manager, and NO micro-manager is good at their job, period.
If you do retain access to the critical functionality, and continue to perform some of your direct IT duties in addition to your new managerial responsibilities, you will find that over time, this will become the expected norm. Coworkers who were used to come to you for all things IT will continue to do so, and assuming your management duties keep you fairly busy, your workload can get overwhelming in a hurry. The longer you wait, the harder it will be to transition the direct IT responsibilities to the new admin.
I understand it is hard to hand over control to something you invested a considerable amount of time in, and in this field we are all used to wearing multiple hats at one point or another, but your best course of action is to trust whom you hire, and in the event that the new sysadmin does need help, provide it directly to them instead of resolving the issue on your own.
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 organization like that means trusting your employees to do the right thing. You need to get comfortable thinking on a high level, and not worrying about how the servers are configured.
AccountKiller
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.
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 of 1) room to do their job, and shelter them from the sturm und drang in the board room.
if you can't give up the keys, then perhaps you should be interviewing a finance manager instead of a new it director?
I think that you should consider your replacement's needs rather than your own. You don't want to have to hire again in short order because you've either overwhelmed her with everything involved with the job, or because you won't let go completely.
If you decide to hire this person, the first thing to do is ask how she would most like to proceed with the transfer. It may be a quick ramp up, or a slower transition. And don't make this a single conversation, either. The replacement may be hesitant to come to you to discuss a change in the pace. Sit with her and mutually evaluate the progress.
Speaking as someone who was literally just thrown into a sysadmin job this month and had to hit the ground running, I would have preferred a slower transition. There have been a few days where I've been tempted to flip the desk and walk out.
As someone mentioned too, feel free to keep a copy of the keys, if for no other reason than to give you peace of mind.
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.
1. Learn about Management. Most individual contributors who move into management are horribly unprepared for it and end up failing. An individual contributor is measured on what they accomplish. A manager is measured on what they can accomplish through other people.
2. If you hire a qualified person, give them free reign. If something breaks, it wasn't built right in the first place and needs to be rebuilt properly. I'm not advocating chaos but most older IT people have created systems which are incredibly fragile and a fresh login will often help find where these landmines exist.
3. If you're still advocating IT then you're setting yourself up for failure. IT is a dead discipline. Move to an Ops Engineering mindset. Forget about big-iron high-availability, look at small, fast and no single point of failure and yes, a dual-PSU server is a SPOF.
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.
+1
Seriously, at some point managing operations has to come second to company growth. Put your strategic vision goggles on when you leave the house every morning.
Now, as someone who has also very recently transitioned from the world of IT to money stuff, I will say you need to be very careful about it. Right now I have very few resources at my disposal to turn to when things get mucky. And, sometimes you need some accounting magic to get that balance sheet to balance (find an asset, depreciate it! have the company loan itself money!) Now, I've found it to be ridiculously easy compared to IT - oh, sure, I have a vast amount to learn, but I've found I absorb the knowledge quite fast. My recommendation to you is to begin building that safety net - find some friends who are amazing accountants (controllers) you can discuss things like P&L's and balance sheets with. Find finance friends who can give you sage advice on everything you don't know - are there tax ramifications if you make that purchase this quarter?
Then, just remember, always make sure the decision you're making isn't going to affect making payroll. If it does, what's your plan?
----- obSig
Just proof of Abraham Lincoln's maxim: Any man can handle adversity pretty well, but to really test a man's character give him power.
Intelligently Moving From IT Into Management?
There's a term for that: downgrading.
And I'm not sure that it can be done 'intelligently'.
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.
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.
I am not interested in articles about life extension advancements.
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 will be horrible at, one paycheck and zero free time. .
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
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.
Brought to you by Carl's Junior.
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.
"Draw them in with the prospect of gain, take them by confusion." Sun Tzu
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, keep copies of important passwords and contents in a secure place. I'm assuming you will still have to act as this person's backup if they're not available for whatever reason, so you need to maintain a working knowledge of your systems.
I once took a job as a programmer/sys admin for a small organization of about that size. By that point in my career I had lots of experience with both and was much more comfortable with the technology than the management person whose responsibilities I was supposed to be taking on. The thing is he could never quite let go and would second guess even the smallest of changes I wanted to make. Eventually I left. So don't make that mistake. Be aware of what they're doing, but don't micromanage.
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
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 position albeit the "go to" person for a little while to solve the inevitable technical issues. But I truly think you must set up some sort of checks and balances from the start or your @ss is going to catch a lot of h3ll if things go wrong. Best case, your new person could screw things up to the point where you must now juggle both this new management role PLUS the IT tasks too....yikes! This is why I don't mix the two as MANY people assume IT is so simple and just clicking buttons and taking long lunches--until the Sh*t hits the fan and then WHO do they look to...you know what I mean..good luck to you...
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 overnight is a very bad one. Ideally you should coach a junior and hire an IT admin/partner and train/work with him, for at least a year and half. After the time, you will have an idea what he is capable off, and he will know well enough the infra-structure to be trusted to make his own decisions. If he is very good, it will be probably between six months and one year, but not before.
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 simultaneously speak at every level from customer to IT staff to CIO. I no longer get my hands dirty with the finer details of how an account gets created - I just tell someone to do it and it gets done. I miss it a bit, but then I come home and hack away on my home network and stay up to speed on what's going on out there.
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 untrusted IT Mgr. is worthless. 4. You and the admin should agree a timeline and certain milestones, upon which you relinquish certain responsibilities at that milestone. Unless the admin proves subpar, at which point you start looking for a new admin. For instance, at 30 days in, you step back and turn all acct mgt. over to the new admin, totally. I suggest the whole timeline take no more than 6 months, and if you can develop a quicker one, the better. 5. Develop a root password mgt. system. Every time the root password is changed, it is locked in a restricted access safe. And, SUDO is always used.
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 essentially made it so that he controlled everything. They key here is not to stand over the new guy, but to make sure there is always a way to take back access should you need to. I'm desperately working to document a set of systems I inherited because I realized the other day that the operations groups who were supposed to know everything about running them didn't. And since I'm in the engineering side of our highly segmented IT organization, my primary focus shouldn't be day to day admin work.
I'd like to think the days of cowboy IT admins are coming to an end, but I'm not so sure. In fact, with everything moving to the cloud, the guys who control the cloud vendor account have tons more power. I'm sure people here could tell plenty of stories of people getting fired, then VPNing in through their "doomsday" back door account and wiping out servers and backups. Just keep the keys and make sure you take them all away when someone leaves. Another story from my previous experience -- no company names because it would scare people to know this happened. But, basically, the "network guy" of a startup that grew super huge in the space of 5 years disagreed with the new CIO and started getting pissy about various things. So much so that the CIO brought in network contractors to start trying to rein the guy in. When the guy refused to work with them, he was fired. Only after that was it discovered that there was absolutely zero written documentation. It took months of very careful probing and the cooperation of the guy's underlings to get the network equipment manageable again.
If you're truly leaving IT behind for pure management, good luck. I just inherited a sorta-lead role in addition to all the other work I need to do, and it really is a different skill set. Humans are way less predictable than computers.
Also, for the sanity of those below you, please do not implement ITIL as a top-down mandate. ITIL is so horribly complex system that vendors like Remedy, CA, BMC, etc. will try to sell you as a prepackaged solution to all your IT problems. The reality is, unless you start cutting out parts of the processes you don't need, IT will become a nightmare world of useless busywork. We're at the point where we have to think about changes in terms of "how much work will this take to get pushed through?" rather than whether it's a good idea.
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 for their abilities and work ethic, but be upfront with them about this. If they cannot handle a little micromanagement or are unable to explain why their purposed change is better when they identify something you did wrong, you do not want them as an employee. Other common sense measures include; Do not ever let your sysadmin lock you out of a system, Setup regular supervision(do not rely on informal meetings or drop in sessions), Don't worry about certifications or unnecessary documentation, Pay attention to what matters(actual system performance and DR planning).
"I myself am made entirely of flaws, stitched together with good intentions."
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.
Oh, I'm sorry sir, I thought you were referring to me, Mr. Wensleydale.
I was was just in the position of being hired on as the new Administrator at my job a little over a year now.
I was given easy assignments at first with low privileged to more difficult and Domain Admin privileged based as time went on. I Think that it worked out well it built up that trust and when i needed access to curtain things i would need to ask to have my Boss login for me as Domain Admin. This forced me to think about what i was doing and making sure i was going about it the correct way and that is was necessary to get the Admin rights to do the job.
I would suggest that you create a domain admin not with his name but either a title or a nickname, then you can disable or enable that user for when he or she needs access, I would also turn on Auditing for logging on and off with that Account so you can track what that persons activity is. This way it will re assure you, that person is doing their job or if you have to fire that person the account isn't necessarily tied to that one individual.
Also meet with them regularly talk about the projects and how they will handle it. This way you both know about each others skills and way of doing things to make sure you are running efficiently.
Seriously, the number of small to medium shops that decide to move their capable, seasoned network admin into management and then hire some callow youth at the same pay they hired the current admin at 10 years ago is just stupid. Hire someone around the same career experience and equal or superior skills to the current admin at similar current compensation.
Disclosure: I currently support an organization (as a contractor) which did exactly what I advise against above. Even worse yet, their previous network admin wasn't qualified for his position and was in charge of hiring an entry level version of himself.
Learn to use them. You out them where there should be a comma.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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 stabby. Don't micromanage. Do set expectations - realistic ones, and do hold them to it. But don't do the job they were hired to do. Show them the ropes and turn them loose. As for the passwords etc., as someone else noted, if you're the only one who knows those, you need to work on your disaster plan, because that should never happen. You could blow a blood vessel in your brain reading these comments and then who is going to manage the servers?
The fact is that management isn't IT, and IT isn't management. You're changing jobs, and you need to let the old one go.
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.
Hardest lesson I learned in moving from being a developer/sysadmin (kernel-mode) was to let it go. How I went about my tasks was no longer important. I wasn't doing it. But what was important were the goals, objectives and measurements. I could certainly provide direction and advice as to how one might approach things -- but the day to day (minute by minute) issues were someone else's problem. No longer my personal problem. Not easy to let go, not easy at all...
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.
Sounds like you may be regretting the decision to move to the boardroom? Anyhow, good luck with it...
"The greatest lesson in life is to know that even fools are right sometimes" - Winston Churchill
stick a screwdriver up your nose and swirl it around for five minutes, then you'll be a manager
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
You know in large corps they have audit policies so that in an event someone goes full retard, you can trace it. The policies typically requires that it cannot be circumvented even by people with administrator access. Put one in place. You are in the position for that as an MD. Then hire so the guy/gal comes in the door with a policy and implementation in place (implementation can just be a paperwork process if you're not willing to invest in systems)
You can use that audit trail to gain comfort without looking like you don't trust the person. Audit trails of course provide much more other benefits as well.
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, even if I KNOW I could do it 5 times faster. I learned that it's less about getting today's programming done quickly, as it is about mentoring others to be able to do it for themselves.
I think the same principles apply to IT, or just about any other profession.
Stop asking stupid shit, you fucking moron
"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 organisation that you work for. And yes, I was a high end technical guy. I still have a lot of tech at home, and play there. And keep the technical staff I work with honest, but I trust them to do their jobs.
Oh no you don't! Don't send those fuckups over here to development either.
One of the things I have learnt is that for a minimum of the first 6 months you need a regular weekly hour-long meeting scheduled with them. That is dedicated to them so that they can pick your brains, bounce ideas off you, and you can also share experience and provide encouragement (along with monitoring how they are progressing).
Technical is easy as it's a skill that will transfer between jobs and roles, but the people and politics side can be a real minefield. Being available to coach them and steer them in the right direction will be of major benefit. Also remember that coaching is not about providing the answer, it's about helping that person realise the answer and how it fits in with everything else they know.
Good luck, it's real hard to step back, it took 5 heart-attacks for me to realise I needed to hand my stuff over.
https://en.m.wikipedia.org/wik...
Casteism
You have to learn to let go, there will be a window of overlap which will mean you'll both being doing the duties of Sysadmin but eventually you need to wean yourself off the job. It's your employees responsibility, and you're there to head off the big problems that will prevent them from doing their job. Your Yoda now, you don't go into battle with a light-saber unless there is no other choice. Keep the Senate off your new Obiawan's back long enough to fight the Sith and all will be right with the force.