Slashdot Mirror
What To Do After You Fire a Bad Sysadmin Or Developer
Esther Schindler writes "The job of dealing with an under-performing employee doesn't end when the culprit is shown the door. Everyone focuses on security tasks, after you fire the idiot, such as changing passwords, but that's just one part of the To Do list. More important, in the long run, is the cleanup job that needs to be done after you fire the turkey, looking for the hidden messes and security flaws the ex-employee may have left behind. Otherwise, you'll still be cleaning up the problems six months later."
The answer has been widely discussed here: http://serverfault.com/questions/171893/how-do-you-search-for-backdoors-from-the-previous-it-person
After all, everything wrong with the place is the fault of the last person to leave!
... wait, what?
Real mature there guy... With an attitude like that. You'd better have alot of backup plans in place. It sounds like you are a shit place to work for.
Do us ALL a favor. Name your company. So we can avoid it.
In fact, your entire corporate structure is at risk. How do you know he didn't engineer a brain virus that allows him to use the company's board members as flesh puppets?
He might have even used telepathy to cause major investment banks to sell him all of their shares of the company for pennies on the dollar. He might already own the company. It's best to double check.
In fact, he might be standing behind you right now, brainwashing you with lasers.
There's no -1 for "I don't get it."
Quickly leave the island before the dinosaurs escape.
...it's hard to imagine the relationship went sour,
"...after you fire the idiot, such as changing passwords, but that's just one part of the To Do list. More important, in the long run, is the cleanup job that needs to be done after you fire the turkey,.. "
You hired this employee. Chances are you started off with a relationship of mis-trust: .. And you still were too stupid to figure out whether or not you had someone who could do the job right.
- You did a criminal check on the hire
- You did a drug check.
- You did a credit check.
- You did personality test.
- You used Shockley style brain-teasers to see if they could do things other than what their jobs entail because you don't know how to measure skill, intelligence, or talent.
- You interviewed in a style of hazing akin to a gang-bang.
Sorry, but the tone of the summary makes you look like an asshole, and you deserve whatever you get. This is your wake-up call.
The article points out many obvious pitfalls on letting an underperforming employee go, but very few of these problems are unique to the particular situation of letting an obviously underperforming employee go. Most IT departments are pummeled to death with impossible deadlines and demands and management thinks that the complaints and warnings are just "the way it is with those lazy bastards". Truth is, anyone who's worked with IT knows that you have to test your backups and failover procedures, do security audits, tear down setups that are no longer used and keep documentation and automation up to date. BUT first we have to finish this project that was dreamed up by the top level management with absolutely no understanding of the technical hurdles involved. And it needs to be finished yesterday. If you want things to be neat and tidy, you're pretty much expected to take care of it on your own time.
Time flies when you don't know what you're doing
...you wouldn't be asking this question.
under-performing or metrics may them seem to be under-performing??
Made to do the work of 2-3 people??
Pulling 80 hour weeks that lead to errors and under-performing over time.
My first reaction (before RTFA) was that the problem might not have been the employee, but the person doing the name calling. However, the link is to a blog that lists a generic list of precautions to take. Whoever wrote that blog still has some growing up to do, but I'll give him/her the benefit of doubt and assume they were going for humor.
In any case, I notice that HP paid for the content. Now we know why they are in such trouble.
Companies are large organizations. Each person in the organizaton may concienciously do their job with good intent but without seeing the bigger picture (not their job) and therefore without knowing the consequences of their actions. The people at the top who, in principle, see the bigger picture, are often so far removed from the details of what is happening that they too do not know what the company is doing, except in respect of the shareholders and overall finanical performance. So, the company runs on policy and no one knows what it is doing. The company can be uber-evil when everyone in it is as nice as can be.
The company is more/other than the sum of its parts.
The real dangers are often not the fired employee themselves(if you aren't stupid about it) but the employees that remain. Most people will not install any insidious backdoors just on their own initiative, but if you fire someone in a way that upsets the remaining employees, i.e. publicly embarass them, screw them out of money they earned etc., then odds are someone else IS going to try to install something to make sure that they don't befall a similar fate.
I hope he reads this. After a bunch of expensive equipment disappeared under his watch we fired him. The day after, standing around the coffee room I mentioned. "Too bad they fired him, he owed me 50". Three other people suddenly said, "He owed us 50 also." It turned out the same story for everyone. He borrowed 100 and returned 50. (note: some of my best friends are sysadmins so don't get me wrong)
The submitter comes off as an angry, abusive tool. Maybe he should fire himself for having a hand in hiring an "idiotic turkey" to begin with.
It's likely that the developer wasn't all that bad, but stopped giving a shit after being berated by an abusive asshole for umpteenth time.
I tend to side with the critics here, asking if maybe management (including possibly the person posting the original question) are really the ones to blame?
I've worked in I.T. for something like 25 years now, for companies big and small, though the only times I've held a title of "manager", I was really only tasked with managing outside consultants or developers. I've always preferred being relatively "hands on" with the problem solving and system/network administration tasks at-hand, vs. spending my day in meetings and typing up Excel spreadsheets trying to explain what the "team" was doing.
Bottom line? Sure, there are a LOT of people out there trying to get hired in I.T. as support people or sysadmins who REALLY don't know what they're doing. If more companies would let the people actually DOING those jobs interview these people, they'd be able to weed out far more of the bad seeds before they even started. What I see, time and time again, is some I.T. manager who thinks he's simply "too busy" to interview some potentially really good people who apply for positions, and then he gets in a panic when it comes down the wire and he absolutely can't go without employing another person any longer. He winds up asking H.R. to find him someone good, and of course they don't know squat about I.T. so they pick through the resume submissions based on "standard issue" criteria like the college degree they claim to have, or the number of certifications they list. If he does "second interviews" with these pre-selected people, he may just be trying to pick the best of a bad bunch at that point.
But another problem is with how the I.T. workers are managed. You can have some really top-notch people working for you, yet they're made out to be clueless, inefficient screw-ups because they're actually trying to use their brains to decide which tasks on their plates are REALLY most important to the company. Meanwhile, some upper management character is throwing fits about relatively inconsequential items his ego demands be put "front and center". If you're busy working a difficult problem affecting a whole division of the company and by doing so, you didn't get some new computer issued to somebody first thing in the morning ... guess what usually happens? It's that idiot in I.T. who caused the employee not to have that shiny new PC on their desk on time. Nobody's even aware of the work the I.T. guy was actually in the middle of doing.
And here's the kicker.... You can say all you like about this simply being a "lack of communications" issue. "If management was simply kept informed about what I.T. was doing, everyone would be better off." But so many computer problems are of a "need to fix this yesterday!" level of importance, your good I.T. rank and file employees are going to concentrate on getting that done -- not on getting sidetracked with emailing status updates to key people. Management needs to realize that a certain level of TRUST is required here. You have to say, "I don't really know what Joe Q. has been doing the last few days, but that's ok. I trust Joe Q. because when I make an effort to find out if anyone feels Joe helped them with their issues, I get loads of positive feedback that he did." Micro-managing I.T. is almost never wise....
By using terms such as "culprit", "idiot", and "turkey" you indicate that you are a big part of the problem.
Only gross mismanagement would let you get into such a mess in the first place.
It sounds like he is well rid of you.
There isn't really any practical way to be completely sure, but one thing that can help is to not give him reason to want to attack the company.
Lay him off and pay him out a good severance pay and he is much less likely to leave disgruntled. There may also be other parting perks besides pay that can generate good will depending on the person.
This also give the added benefit of when something breaks in the old obscure undocumented part of the system only one person knows, that one person may be more willing to help. Tho how beneficial this is depends on how useless he is.
As for the technical stuff, only way to be sure with sysadmin is rebuild all the servers from scratch (an extremely time consuming task of course).
For programmer, the whole team should be doing regular code reviews anyway looking for any security bugs. Maybe an extra code audit would be a good idea.
1984 was not supposed to be an instruction manual.
Nope. When the bad guys have got root on your PC the only way to restore confidence in it is to rebuild it from a trusted image. Likewise if your network admin has gone untrusted on your infrastructure you burn it down and build it new again. Nuke it from orbit. It's the only way to be sure.
Frankly that's not near enough to stop a real determined jerk with skills, but thankfully we are rare. Don't hire us in the first place if you can avoid it.
Help stamp out iliturcy.
I have been in IT for nearly 25 years now and have learned a few things along the way. The first rule is that most employees referring to others as idiots, turkeys, incompetent etc need to look first in their own seat.
It is generally a reaction I expect from a dev or sysadmin covering his own faults by passing blame to others. I find most people just want to do what they where hired to do and do it well and given the proper chance and assistance will do just that.
In the last 5 - 10 years though it is generally a result of understaffing and insane deadlines causing less than desired results.
Got Code?
when the culprit is shown the door.
But the person who hired him still works at the firm... that's the real "culprit".
Seven puppies were harmed during the making of this post.
That's when things got interesting.
My manager and I started the process of handing over all my projects -- most to the rest of my team, but a few went to the OFFH. It didn't take long for the OFFH to piss off one of my soon to be ex-clients to the extent where top level management got involved, the OFFH was finally pulled into a disciplinary hearing (wasn't fired, but received a final written warning), and I had to step back in and clean out the mess. The next day, the OFFH put in for leave on the Friday coming up, went away... and never came back. It was formally dismissed for absconding shortly afterwards.
That's when we found what was really going on. To summarise:
So, while we thought we were dealing with mere incompetence, in truth, the OFFH was a malevolent fucktard.
All of us involved has learned our lessons -- personally, I'm far more security conscious, and the folks I worked with are far stricter regarding who they hire, development practices and policies, and that kind of thing. As for the OFFH, it seems to have vanished into thin air...
I hope you are joking. "Under-performing" doesn't mean "idiot" or "turkey" or imply incompetence or malfeasance as TFS would have us believe. To the contrary. someone capable of doing things requiring the type of audit you suggest would probably not be an under-performing employee.
It must have been something you assimilated. . . .
Backdoors from the current IT person aren't important?