How to manage a developer with poor work ethics

Question

Background:

I am the PM / Scrum master in a development team, we follow a semi-agile framework for app development. The team (which is newly formed) consists of 3 developers. I am not the line manager of the developers but only the PM/Scrum master.

Problem:

There is a developer on the team (let's call him Tom) who is constantly missing out on his deliverables. Tom, for example, delivers only 70% of the story points that were estimated at Sprint planning. Those were the stories that he personally estimated and volunteered to take on during the sprint planning session.

Analysis:

My analysis is that he is capable of delivering 90-100% of the story points however he has not been engaged enough to work on this.

Evidence - I sit close to him and notice that he spend a large amount of his time doing 'lesiure stuff'. We are in the Tech department of a MNC, there are barely any overtime so the average productive hours is about 7 hours per day (9 hrs minus 2 hrs of breaks). The amount of leisure hours he spent is close to 3 hours per day.

For these 3 hours, he would walk around the office and discuss anime with the other colleagues, or watch downloaded movies, or do online shopping. It is only at the last few hours of the day then he would only sit down and rush to finish the work.

Question:

How do I manage such a person? The department itself has quite a relax working culture so I don't want to be the person who is creating conflicts unnecessarily. However, I am worried that he will spread his working attitude to the other team members who are so far still performing. Tom's coding skills is considering slightly above average and is more experienced than the rest of the team. He can rush his code pretty quickly (completing 70% of the deliverables despite working for only slightly above 50% of his time) so I also don't want to let him go.

Additional info: We are in the Tech department of an MNC so salary wise it is not as competitive as big Tech companies, but it is at least market median.

Answer 1

I can share a dialog schema that I use to solve issues such as the one that you have.

The schema consists of four essential parts.

1. Prepare your arguments well.
2. Agree on the problem definition.
3. Work on the solution.
4. Follow-up.

Let me go through these steps one-by-one.

First, your preparation. This is the most important step, so invest time and effort into making sure you are well prepared. A few principles first.

p1. Your conversation has to be done at the right time. You will want to do it when there are no urgent things to do in the next 60 minutes, when the person is not upset, and when the problem is still actual.

p2. Your conversation has to be fact-based. You have to tell exactly what the commitment of Tom was (and back it up with objective evidence), what was the result, evidence of procrastination and so on. Always rely on concrete facts only. DON'T: "You are always procrastinating". DO: "Yesterday I asked you to finish task N. I noticed that by the end of the day you could not finish your task, and I also saw two times that you could not focus on your work because you were browsing Internet".

p3. Focus on the problem, and never on the person. Your goal is to solve the problem, not to change Tom (which he can only do himself, and only if he wants to).

In preparation focus on the following:

1a. The problem definition. Work on the importance and urgency first. Importance = whether/how it influences the business. (if it does not, then it's not a problem, stop right here). Urgency = what will happen if the problem is not solved now. (if nothing happens, then you will want to use a different method than this one, stop right here and look for another solution).

1b. Empathy. Think of why this is a problem for you (and explain this later on the meeting), and why it is a problem for Tom (important! you will want to attach the problematic situation to Tom's personal goals - career, reputation, respect from team members etc.)

1c. What could be the point of view of Tom. Normally people do not do bad things intentionally. There is likely a good intention in everything. For example, Tom may give too optimistic commitments to make his manager happy?

Explore other options as well, definitely the following:

• Goal is not clear enough. Does Tom understand that the goal is to consistently deliver to the commitments? Why is it even a goal?
• No skill. Does Tom have skill / experience / training to give realistic estimations?
• No resources. Does Tom have everything he needs to provide the result?
• No will / motivation. Check this one only after you checked other possibilities?

1d. Think of when did it start. Imagine for example that Tom is going through difficult times in the family. Putting more pressure on him may not do any good. You may want to support him instead and agree on how you collaborate in the meantime.

----- START OF THE CONVERSATION -----

Second, agreeing on the problem definition.

Do not take 100% of time for your speech. Instead go for a dialogue. State the situation and a supporting fact, then make a pause, and let Tom respond. Do not go into argument (if you feel you need to, then you did not prepare well - wrap up the conversation and go back to step 1). The first goal of your conversation is to have a mutual agreement on the problem. If there's no agreement, do not go further.

Third, working on the solution.

Depending on the skill / will apply different tactics here (see Situational leadership). Try to have Tom develop and own the solution, help when needed. Make an agreement in the end on what the solution will be.

Fourth, the follow-up.

Provide feedback - both positive (managers often overlook this!) and negative. Example of positive = "Thank you, I see that you've been working on this!". If something is not going right, you should appeal to the agreement that you've made before. "We had an agreement, is there anything that's not working?"

Good luck, hope you are able to solve your issue!

Answer 2

Step 1: put him on notice of an expected performance increase on a timeline. If he makes it, march on. If not, see Step 2.

Step 2: replace. You should always strive not to have a single point of failure on an individual performer, no matter how great. If you have a single point of failure on a marginal performer, then you have another issue to solve. Allowing marginal performance is a cancer on a team and will metastasize.

Answer 3

First questions to ask yourself are:

• can I afford to lose this developer?
• will I have a hard time finding a replacement if you lose him?
• what impact will his behavior have on the other team members/project if this is allowed to continue?

Regarding the third question, from experience I can tell you that his behavior will get worse and that inevitably some of the other team members will start behaving in a similar way. Think about it. Tom is slacking off and he is not confronted about it. This creates an indirect incentive for him to slack off even more just because he can. At some point, others will figure out that Tom is slacking off and nothing happens to him, so they figure out that they could step down a gear also and work less hard.

So you have to do something about it. And here, the first two questions above become important.

You need to tell Tom what you noticed. Tell him you know he can do better and you would appreciate if he does. From personal experience with things like this, I can tell you Tom will not all of a sudden say "Oh gosh... I wasn't aware of me doing this. Thank you for bringing it into my attention. I will immediately start behaving differently". Won't happen.

What's likely to happen are things like the following:

• Tom will start working more, but he might also start looking for a job somewhere else and leave. His behavior most likely isn't developed in your team, he possibly picked it up somewhere else where he was doing the same and got away with it. So he can find another company where he can do the same;
• Tom will get defensive. You are exaggerating. You are seeing things. Imagining things. He might unwind here and there when he loses productivity but he gets back to the task. He recoups his work. He delivers 70% but maybe that's because he's a bad estimator, not a lazy worker. He will probably overestimate things from now on, or take less work next sprints.
• Tom will behave in the same way but now he will be more careful not to show it. He will be at his computer, his IDE will be opened, but he will stare into space. Or he might be typing code but for a personal app of his. You don't know what he's doing there. People who want to slack off will find ways to do so no matter what you do to monitor or prevent it.
• he will start talking behind your back to the other developers. Telling them you have some issue with him. That you are a control freak that insists people are productive 100% of the time. That you can't even look out the window without you pointing out that one should be looking at his monitor instead.
• etc.

There might be some resentment, conflict or undesired consequences if you approach Tom about this subject. If you figured out this can't absolutely be allowed to continue, then that's life. Tom is an employee. He gets employee treatment: bad performance reviews, official notices, less salary increases, whatever the company's policy for under-performing staff is, which includes being fired.

You say you are not his line manager. Who is? Talk to that person. You are a PM/SM so you can't really evaluate Tom‘s work, you can only observe that he's working less than the others. But maybe he's more productive, maybe his code is better, maybe he works on hard technical tasks that take a toll on his brain power so he needs more breaks. For a developer, time spent banging at the keyboard might not be time spent being productive and doing a proper job. So take it up with his superior (which I hope is another developer, not a manager, or you will have the same problem or worse).

The alternative is micromanaging Tom. Yes, micromanagement sucks, but for the right people it is the right tool. We all wish employees are proactive, professional, don't need to be told what to do, ask for help when stuck, etc. But people come in all shapes and sizes. Tom isn't the right shape and size so it needs more attention to rough out the edges. This can backfire too and cause Tom to talk behind your back like I mentioned above if he's the only one being micromanaged. You might also start micromanaging other stuff too if you see it brings better results with Tom, but that is a very slippery slope for you to be on, which on the long run might cause even more damage to the team and projects than Tom could ever do.

Whatever you decide to do, do something. Worst thing you can do is look the other way. Even if your decision is to leave it be for now, but monitor how things are going to take a better informed decision later, it is still better than looking the other way.

Situations like this are never fun, but if you are a PM/SM, they are part of your job description.

Answer 4

Talk to him about this. Don't attack his behavior, but point out the implications that you think his behavior has on the team. If he doesn't see the problem and doesn't want to change, take action and let him go. Hire for attitude, train for skills.