Comments on: Trust me: don’t fire that bad developer just yet (part 2)

By: padraic2112

padraic2112 — Wed, 19 Sep 2007 23:10:00 +0000

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.

By: pedro

pedro — Sat, 15 Sep 2007 06:47:35 +0000

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)

By: themarksavage

themarksavage — Fri, 14 Sep 2007 13:35:47 +0000

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

By: Diego Parrilla

Diego Parrilla — Fri, 14 Sep 2007 12:52:40 +0000

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

By: pedro

pedro — Fri, 14 Sep 2007 05:02:32 +0000

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.

By: themarksavage

themarksavage — Fri, 14 Sep 2007 00:27:21 +0000

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

By: themarksavage

themarksavage — Fri, 14 Sep 2007 00:15:10 +0000

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

By: OJ

OJ — Thu, 13 Sep 2007 23:21:59 +0000

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!

By: toomanymarks

toomanymarks — Thu, 13 Sep 2007 22:44:01 +0000

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.

By: Rob

Rob — Thu, 13 Sep 2007 19:16:03 +0000

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