How to tell whether your programmers are under-performing?

Question

I am a team lead with 5+ developers. I have a developer (let's call him A) who is a good programmer, who writes good clean, easy to understand code. However he is somewhat difficult to manage, and sometimes I wonder whether he is really under-performing or not.

1. Our company requires the developers to indicate the work progress in the bug tracker we use, not so much as to monitor the programmers but to keep the stakeholders apprised of the progress. The thing is, A only updates a task progress when it is done ( maybe 3 weeks after it is first worked on) and this leaves everyone wondering what is going on in the middle of the development week. He wouldn't change his habit despite repeated probing. ( It's OK, developers hate paperwork, I do, too)
2. Recent 2-3 months he on leave quite often due to various events-- either he is sick, or have to attend a lot of personal events etc. ( It's OK, bad things happen in a string. It's just a coincidence)
3. We define sprints, or roadmaps for each month. And in the beginning of the sprint, we will discuss the amount of work each of the developers have to do in a sprint and the developers get to set the amount of time they need for each task. He usually won't be able to complete all of them. (It's OK, the developers are regularly missing deadlines not due to their fault).
4. I am based in Singapore. Not sure if that matters. Yeah, Asians are known to be reticent, but does that matter?

If only one or two of the above events happen, I won't feel that A is under-performing, but they all happen together. So I have the feeling that A is under-performing and maybe-- God forbid--- slacking off.

This is just a feeling based on my years of experience as programmer. But I could be wrong.

It is notoriously hard to measure the work of a programmer, given that not all two tasks are alike, and there lacks a standard objective to measure the commitment of a programmer to your company. It is downright impossible to tell whether the programmer is doing his job or slacking off. All you can do, is to trust them-- yeah, trusting and giving them autonomy is the best way for programmers to work, I know that, so don't start a lecture on why you need to trust your programmers, thank you every much-- but if they abuse your trust, can you know?

Outcome:

I've a straight talk with him regarding my perception on his performance. He was indignant when I suggested that I had the feeling that he wasn't performing at his best level. He felt that this was a completely unfair feeling. I then replied that this was my feeling and I didn't know whether my feeling was right or not. He would have none of this and ended the discussion immediately.

Before he left he said that he "would try to give more to the company" in a very cold tone. I was taken aback by his reaction. I am sure that I offended him in some ways. Not too sure whether that was the right thing to do for me to be so frank with him, though.

---

My question is: How can you tell whether your programmers are under-performing? Surely there are experience team leads who know better than me on this? 

---

Extra notes:

1. I hate micromanaging. So all that we have for our software process is Sprint ( where tasks get prioritized and assigned, and at the end of the month, a review of the amount of work done). Developers would require to update the tasks as they go along everyday.
2. There is no standup meeting, or anything of the sort. Mainly because we have the freedom to work from home and everyone cherishes this freedom.
3. Although I am the one who sets the deadline, but the developers will provide the estimate for each tasks and I will decide-- based on the estimate-- the tasks that go into a particular sprint. If they can't finish the tasks at the end of the sprint, I will push them to the next. So theoretically one can just do only 1 or 2 tasks during the whole sprint and then push the remaining 99 tasks to the next sprint and still he will be fine as long as justifies this-- in the form of daily work progress updates

Answer 1

This should be a surprisingly easy problem to solve.

Have a second meeting with him. Tell him that you accept that it's probably your perception of reality that is at fault. Then qualify that with "however, if that is the case then we need to work together to improve my perception." Finally challenge him to solve that problem, so he doesn't feel micro-managed.

This exact thing happened to me a long time ago. For me, the issue was that I dislike the possibility that anyone might think I'm seeking extra credit for simply doing my job. And that was fair enough, but there has to be a regular feedback loop between any member of staff and their line-manager.

If there isn't then you get these problems.

