Ask Slashdot: Intelligently Moving From IT Into Management? 125
MightyMartian (840721) writes "I've been working for an organization now for over seven years, my best run yet. A couple of years ago, the company went through some major changes and I bought in as an owner and as a managing director; my responsibilities encompassing administration, finance and IT. It's a small (20 employee or so, plus nearly that many with subcontracting companies) organization so needless to say I retained my direct IT responsibilities.
My fellow board members have decided that I need to detach myself from the day to day IT operations and take over more management duties; in particular in the finance and budgeting end of things. Right now I'm in the process of interviewing a new IT system administrator who will, over time, take on most of my IT roles. However, since this has been a one-man shop for seven years; namely my shop, I confess some reservations about handing over the keys and moving permanently up to the top floor.
Does anybody have any suggestions on the level of permissions for servers, networks and infrastructure I should start with? Do I, for the moment, retain some of the critical functionality; like superuser passwords, and slowly move the new system administrator into his or her role, or do I move more quickly, give him the basics and then let him fly on his own?"
My fellow board members have decided that I need to detach myself from the day to day IT operations and take over more management duties; in particular in the finance and budgeting end of things. Right now I'm in the process of interviewing a new IT system administrator who will, over time, take on most of my IT roles. However, since this has been a one-man shop for seven years; namely my shop, I confess some reservations about handing over the keys and moving permanently up to the top floor.
Does anybody have any suggestions on the level of permissions for servers, networks and infrastructure I should start with? Do I, for the moment, retain some of the critical functionality; like superuser passwords, and slowly move the new system administrator into his or her role, or do I move more quickly, give him the basics and then let him fly on his own?"
Give up the keys (Score:5, Informative)
If you can't trust your sysadmin, you shouldn't have hired them in the first place. Anybody capable of doing the job, with a reasonable background, should be given the opportunity to show their mettle without being arbitrarily restrained.
Re:Give up the keys (Score:4, Insightful)
If you can't trust your sysadmin, you shouldn't have hired them in the first place. Anybody capable of doing the job, with a reasonable background, should be given the opportunity to show their mettle without being arbitrarily restrained.
Keep your own administrative access, but since you were barely qualified to be a sysadmin in the first place, just learn to let go. The organization will be better for it while you move back into finance where you belong.
Colonel Meyers: Are you new to the infantry, Major?
Maj. Malcolm A. Powers: Yes, sir. Just came over from supply.
Colonel Meyers: Were you good at that?
Maj. Malcolm A. Powers: Yes, sir!
Colonel Meyers: Well then, stick to it because you're a walking cluster fuck as an infantry officer. My men are hard chargers, Major! Leutenant Ring and Gunny Highway took a handfull of young fire pissers, exercised some personal initiative and kicked ass!
MANAGEMENT == PSYCHOLOGY (Score:3)
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.
Re: (Score:2)
+1 Amen
Re: (Score:3)
Perhaps you need to think like a psycopath? [wordpress.com]
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
Re: (Score:3)
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.
Re: (Score:1)
Because he'll NEVER figure out how to get root access with only full sudo!
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re:Give up the keys (Score:5, Insightful)
Trust is earned.
You've basically got three kinds of sysadmins, in my experience (though obviously there's a spectrum).
1) The jerkoffs who don't do their job and squander company time. They don't fix things, they don't improve things - insofar as it's not visible to management. These are the kinds who put in backdoors and may put in needless obfuscation to maintain their relevance.
2) The fuckups. These are the ones who needlessly make a mess of things by not following basic best practices. They're better suited for desktop support roles or development. They may be good, damn good, but they're not systematic enough to be good admins, and overlook crucial things (like, "oh, I'll just leave this point-to-point tunnel up without encryption and get back to it later").
3) Everyone else. Doesn't matter how good they are and how fast they are at doing it, but they follow a couple basic rules: be thorough, be diligent, and always try to improve.
You'd know pretty soon which kind of administrator you've got. Start with a short term contract. Give them a limited scope of responsibility - a zone, like a set of specific systems or a project, such as something like upgrades and/or documentation. Maybe give them a problem to solve. Give them something that's intentionally expansive but of limited impact for them to work on and see how well they do.
If they do well and don't surprise you with something atrocious (oh, I don't know: can't convert MB to GB would be a hard stop for me - I've seen it), let them stay on.
But they really do need to see how the shop runs and be your PFY for a bit, first. There are very few people who can jump into someone else's baby and drive it like a pro, it's going to take a long time for even good sysadmins to catch on (my replacement is still catching up after I left 3 years ago, and I was only there for a year, thrown into more or less the same environment he was: his approach has been to slash and burn whereas mine was more granular due to less levity in outages).
Nuh-uh! (Score:2)
Oh no you don't! Don't send those fuckups over here to development either.
Re: (Score: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"
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?
Re: (Score:1)
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.
Re: (Score:2)
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 -
Re: (Score:1)
Re: (Score:2)
^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.
Re: (Score:2)
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
Re: (Score:1)
Be there for him... (Score:5, Insightful)
Be there for him, but not looking over his shoulder. Also remember that he'll make mistakes, just like you have over the years. It's difficult but you'll find yourself more effective when you learn to delegate.
Re:Be there for him... (Score:5, Insightful)
So be there for the new SA, but make sure that after a certain point it all becomes his responsibility.
Something along the line of:
First month, training
Second month, I will help
Third month, I will answer questions. If I remember
Past third month, Moral support.
Re:Be there for him... (Score:5, Interesting)
Re:Be there for him... (Score:4, Insightful)
Re: (Score:3)
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...
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:1)
Re: (Score:1)
You sound like a real peach to work for/with. If technology wasn't 50% screwups and botched design, we wouldn't need sys admins.
Let it go (Score:1)
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.
Management 101 (Score:1)
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.
Re: (Score:2)
Re: (Score:2)
+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
You got it backward (Score:1)
Intelligently? No, first you need to get a lobotomy.
Re: (Score:2)
Oh come on, in context that's bad advice. He explained he was better suited to management in the first place.
Re: (Score:1)
It was intended as a joke. Flat?
Re: (Score:2)
Naaaaaah, I was just saying that it's he's already had the lobotomy.
Re: (Score:1)
Grow a pair (Score:3)
Re: (Score:2)
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
Re: (Score:2)
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
Lots of Factors (Score:1)
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
Change your mind set (Score:2)
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
incrementally hand it over (Score:1)
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
Teach him well, grasshopper (Score:2)
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)
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.
Problem (Score:4, Funny)
Intelligently Moving From IT Into Management?
Sentence does not parse.
Think about it this way... (Score:2)
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
Re: (Score:2)
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
Let it go (Score:1)
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
It depends. (Score:2)
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
Sounds like my bosses boss (Score:4, Insightful)
My bosses boss was the sys admin here. He's moved up over the years. He still keeps his hands in the sys admin stuff on occasion. You know what happens? He fucks things up in the process! Things have changed in the past 5 years that he isn't aware of and so shit breaks when he tries to help.
Do yourself a favor and do one job and do it well. Give up the keys and let someone else sink or swim. If you don't stand aside, you'll be a liability more than an asset.
Re: (Score:2)
Let it go (Score:1)
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)
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.
hrm... (Score:3)
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.
You're Asking the Wrong Question (Score:3)
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.
Re: (Score:2)
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.
Re: (Score:2)
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 .... (Score:1)
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 (Score:2)
This is assuming you run *nix based systems, you did not specify your infrastructure.
This may not end well ... (Score:3)
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.
Document Everything(tm) (Score:2)
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.
Been on both sides of this... (Score:2)
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,
Do a Proper Disaster Recovery Plan Together (Score:4, Informative)
OK, so if you're asking this, there's no way you've done a proper disaster recovery plan--folks that have done those have sufficient documentation in-hand that someone else should be able to pop in and do the job.
So this is a great opportunity to do that. Together. You gain confidence in your IT minion while s/he gains confidence that they're flying right. And any keys to the kingdom are nicely stored where they should be, so any authorized IT person can get at what they need.
The first step is to get the lay of the land and prioritize services. Gather the keys/passwords/whatever together (make sure your AAA story is good, etc). Come up with what your backup/restore stories are. What do you do if you need to restore one file (the "oopsie" moment)? What about a dead drive/server? What if a plane hits your data center? etc, etc.
Make no mistake--you're in the middle of a disaster RIGHT NOW. You're losing your lead IT staffer to promotion :-)
from IT grunt to Officer material :-) (Score:1)
Does it make sense? (Score:2)
Re: (Score:2)
Did the move a few years ago (Score:2)
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
Develop a hand-over plan (Score:1)
Always have a way to go back (Score:2)
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
Use common sense measures. (Score:2)
Been there, it can be hard. Short trial period. ?s (Score:4, Informative)
It can be very hard to let go, to trust the new person with your baby. I think it's generally true that "Whoever can be trusted with very little can also be trusted with much, and whoever is dishonest with very little will also be dishonest with much", so I didn't hand over everything on day one, but I tried not to delay unnecessarily once someone has proven themselves. Maybe give the new person full reign on a NEW project or system, something that won't wreck the company if it blows up. Similarly, maybe a just non-critical systems for a few weeks.
The other thing I tried to do that helped both the new person do the job and helped me feel better was to frequently communicate about how often the new person is asking questions. I try to guide them to ask questions when they need to (don't guess when you don't know), and also trust their knowledge when they do know. So I tell new people I plan to get questions from them. Even if they are an expert in their field, they aren't an expert on OUR systems. Also, experts talk to other experts. I'm part of several groups, standards bodies and FOSS development efforts, where highly competent people discuss ideas. So they should feel free to ask questions when needed - if they didn't any questions in their first week that would signify a problem. Conversely, I had one employee who would keep asking the same questions. She would check with me even when she knew what needed to be done. I had to encourage her to trust her own knowledge.
Knowing that my people ask intelligent questions about the areas they are responsible for, I know what I can trust them with. In those areas where they ask "dumb" questions and really don't know the answer, I know I shouldn't give them that specific responsibility outside of a learning projects.
First thing first (Score:2)
Semicolons (Score:2)
Learn to use them. You out them where there should be a comma.
delegation is never easy (Score:1)
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
What? Why? (Score:2)
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.
Follow William Pitt (The elder) (Score:2)
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.
S
episode 8 (Score:1)
Keep the keys (Score:2)
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
Delegate (Score:2)
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,
In the words of James T. Kirk (Score:1)
Treat management as you did your tech career (Score:1)
Re: (Score:2)
Sounds like (Score:1)
Re: (Score:2)
Re: (Score:2)
This is pretty good advice for an AC.