Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
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.
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.
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.
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:
"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.
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.
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.
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.
