We have a team of 3. Developers A and B would each take about a day to do a task X. Developer C will take an entire week.

What is the best way to deal with this? I don't want to fire them because it's so hard to find competent developers, but at the same time, it's a hassle only being able to give them non-critical tasks.

  • 5
    This is a line management problem, not a project management problem. The project manager is responsible for accurately estimating the amount of time it will take to accomplish the task; sounds like you've already solved that problem.
    – MCW
    Dec 8, 2014 at 15:52
  • @MarkC.Wallace That's a good point, which hadn't occured to me. Unfortunately our company is small enough that I'm doing both jobs. Is this not an appropriate site for the question? Should I ask it somewhere else?
    – Benubird
    Dec 8, 2014 at 17:10
  • Could you clarify what the problem is that you are trying to solve? Mr. Espina and I read different things into the question.
    – MCW
    Dec 8, 2014 at 17:54
  • 8
    @Benubird - There is a tacit assumption in your question that the quality of the output of A, B and C is the same. Is this the case in your situation? I've seen a lot of SMEs working on whatever who take longer than average but give you a better product.
    – Doug B
    Dec 8, 2014 at 20:50
  • 1
    The question doesn't inherently prove that C is at fault here. A and B could be cutting corners and building up technical debt, and C could be the only one going through proper analysis, implementation and testing procedures. Speed should not be the primary criterion to judge a developer on.
    – Flater
    May 7, 2022 at 8:22

6 Answers 6



You have already decided, a priori, that team member C is the problem. This is based on information you have not provided in your post. As a result, this appears to be a false conclusion that papers over a process problem that you (as the project manager) are responsible for uncovering.

The Problem

Given a task X, developers A and B would each take about a day to do it. Developer C will take a full week.

And this is caused by...what? Difference in typing speeds? Perfectionism in C? Sloppy work from A and B? You have thoroughly failed to define a root cause, so I will define one for you.

This "performance gap" is not necessarily a performance gap. It is a communications gap where the project manager lacks understanding of the team members individually and the team's gestalt dynamics, and has failed to address underlying process issues.

The Solution

You need to inspect (and possibly adapt) your process. Until you thoroughly understand why members of your team are performing at different rates, you can't formulate a different approach. In short, you need to fix your communications problem with the team quickly, so that you understand all of the contributory factors to this disparity between your team members.

Once you understand why your team members are developing at different rates, you can adapt your process as you see fit. For example:

  1. You can fix whatever underlying process problem is causing this differential (e.g. skill deficits, poor specifications, poor communications, lack of time-boxing, or lack of product ownership, regardless of which team member is exhibiting the problems).
  2. You can acknowledge the problem, and take it into account in your scheduling. You can create aggregate estimates for the team that average out speed differences, or you can assign more realistic targets based on actual, historical values for the team or its members when updating your project plan. Either way, you must get away from assuming your desired targets are delivery guarantees, when clearly they aren't realistic based on your team's current overall output.
  3. You can replace team members that are under-performing. Whether this means replacing the slower developer, or replacing the two developers that are turning in faster (but potentially less-complete or less thoroughly-tested work) is entirely up to you. You need to base this decision on what the project and the organization value, and no one outside your organization can make that determination for you.

"Holding people accountable" for management targets is a common project smell for projects that will fail. It's much better to work with accurate estimates from the task performers, and to ensure that the schedule has accounted for as many variables in its processes as possible, including human variables. Always examine the root cause (or causes) of a process problem before assuming its a people problem. While people can sometimes be the real reason, more often than not it's the process or framework that is at fault. Your mileage will of course vary.

  • 2
    Excellent answer. Definite +1 there for pointing out that the problem may not be C being slow, but A & B rushing things and not performing the job properly.
    – David Arno
    Dec 19, 2014 at 15:58
  • Very good answer! Jul 28, 2017 at 4:47

You need to understand why developer C takes 5 times longer.

It's an awkward conversation, but you need to let C know that you feel he takes significantly longer than the other developers to get X done. Then simply ask him why.

There are countless valid reasons that developer C might be performing under power, from needing to skill up in a tech but being afraid to ask for time to do so, to personal problems he is trying to work around.

It's important I think for people to know if they are being viewed negatively. It gives them and you an opportunity to fix the problem together.

But bottom line, is if it can't be fixed, then you need to let them go and find someone who can do the job, even if it takes a while. Although you may feel an under achieving developer is better than none, thats because you can't measure the adverse affect he is having on the other developers A and B, it's very possible that team would be more efficient without C holding them back.


This is exactly the problem I faced and just solved it. The solution is not as elegant as others are proposing but this is the only solution that worked for me.

I was handling a team of 4 developers. All are having variable speed if you see from hours perspective but 3 of them were decently paced differing with each other by maximum 3-4 hours from each other. So as a PM I could manage the timing and predict/estimate that when the work will be complete. But the 4th developer was too slow. Differing others by more than 30-40 hours at times. This threw all my plans off the window. I always tried that he does not get to work on a module on which other team members' modules were dependent but still he slowed down the entire project. I put that 4th person in PIP(Performance Improvement Plan) where he is interviewed and trained again on the basics he lacks in. Yet no improvement.

