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.
So ambiguous, you could be talking about anyone!
One thing (in smaller shops, that is) that I don’t think some managers take importantly enough is the "team fit" aspect. I had a boss (for about 6 months, before he was…umm…"let go"), who – instead of trying to get the team to work together, would instead make all decisions such that the weakest team members would be comfortable. His reasoning was the stronger developers could cope with it. He’d make important decisions based on this – such as forcing the entire team to now write in VB because 1 developer claimed that switching between VB and C# "fucks shit up" (best actual example they could get), and that the context switch was also distracting.
But, for the team fit aspect, he’d go with this as well – so that the stronger developers, who often times come with being vocal with their opinions, and preferring to discuss things in the open, he would effectively consider those opinions 100% invalid. And if those types had issues with how other team members did things, that we should just shut up. He felt that the team getting along together did not matter at all. We’re here to work, after all! The team’s happiness and comfortableness with on another has no effect on the project! At all!