Regular, planned, 1:1s are a great idea. And, as people have pointed out, standups do not need to be orthogonal to working from home. But they must involve the three questions: What did you do yesterday? What are you planning to do today? And the one most people forget ... What (if anything) is holding you up?

That said, you should try to discourage situations where team members never work together. I've worked in that situation before and it seeded distrust within the team and outside it. Have a regular day that you all come into the office. Have a regular meeting where people can voice some ideas on improving processes or whatever.

Don't make it a line-reporting event. Make it an opportunity to just talk. You'll be surprised what you learn. If possible, turn that into a social event, go for a couple of drinks on work time as a bonding exercise.

Answer 2

There's lots of great advice here, and I don't want to take away from any of it, so I'm posting this as a separate answer.

First, it is evident to me (and apparently others) that you have not discovered the root of the problem. You're staring at a symptom and trying to cure that. You need to find out what is causing so much friction between yourself and this developer. Perhaps you're being too authoritative (my Product Owner recently described herself as having "Infinite Power" over a project and that was offensive to me, even though she laughed when she said it). Perhaps he is having severe family problems (would explain all the time out of work). There is a root problem here, and until you find it, this will not be fixed.

Good Catch!

If his performance could be better, that's great that you've determined that. Remember though, that if his bad performance is still good performance by comparison, then you need to tread carefully to avoid losing a good developer. Good developers are hard to come by, and good developers require a very specific set of things. Perhaps take a look at the Joel Test to see if his needs are being met.

Find the Source of the Problem

If he is unhappy with something related to the job he's doing, then you can only fix it by determining the source of the problem. Let me be clear, you said your programmer wrote good code. That means that he loves programming. It is more than evident that he is frustrated at work (from your description of the meeting), and you're probably right that his performance is below where it should be, but don't assume. Remember that many programmers just don't have social skills.

You're Not Perfect Either

Remember that sometimes you're going to have personality conflicts, especially with introverts. If this turns out to be a personality conflict, consider how far you're willing to go to gain an increase in performance (see 1)

All of That Said

I wrote a blog post about Managing Programmers. I think you should read it.

http://deltreey.blogspot.com/2012/07/managing-programmers.html

I cannot emphasize enough the last part of that post.

If your developers are any good at all, they want to code.

Your programmer, even if he is slacking off, does not want to be slacking off. You have to find the root of this problem, and it may turn out to be something that simply cannot be fixed and he has to be let go, but whatever it is, you cannot make an informed decision without determining it.

Answer 3

When it feels someone is "somewhat difficult to manage" like you describe, to better understand how does one perform and whether there are issues (objective or subjective) impacting productivity of dev team members, consider establishing a practice of regular 1:1's with your team members, as presented in an excellent article The Update, The Vent, and The Disaster:

...I’m not suggesting that every 1:1 is a tortuous affair to discover deeply hidden emergent disasters, but you do want to create a weekly place where dissatisfaction might quietly appear. A 1:1 is your chance to perform weekly preventive maintenance while also understanding the health of your team.

...The sound that surrounds successful regimen of 1:1s is silence. All of the listening, questioning, and discussion that happens during a 1:1 is managerial preventative maintenance. You’ll see when interest in a project begins to wane and take action before it becomes job dissatisfaction. You’ll hear about tension between two employees and moderate a discussion before it becomes a yelling match in a meeting. Your reward for a culture of healthy 1:1s is a distinct lack of drama.

---

_{A very strong point of mentioned article is that it is self-contained, in the sense that besides explaining benefits, it also provides a set of practical recommendations basically allowing one to start practicing regular 1:1's without digging into other sources (although looking for additional information won't hurt, you know).}

Answer 4

Obviously, there is a major communication issue here. He may well be doing fantastic work but if you've got the feeling that you don't know what he's up to then that by itself is an issue. And if you don't know what he's doing, then his coworkers probably don't either. This can cause issues when he does check his two week old code in. Especially if there was anyone working in a similar area.

