Archive for the 'Uncategorized' Category

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

September 6, 2007

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.

  1. 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.

  2. 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.

  3. 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!

Advertisements