Hello again, I'm continuing this series on training and teaching new developers. And this week going to talk about a topic no one enjoys. What to do with bad talent.
The title of his blog post is not an attempt for me to be funny (OK not totally). But part of the reason I wanted to write this is that I would hear a major misconception from students and other developers. And that misconception is that if a member of your team isn't pulling their weight you just fire them.
Honestly I don't know how this got started but its definitely not always the case. In fact in my experience having someone fired is never easy.
I used to give a group project when I was teaching (I know...I've heard it all about how everyone hates these). I gave this assignment because if you are working in this industry I can pretty guarantee you will be on a team. And your going to have to be able to work with people. And I would regularly have students tell me that they would just fire a group member that doesn't pull their own weight. And in y experience this is rarely easy to do, and usually requires a lot more work on your part.
But unfortunately it happens, people don't work out. It could be a case that they just aren't meshing well with the team, or their work is substandard. Or they just have a bad attitude. So what do you do in these situations.
First lets get one thing out of the way, your first instinct should never be termination. And I say this for several reasons. One if you play that card too much management will see you as the little boy/girl who cried wolf. So now when you really do need someone removed from your team, it comes across as you complaining. And it makes you look like some kind of task master who is never going to be happy. Secondly, there are more than a few business facts behind this statement. If you read any business journal they will tell you that turnover is extremely expensive. Cause you went through an entire on boarding process, just to fire them and repeat. Not to mention loss of productivity and all the headaches involved.
And additionally you need to regulate your own feelings. Most software developers take their projects very personally and can get very offended when bad work is turned in. They then treat this as an attack on their skills and can immediately go on the offensive.
I heard a great quote from Scott Hanselman, "Never attribute to malice, what can be attributed to incompetence.". Most people aren't organized or smart enough to be doing this with Evil intent. As hard as it is to believe they are not sitting awake at night thinking of ways to destroy your project. So check your emotions at the door.
So if we step back and assume incompetence then we should be looking at the possible reasons for this error. Now before I go further, its worth mentioning hat much like the ramp up I discussed in the last blog post, this is a sliding scale. And it works the same. There is nothing wrong with expecting more from more senior developers. And you should have more tolerance with more junior talent. And there is nothing wrong with having high expectations for a sub.
The first question here is to look at the type of issue you are having. I'm going to focus on the policy issues where they don't follow process and quality issues where they are turning in bad work. But the first step should always be to talk to the person involved. Take time to step aside and discuss the issue.
Take the time to point out what is going wrong and how it effects the team. These are appropriate questions as sometimes people are just unaware that their actions have an effect on others. But it is important to have this conversation but also important to quantify outcomes.
Because honestly, think of it this way. If someone came and told you, you messed up, it did this and then said...Don't do it again! How much do you have to operate on? What can you say or do to prevent that situation from happening again?
The better option is to give a quantifiable result. To say for example, You aren't completing enough work, and we'd like to you to deliver more, or better quality. Then say I've assigned additional work to you and given a due date, it must be completed by that date, and the day after we're going to do a debrief.
This gives the employee the chance to turn things around and impress you. They can take a bad situation and salvage it. They can change situation and come back from this in a positive way.
The other thing is that starting now, everything needs to be heavily documented because if things do fall apart, this documentation is what will help to deal with any requirements from managers or Human Resources.
Now that being said, it doesn't always work, and in those cases you can't save every dog in the pound. Sometimes things don't work out and in those situations, make sure you start early with developing a plan to shift that persons work. Because even after they've been moved off of your team, you will still need to accomplish the work and need an approach to carry that load.