How to help a teammate up

Software is a crazy industry. Requirements are changing quickly. Technologies are changing even faster. Customers generally cannot specify what they want. No wonder some of us fail to do their job well.

Salaries are high, professionals are valued high, which attracts people with various personality disorders. Programming is some sort of trance, which attracts people with other kind of problems. No wonder we usually cannot help the ones who are left behind.

The Team Geek book suggests that we should help the teammate up or out. Note, that it isn’t the same as the idiotic up our out policy. Anyway, they argue that people who cannot perform well in one environment, they can become successful in another. They also suggest that you need to help them out most of the time.

But helping up is not that hard. Actually, HR should be able to deal with this kind of situation. But in lots of software companies there’s no HR at all. So programmers will try to help each other. This post is about how I would do that.

1. Give feedback

Really, give feedback. Make sure that this feedback is gentle and accurate.

Being gentle is important. When you deliver bad news, then people tend to be defensive. The more arrogantly to tell them to change, the more defensive they will be. I know, you can fire them, but being fires is not that bad. A developer can find a new job in no time. So be nice, and they will cooperate with you. Well, the narcissists will only pretend, but that’s another story.

Being accurate is also important. Saying things like “You need to work faster” or “You need to make less mistakes” doesn’t really mean anything. Statements like these are very vague. It’s unclear how fast should he become. How much mistakes are tolerated? What’s the deadline for him to change his practices?

You need to find something more to-the-ground thing. For instance, this is a good starter: “You are making too many mistakes due to refactor. I’d like you to focus on how to improve that.”

Easy to say hard to do,  isn’t it? Maybe all you know is that a colleague is too slow, but you don’t know why. Well, you need to ask and listen.

2. Listen

Here is something that almost never happens. You should ask the colleague if you aren’t satisfied with his performance.

I know, private life shouldn’t affect work. But it does. If something is going on, like he takes care of a newborn kid, then you know that he’s going to be a little sloppy for some time. Now you can make an informed decision whether you can tolerate it or not.

Maybe something is bothering him about your management style? Maybe you can learn something from him? Can you help him with something? Maybe his attitude is a better fit for another role? You won’t know unless you ask and listen.

It’s a good idea to have someone to pair with the problematic programmer. I’m a big fan of pair-programming. Pair-programming is a great way to write quality code – and to learn. In a few weeks, both programmers will learn from each other. They will also know how the other one could improve.

We all have our blind spots. Pair programming can help you to give accurate feedback. E.g. he might work well but doesn’t ask for help. Or maybe he needs to learn how to write unit tests. It’s worthwhile to figure it out.

3. Goals

How will you know whether he has improved? You need to find something measurable – and measure it.

How will you know whether his improvement is enough? Well, you need to set goals. Everybody who is involved need to know in advance what that goal is. Otherwise you’re just bossing him around.

Bossing around makes people defensive. They won’t listen. They will rather look for another job.

It’s important to know that people change slowly. Chances are it’ll take a couple of months for someone to significantly improve one of his skills. If you really need quicker improvement, then you better recruit somebody else.

4. Focus

Maybe you have lots of problems with that developer. Still, he can change one more two things at a time. Figure out your priorities and focus on those issues. Set goals for the most important things. Give quick feedback, if needed.

Wrapping up

I was talking about HR and management practices. This is what I picked up during the first 10 years of my programming career. In one sentence: treat others with respect.

What else you could do to help at their job? What wouldn’t you do?


About tamasrev

A software developer, specialized in Java, addressing himself as generalist. A proud daddy.
This entry was posted in soft skills and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s