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?


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
  • 10
    What about suggesting some pair programming for specific tasks and explain it's a method to share knowledge and do something different. It might give an insight to how he is working and give you first hand knowledge?
    – dreza
    Nov 26, 2012 at 7:09
  • 44
    Have you considered that something else entirely may be going on with this person? When someone is calling in sick a lot and has to attend many personal events, my guess would be that something is happening in his private life that is distracting him at work. Badgering him about his performance isn't going to help either of you. Talk to the guy, find out what is going on in his private life, help him out if you can, give him some leeway if he's valuable enough to you - he will thank you for it and probably return with interest when his personal life is sorted out. Nov 26, 2012 at 7:19
  • 4
    @MarjanVenema, I talked to him, he felt that he was already giving his best, namely, my feeling was wrong. Also, not everyone wants to share their private life with you. You are risking being labelled a busybody by asking other people's private life Nov 26, 2012 at 7:29
  • 3
    What do the other developers in the team think of this person?
    – MarkJ
    Nov 26, 2012 at 12:59
  • 5
    I'm reopening this question. It doesn't make sense on Workplace to me, which is for general and cross-disciplinary concerns. The specific measurement of performance of software developers is different than measuring performance of some other professions, so I don't see how it's appropriate for migration. However, @ATeamLead, you should update this question with some more of the information that was asked about in the comments, such as your geographic location.
    – Thomas Owens
    Nov 27, 2012 at 13:03

11 Answers 11


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.

  • 3
    we need to work together to improve my perception -- Exactly what I was thinking when I read the question, especially the "Outcome" section. Nov 27, 2012 at 17:46
  • 2
    My sympathies are with the developer. If he's delivering what was requested, on time, then the project manager's "feelings" are not only baseless and irrelevant, they are insulting. Nov 29, 2012 at 2:07
  • 4
    @StevenA.Lowe: Am I missing something? The question says that the developers get to set their own expectations and he still regularly misses them. Not to say that I haven't been guilty of overestimating my own abilities (and the OP makes the same concession), but I'm struggling to see where you're reading that he's "delivering what was expected, on time".
    – pdr
    Nov 29, 2012 at 2:20
  • @pdr: lol perhaps i misread, though this question seems to be edited every day. the dev in question is missing his estimates, but apparently no more so than the other devs on the team. suspect a lack of training and/or leadership ;) Nov 29, 2012 at 21:28
  • 2
    +1 - the problem here isn't that he's underperforming. As the OP said, he doesn't know that he is or not, and that is the problem that both he and the developer need to resolve.
    – Zibbobz
    Apr 14, 2015 at 14:09

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.


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.


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).

  • I don't see how this is connected to my question. Nov 26, 2012 at 8:25
  • @ATeamLead I updated the answer to clarify the connection. Basically, when you have regular 1:1's there is much less mystery and difficulties like you describe. At least that was my own experience
    – gnat
    Nov 26, 2012 at 8:31
  • 1
    +1 this is connected to the question because if you follow this practise, problems like this question are less likely to arise in the first place, and easier to solve in the second place.
    – MarkJ
    Nov 26, 2012 at 12:58

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.

  • So when did you do the daily standup? Nov 26, 2012 at 8:25
  • 1
    We do it at 9:30 GMT which works out at 15:00 Indian Time currently. We have myself and a team lead in on a conference call which never lasts longer than 15 mins and is usually over in 10. There are some Ireland based developers who work from home and they can ring in as well.
    – Eoin
    Nov 26, 2012 at 14:59


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.


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.


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.

  • So how would you manage your developers? Give them tasks to do for a period of time, let them do whatever they want to do, don't bother with their progress, and at the end of the month, accept in resignation that only a portion of the designated tasks get done? Nov 28, 2012 at 2:02
  • Requiring % complete stuff is silly, but daily standups, IMO, are a huge boon when kept brief, informal, and more about communicating needs/challenges and priorities at a moment when you have the whole team's attention. Nov 28, 2012 at 3:13
  • 1
    I don't manage my developers, I manage my projects. If a developer commits to completing task A in X days, I check in after X/2 days to see how he's doing just as a formality, but my developers know to tell me immediately if they run into anything that will cause them to slip the deadline. After X days, they deliver. If you have people that chronically overpromise and underdeliver, asking them to make up an imaginary progress percent-done number every day will do nothing to change the fundamental issue (which may be estimation, tools, training, etc.). Processes and numbers != management. Nov 29, 2012 at 2:01
  • 1
    @ErikReppen: I agree with the kinds of information exchanged, but firmly believe that such information should be transmitted the instant it is discovered, and only to interested parties, rather than distracting the entire team every day for no good reason. Timely communication is the key, not rituals ;) Nov 29, 2012 at 2:04
  • 1
    I've worked in too many environments where that's simply not something you could rely on, even if all parties were being as responsible as they could about it. Interested or not, every member of a team should be aware of the kinds of obstacles their teammates are running into. It's not about manager to employees, it's about a team working together. In scenarios where it's not, I would agree that it's just another useless distraction. Nov 29, 2012 at 3:00

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.


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.

  • What about the code check in's? Does he checks in his code all the time? No he doesnt-- he only checks in when he's done with a feature, and that could be a week long gap in terms of check-in. when you do assign a task, do they commit to a timeline or is it you who assigns them the timeline? They are committed to it. Nov 26, 2012 at 7:19
  • 1
    That's again a problem! What if something happens to his machine? I think he should be checking in his code everyday. I understand that a nightly build can be broken if his code has some error but at the same time, it's not hard to fix compile time errors unless he codes on notepad lol.
    – Bytekoder
    Nov 26, 2012 at 7:21
  • Also, there are a lot of non-trivial programming tasks that are not so easily estimated. And of course every single programmer-- by definition-- is doing that kind of tasks instead the programming tasks they did before ( Why would you redo something which you can easily reused?). So this makes estimation very, very hard and I won't fault them even if their estimation is missing by leaps and bounds Nov 26, 2012 at 7:22
  • 2
    @Bytekoder, there are thousands of runtime/logic errors that will break an application. Your code compiles doesn't mean that it is stable. Nov 26, 2012 at 7:43
  • 2
    -1. The length of the sprint is hardly the issue. And checking in code often, into the only branch available will only serve to break the build. Nov 26, 2012 at 7:47

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.


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.



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.


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.


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).

Not the answer you're looking for? Browse other questions tagged or ask your own question.