We continued like this for almost 3 months. When I compared the estimates provided by the 3 well performing team members there was a gradual increase in the their estimates. When I asked about the increasing timelines they shot back with an argument that 4th one gets whatever time he wants and no one questions him.

This was the time when I realised that if you want your A team to work and perform get rid of B grade people. Finally I had to asked HR him to be put him on bench or ask to leave and get me a new team member. This new member is performing better. Timelines and production has improved. Team is more motivated to beat each other in a healthy competition of completing the work before the other person with least number of bugs.

I don't know if this works for you, but believe me, I have learnt after wasting a lot of time, that A grade team members shall never be mixed with B Grade team members. Only few B Graders will improve themselves to A Grade, but possibility of B Grade pulling down A graders to B grade level is higher.

If someone comes back to me saying that you should appraise them separate as per their performance. Please be informed that appraisals in our organization happen after 1 year. One cannot wait for 1 year show displeasure on the performance.


The best thing you can do for the project is to make C better.

First, you need to figure out the source of the problem. It can be related or unrelated to their skills. Having an open discussion with C really helps, if you are delicate and appreciative of the effort he already puts into work. In most cases a person is not deliberately working slow.

Once you know the source of the problem (lack of education, personal issues, whatever else) you can devise a plan to train or coach him.

If the problem is in lack of education/skills, then consider allocating time from A and/or B to work in pair with C. Technical guidance from more senior people is, in my experience, the main source of skill improvement.

If the problem is in C being disorganized and wasting a lot of time, consider coaching him/her to use the time and spend effort more thoughtfully.

There can be other reasons (lack of motivation, personal issues etc.), so you'll have to be creative in solving them. There's plenty material in the internet on that.

As a start for you it is worth listening to this podcast: https://www.manager-tools.com/2006/02/how-to-fire-someone-well-almost . It shows how to take a poor performer and turn them into a good performer (if at all possible) through gradual and consistent feedback and coaching. To simplify, you openly discuss with C your concerns and them coach him/her to become better. Rinse and repeat.

  • 1
    why assume C is worse and needs to be "better"?
    – warren
    Dec 11, 2014 at 20:36
  • 3
    @warren, this assumption may be wrong - I seem to have fallen in the similar trap as the OP; CodeGnome's answer pm.stackexchange.com/a/12801/13461 is definitely better Dec 11, 2014 at 21:18
  • 1
    I like @CodeGnome's answer, too :)
    – warren
    Dec 11, 2014 at 21:48

I think this is a good project management question because it exposes the huge gap between three things: an estimate, a planning value, and actual performance. Both the estimate and actual performance are probabilistic and span across a range of performance values, such as one day to one week as described in the OP. The planning value is deterministic, some single value within the estimate on which a PM would base his/her schedule.

A whole host of variables influence in a very random way where actual values actually come in and will change if you performed the activity over and over again, yielding the range of actual results spanning from best case performance to worse case. One of those many variables are both human and machine performance, where you can safely expect some humans to out perform others and where an individual's performance will also vary. You only have so much control over those phenomena, so your planning value needs to reflect that risk.

So in the OP's example, if the estimate is one day to five days (assuming the most likely is somewhere in the middle), then the planning value might be two or three days. From here, you manage those variances across all the tasks in your schedule, where in some cases you come in fast and others you are late. With early signals, you mitigate where you can and with a little luck you come in reasonably close to your planning values.

This is project management.

This should not be frustrating as you should have planned for this stochastic variability in your schedule and have enough reserves to play with. Monitor your variances and, if the lower performer continues to exacerbate your variances, then replace if you are able. If not, communicate early and often where you think you are headed.

  • 1
    Your answer is unarguably true, but I believe it is unresponsive to OP's question. OP has a task and a clear estimate of the time required. OP can even break it down into a resource prioritized estimate (A = 1 day, B= 1 day, C= 1 week). If A & B are occupied with high priority tasks, then we know it will take a week. (If A,B & C must collaborate, I suspect it will take a day for A or B to lose patience and 1 day to develop, so 2 days). The problem isn't estimation, it is motivation/supervision.
    – MCW
    Dec 8, 2014 at 17:49
  • I don't read an estimate in the OP. What he indicates implies actuals. The question remains, what were the planning values the OP used in his schedule. Dec 8, 2014 at 17:53
  • Yes, this isn't really about estimation. Regardless of whether it takes A one day or two, he's still going to be done 3 days before C could do it at the earliest.
    – Benubird
    Dec 8, 2014 at 18:29
  • It's about your planning values. Planning values are not estimates. What did you plan? Did you account for aleatory variability? If you did, this would not be a concern, generally speaking. Dec 8, 2014 at 19:09

I agree with the apparent consensus that you must ask the slower developer why (s)he is taking so long. Then, you must carefully listen to the answer. "Speed" is not necessarily a virtue if quality suffers. I vividly remember working with one team that put out sloppy work very quickly.

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