You can always suggest that he checks in/provides updates more regularly to minimise these kinds of conflicts. This could allow you to couch your request in terms of helping the team rather than "I don't know what you're doing".

I know standups get a lot of hate but it doesn't actually have to be held in the same room. A quick call or a group Skype update once a day is very quick and keeps everyone on the same page.

I'm currently working from India with a team in Ireland and I can't imagine not being in communication with each of them on a daily basis and I either know roughly what each of they are at or I can find out very quickly.

Answer 5

Pointless

Daily status updates are pointless. Having people report 'today I am 2.5% complete', 'today I am 3.74% complete' is ridiculous.

It provides no value to the stakeholders, and annoys the people doing the work.

Leave them to their work, undisturbed.

Baseless

On what grounds do you suppose that developer A is 'underperforming'? If his/her work is being done on time, that should be good enough.

You say you hate micromanaging, yet what you have described is exactly that.

Our company requires the developers to indicate the work progress in the bug tracker we use, not so much as to monitor the programmers but to keep the stakeholders apprised of the progress. ... Developers would require to update the tasks as they go along everyday.

This is pointless (see above) nonsense. Your team is not flipping burgers, they are crafting technical solutions. Progress is not linear, nor is it easily measured or even estimated. Even if it was, such daily measurements or estimates have no value.

Dangerous

Reexamine the basis for your 'feeling' that developer A is 'underperforming'. You think he/she could do better, but on the basis of what evidence?

Unhappy != underperforming

Continue as described, and at some point, developer A will likely decide that he/she is under-appreciated, has given enough to the company, and will find another company. Squeezing the last 0.01% of effort from employees is far less important than retaining them for the long term.

Answer 6

Developers might hate the effort of documenting what they do and updating statuses - but that's part of being a professional developer. I would suggest that you could try to point out to him that his late updates of your issues log is causing an unnecessary negative perception of his work. If he doesn't see that his failure to communicate is a performance problem - well, you're his team leader; tell him that it is.

Regarding estimation - that's a classic problem. I recommend reading "Software Estimation - Demystifying the black art" by Steve McConnell. In this instance, you give the impression that most of your developers under-estimate. This is, curiously, normal, and rarely addressed. I would suggest that you've got a problem with the estimation process itself, rather than this one individual.

Try to 'close the loop' of estimate-measure-review and improve. Then, if your developers are coming in on time more regularly and this one individual isn't, you can consider what to do about him.

Finally, have the stand up meeting. Even if it's by Instant Message. All you want is everyone to know "what I did, what I'm doing today, any issues". And if there are issues, take them offline for discussion later. That's what I've done before, and it was successful for that team.

Answer 7

First thing, why are your sprints that long? Sprints should never exceed two weeks. I think the majority of your problem lies there. I would recommend you to shorten the sprint time on a trial basis and then analyze your question again.

What about the code check in's? Does he checks in his code all the time? I personally think that programmers are not really management guys and the more you try to manage, the more they will get frustrated. In fact, I hate to do those update tasks and probably that's why PM's and Leads are there for. But at the same time, I do provide a status during scrum meetings or whenever we meet. Now when you do assign a task, do they commit to a timeline or is it you who assigns them the timeline?

Therefore, the only way I could tell if someone is under performing is to map the committed timeline to % of work done. Now of course, if someone says that it will take him two days to write a method that adds up two numbers, you know there is a problem so the timeline should be something realistic and agreed by both the parties.

Take it this way- If you can write a piece of code in an hour, give him an hour + some buffer. If he is delivering that to you in that amount of time, I think then you guys are just doing fine. If he is not then question him and later its up to you to decide whether he is furnishing a reasonable explanation or not.

One thing that you can do is to integrate something like XPlanner with versioning tool.

Answer 8

I don't think the programming profession is inherently different from other professions when it comes to identifying someone who is slacking off. You may have to go with your gut.

