Aug 22 2008

How to run a software development company (INTO THE GROUND) - Part 3

Category: Best PracticesMatt @ 07:32

I am really, really glad it is Friday.  It's been one of those really, really (not) awesome weeks.  Anyway, here's how you, too, can successfully take your software development ship and crash it into an iceberg, killing everyone on board!  In a change of pace, I'm going to start putting a "why you shouldn't do this" section at the end that explains things with a bit less sarcasm.

Never. Fire. Anyone.

Firing.  Even the word sounds bad.  As you pilot your software development company to guaranteed fortunes the likes of which haven't been seen since the dotcom bubble burst, you may run into a situation where someone doesn't seem to be a good fit.  Maybe they just don't jive with the team.  Maybe they are clearly "incompetent".  Maybe they're sleeping at their desk for long stretches every single day.  Maybe it's someone that your developers warned you not to hire because they knew this person was toxic to a team, but in your brilliance, you hired them anyway because you saw right through that BS they were feeding you, and you knew that guy was gold.  Even after the guy talked smack about you behind your back to one of your friends less than 24 hours after you hired him, you still knew this person was going to help get you to the pot of gold at the end of the software development rainbow.

Anyway, so you have someone that is a problem, and they're apparently dragging the team down (or so everyone says).  Whatever you do, DO NOT LET THIS PERSON GO.  It isn't their fault that they can't stay awake in meetings, or that their code never compiles.  It's because the rest of the developers are not competent enough to keep up with this person.  You should promote this person instead!  That will show those pesky developers!

The morale of this story...

Not everyone is a good developer.  Not everyone is a good worker.  Hiring good developers is a very tricky process.  I've seen good developers interview terribly, and I've seen terrible developers that interviewed great.  That means that not everyone you hire is going to work out.  While it is important to give these people feedback and to try to help them adjust, there are going to be situations where the best thing for everyone (you, your team, and actually even the problematic individual) is to part ways.  You shouldn't be terrified of taking this step.  You shouldn't be terrified of confronting them and letting them know that what they're doing that isn't up to par.  If you don't, they can't improve, and the environment suffers, and that makes things hard for everyone.

Tags:

blog comments powered by Disqus