So you didn’t take my advice (part 1). You went ahead and fired the guy anyway, didn’t you?
Now you’ve done it. This is terrible. Your IT department is going to disintegrate and your company will go the way of BetaMax, 5″ floppies, CRT monitors, and the buttermilk pancake helmet (delicious but ineffective, as any historian familiar with medieval times will attest)! Run for your lives!!
Ok, ok. It isn’t that bad. BUT here are some things you might’ve done when you fired that dude.
- You’ve created a slippery slope – Once you let someone go because they required a tad too much effort and supervision, it becomes a little easier to let the next person go, and next thing you know, you’ve not only fallen down the slope, you’ve landed on your groin and lost a shoe on the way. You may start to see patterns in another developer that remind you of the bad developer you fired.
Don’t misunderstand: people absolutely do behave in patterns, BUT the evaluation of those patterns should be confined to each person; they’re not necessarily transferable from one individual to another. So, for example, if you notice that Bill has difficulty understanding your shopping cart module just like that guy you fired, don’t assume that there will be other similarities. Maybe that particular module is just tough, but Bill will do a killer job once he gets the hang of it.
- You’ve created an atmosphere that doesn’t allow failure – Without meaning to, you made a martyr of that guy you fired. He’s now the example your team will relate to when they’re feeling overwhelmed or confused. Even the developers that agreed with the decision at the time will come to resent it to some degree and wonder if it might’ve been possible to give the guy just a little longer.
If you want to see developers that are paralyzed to do any real risky work , start firing their co-workers for not “getting it” or for making mistakes on a project. And by “risky work”, I mean working on any system that is truly key to your business – think order taking or shipping, for example. It’s risky because it’s the type of system that has to work. You may know these systems as “the ones that actually make us money“. These types of projects are already stressful enough without your developers thinking that they could be canned if they make a slip.
- You’ve created a hole in your consistency bubble – Cycling quickly through developers (remember: our hypothetical programmer has only been working at your company for 1 or 2 months), causes a high level of uncertainty for the rest of your team, and it’s only worse if they actually like the guy you fired. Serious personality types won’t like him on principle because he’s a weight to the rest of the team; carefree types won’t mind so much. Regardless, though, everyone needs time to adjust to team dynamics. Change them too often and you’ll sacrifice more than just productivity and deadlines.
Your mileage will vary, but you should certainly examine your situation to ensure that any of the above issues are identified and dealt with to the best of your ability. Unless you don’t care, that is.
In that case, fire away!
(the) Mark Savage vs Tech 
September 12, 2007 at 6:27 pm
Your point #2 is typical of what I call “The Cursed Project” or “Cursed Sponsor”. Everyone who works on or leads that particular project or sponsoring department gets canned. Most often it’s either something dealing directly with money making operations or sales.
I got this kind of assignment once. The last 3 programmers who had worked with that particular department had gotten fired because they “couldn’t produce” although they had produced fine on other projects. Guess what, I got canned too. Nobody could produce for those people but they certainly had upper management’s ear.
September 12, 2007 at 7:03 pm
Frank,
Good stuff.
Regarding your scenario about the last 3 programmers producing fine, but getting fired for not producing for that specific department: I am familiar with environments in which you’re only as good as your last project. It seems that sometimes the slate is wiped clean on certain projects and past successes count for little.
Unfortunate, but true.
Thanks for reading,
mark
September 13, 2007 at 4:27 am
Why allow yourself to get fired by a bunch of morons that don’t appreciate your technical skills anyway? Just quit and go get a better job! Don’t be a victim, take charge of your technical career, take some risks, never stop interviewing. The grass really is greener across the street and it’s the best way to keep your salary moving up. Stick it to the man!
September 13, 2007 at 3:15 pm
I was a witness of a similar situation where i have worked for. One of the inviduals of the team got fired, this led to bad calls of judgement from management on other issues, this forced one of the “good” developers to quit and after that it was a domino effect, everyone in the company left… resulting the company to be in limbo for a while until new developers came in..
Sometime’s that’s a good thing soemtime’s is a bad thing..
September 13, 2007 at 5:39 pm
Andreas,
I think most people would be surprised to learn how few people it takes to create a foundation in a group and how quickly that foundation can be dissolved. In some cases, the foundation is only one person!
It’s true that a chain is only as strong as its weakest link. However, it’s also true that when the strongest link is removed, the entire chain is weakened.
Thanks for reading,
mark
September 13, 2007 at 7:16 pm
Mark,
In your opinion, how long should “that guy” be given to prove his worth? At some point “that guy” will become an anchor on the entire team.
I would think that when the team leaders threaten to walk off if “that guy” isn’t dismissed so someone competent can join the team.
Rob
September 13, 2007 at 10:44 pm
I’m seeing this at my work right now. This new guy spent a year in iraq as a reservist and was hired in directly off the plane. He was getting a divorce from his wife two months later and his mother had cancer until she passed away recently. On top of that in our area new people get little training, zero mentoring and zero coaching. It’s disgusting. I’m looking for another job right now, and this guy hasn’t even been fired… yet.
September 13, 2007 at 11:21 pm
I don’t mean to sound rude, but this is total crap (imho). Crap developers have long-term negative effects on the company. These effects are WORSE than keeping them in the company and trying to help them (this has been the case in my experience at least 95% of the time). Most of the time, crap devs have a crap attitude, and that attitude doesn’t change.
Getting rid of them as soon as possible is the best thing to do.
Just my $0.02 🙂 Cheers!
September 14, 2007 at 12:15 am
Rob,
As much as I’d like to say there is, I don’t think there’s a one-size-fits-all type of answer on this one.
How long you keep a developer that isn’t pulling his weight depends on many factors. Among them: team dynamics, project load, and rate of improvement.
Mostly, though, I think there’s an approximately correct threshold of training, feedback, and time after which the only right thing to do is let the developer go. My goal was to provide some guidelines for this threshold (part 1) and offer some warnings if you have fired someone without meeting the threshold (part 2).
Thanks for reading,
mark
September 14, 2007 at 12:27 am
OJ,
I don’t think you sound rude at all. Candor = efficiency in most situations, yeah?
I have absolutely experienced what you’re talking about, i.e. having a team dragged down by a “crap developer”. There’s a very real cost to it and if the person does indeed have a poor attitude, it can infect the rest of the team.
I’ve worked with developers who flipped off the manager to his face (sure, we’ve dreamed it, but this guy actually did it). I’ve worked with developers who walked around the office barefoot and farted loudly in their cubicles. And I’ve worked with developers who just didn’t care.
That said, I’ve also seen the opposite case. I have been witness to developers that were very nearly fired for performance reasons who later turned out to be pivotal members of our team. We would have made a grievous mistake if we had fired them too quickly.
I’m not saying keep bad developers at all costs. I’m only saying that there’s a fair chance to be given. Sometimes we fall short and that is regrettable. But we can do better.
People do change. It’s the exception, I admit. But it DOES happen.
Thanks for reading and thanks for calling it like you see it,
mark
September 14, 2007 at 5:02 am
You have to seperate strange behaviour from the quality of the work. A barefoot developer maybe the best developer you have, and if he is not client facing who cares? And telling your manager exactly what you think is sometimes essential. I told one boss that has was a ****ing idiot. It took that strength of response to get him to see that he was in fact being an idiot.
For me poor attitude or poor developers are not characterised by eccentric personal habits. Its back to the basics: their ability to take a problem; solve a problem. An example: I recently asked a guy to work on an issue. It was a tricky one but he was a senior guy and so I left him to it … nothing. He was too senior to accept he didn’t understand and too proud to ask for help thus he defended a “lets do nothing” approach as if this was the only solution.
As for firing pivitol guys … yup seen that. I think the problems are related. In my experience you have an old senior guy who is respected and a young junior fresh dev comes in and says “hey this is all wrong”. So you have a conflict and often the organisation goes with the known guy and thus fires the bright young thing. When they take a risk it turns out he was right and becomes pivitol.
cheers.
September 14, 2007 at 12:52 pm
Firing somebody in Europe is very difficult. You have to prove that the worker is not performing as expected. And that’s really hard.
Firing a developer is the very last resort, http://www.diegoparrilla.com/2007/02/how-to-deal-with-toxic-engineer.html
September 14, 2007 at 1:35 pm
pedro,
In my particular examples, those developers also had very poor quality of work and were just generally miserable to be around, IMO.
I agree with you – eccentricities alone do not indicate a developer’s value. It’s a package deal, but the amount and quality of work being done far outweigh behavioral issues. I should have mentioned that.
If the person wants lay on their desk and type with their feet, that’s cool with me. But they better do above average work, because like it or not, they’ll be scrutinized more than someone who types with their hands.
Thanks!
mark
September 15, 2007 at 6:47 am
I totaly agree … eccentricity is acceptable if it goes with good work.
But I’d like to agree with Diego, I work in France currently and I have to say that it is very difficult. To fire someone … lol; to even threaten someone is close to impossible. Hiring people is equally hard. Thus, as there is very little turn over, you tend to see an aging developer population as the good ones are either promoted, change job or leave. And so you are left with arrogant, comfortable ‘senior’ developers who are in fact 10 years out of date.
Perhaps this isn’t the forum but its a real problem.
cheers,
peter (real name)
September 19, 2007 at 11:10 pm
I like the “steer their career elsewhere” idea. If someone isn’t a productive member of your team, you can’t keep them around indefinitely, as they’re a drag. On the other hand, cutting off your team members just because they don’t work well on your team isn’t the best course either. First, you may never know when they actually *do* know something that nobody else knows (and they take that institutional knowledge out the door). Second, every person is a resource, and while they may not work on your team, they might work out well on somebody else’s team. Third, if you up-front tell someone, “Look, I’ll be honest with you, I have a certain process for dealing with this group and I don’t think you’re fitting in. Here’s why…[edit]… so the question is, do you actually *want* to change to fit this team, or not? If you do, then great, let’s give it a shot. If you don’t, I don’t blame you, not everybody is going to be comfortable working under my style just like I wouldn’t be comfortable working under just anybody else’s style either. I don’t want to cut you off at the quick, because that’s bad for you, and it’s bad for me. Let’s work at finding you someplace you’ll be more comfortable, while finding me someone who is more suited for your job.” Then, *help* the guy find a new job.
This has a number of advantages. He won’t leave your org pissed at you and the world. If you need to touch base with him later to learn something only he knew, he is likely to be receptive. He has time to transition from one job to another, so you’re not just firing someone and knowing that he’s got to go on the dole while he tries to find another job. You maintain a relationship, so if he finds someone at his new job that might fit better on your team, you may get a pingback.