I personally think it's strange that A refuses to provide updates for weeks at a time. I am a programmer working from home, and there's an implicit contract between me and my employer that I need to provide daily updates on my progress. These are not "official" updates, it's just a short email or IM letting him know what's going on with the software I'm being paid to create. The update takes less than a minute or two to write, and offers closure to both of us. For bug fixes I mark the ticket as resolved in our bug tracker by the end of the day. These are not difficult procedures for me, though I enjoy a relaxed work environment with very little paperwork.

Even casual updates would be appreciated coming from him, I'm sure. You sound very, very lenient in your post. If you've been suspecting that he's slacking for an extended period of time, you don't need another excuse to address it with him.

Answer 9

Daily standups even if over Skype or in a chat room are the way around this but not if you treat it as an update for the stakeholders. When once a day the whole team just checks in to say what they've been working on, what challenges they're running into and what they plan on doing next, you get several wins:

• Whether you're wasting time for good or bad reasons, that something is taking too long is going to be more transparent, encouraging your devs to ask for help when they need it and not go overboard on research that probably didn't need to happen or solving a problem for the challenge of it when input from the rest of the team would help them knock it out a lot faster.

• You, as a manager can see where people are encountering roadblocks most frequently, which helps you estimate better and possibly resolve fundamental issues that are wasting time/money.

• IMO, it really helps the team learn to underpromise on estimates better when they can see how long it typically takes for everybody to get even relatively straightforward things done sometimes.

• You'll often be reminded of things that need to be communicated in terms of re-prioritizing when your team members tell you what they plan on doing next.

So forget '% of complete.' Just make the process about getting everybody honest with themselves as much as with everybody else, making better/more-reliable estimates as they gain more experience at it, and giving people a little more motivation to have progress to report without it turning into a mind-numbing exercise of putting a number on something that you really can't.

It sounds like upper management understands that deadlines don't always get hit. Doing daily standups will give you more ammo on that front because you'll have much more specific ideas about why they aren't getting hit.

And don't do them first thing. Always a mistake IMO. People need time to sink their teeth back into the problem before they can more reliably report on what all the issues are, IMO.

Quick standups that are more about communication than accountability, and simply setting goals, more than anything are what make agile work in my opinion. The rest I could take or leave, especially Scrum, which I've come to view as executive/stakeholder snake oil.

Answer 10

Underperforming?

Intensity ebbs and flows during a person’s career. If he’s worth more than he costs, then talk to him and try to make his job easier. Or else start looking for a replacement.

Communication

Don’t rely on weekly meetings. Most people aren’t going to do a complete braindump. Schedule more 1:1s. Ask them how things are going, what you can do better, and what you feel they can do better. Sometimes, there will be nothing to talk about, but that’s ok. By having more 1:1’s, you increase the likelihood that they'll remember to mention something.

Have a more persistent means of communication

You can get more information out of people if you don’t make it feel like an extra chore. If they’re all remote, have them use a chat program with logging capabilities like Hipchat or IRC. Having a more persistent means of communication encourages people to talk more. Lead by example and talk often, to encourage others to do the same. At least once a day, have people say where they’re at with their projects. Sometimes, just by looking at chat, you can get a feel for how things are progressing.

Source control

Have everyone check in their code daily. If you’re using git, have them push to their own branch on the company repo. By looking at the commits, you can tell how they're doing.

Separate the means from the ends

The stakeholders want to be updated? Deal with the stakeholders yourself. Part of your job as manager is to be the shit umbrella, so your coders can focus on their work. Look through the chat logs and commits, then write a summary about how things are going.

Answer 11

These are my suggestions:

1. Innovation: Imagination and creativity used to lower costs and improve the current situation.

2. Corporation: Willingness to help others accomplish their objectives

3. Initiative: Attempting non-routine jobs and tasks.

4. Attendance: Absences or lateness, Below standards.

5. Alertness: Ability to quickly understand new information and situations

6. Accuracy and Quality: Code reviews, delivering on time, issue rate).