How to deal with overachievers

Question

I'm working on a project that has fairly large scope and a lot of work to be done. One of the members of my team has a great work ethic and is very bright yet a little defensive. The problem is, he takes on too much work and delivers everything late. I need a way to say to him, "stop overloading yourself" without turning off his enthusiasm. Anyone have any experience with this type?

Thanks to everyone for their responses. I hate to put an "answer" on this, I really like all the insight. Appreciate it.

Answer 1

You cannot change people ..dont even try to do that.. Let him feel the burden and he will realize it soon and then he will stop overloading himself..things like this take time..it will not happen in one day...

Answer 2

I think one thing to note is that overachievers are driven by validation. They like to feel and know that others in on the team regard them as experts. Focus on building them up and validating their knowlege. This extra effort will pay for itself in productivity many times over.

Answer 3

Allowing him to continue is a double-edged sword: It may well force him eventually to realise that he has been taxing himself needlessly, but it may also burn him out and cause him to be disinterested (speaking from experience, so I thought I should mention). I take it, you are managing him, and if so, would it not be better to assign him manageable tasks that he can complete in time? Not until he has finished off and delivered one task or a set of tasks should you assign another to him.

Answer 4

Set up a video camera to record one of your meetings (preferably, a code review meeting). Tell everyone that this is for documentation purposes or as a developer's video. Tell them that everyone would review the video at a later date (to give them time to cool down and forget their emotions during the meeting)

In the meeting, talk about all the flaws of the code (not just the code that came from your overachiever. Everyone's code should be reviewed). Don't talk about the flaws of the coder, focus on the code. Everyone's mannerism and bad habits will be seen.

Most people, when they see their own flaws, will quietly try to fix their flaws.

We have a sort of hands-raised "I can do this" sort of system, and when he jumps onto a task everyone kind of backs off.

In the meeting, hand out tasks like you usually do. This behavior where everyone backs off would be recorded. Hopefully, he will pick this up.

Answer 5

be friendly, assertive. don't be scared to address it just because he may get defensive. handle his defensive reaction by approaching the situation with a positive attitude. ("you do great work, and we're going to make it better").

first - ensure he actually respects the deadline. in some companies deadlines are very wishywashy things. it's hard to change that culture once it's ingrained. you need to illustrate that timeliness actually IS important.

once he actually knows the value of timely delivery, this is just another problem. geeks love solving problems, especially overachieving ones. collaborate with him to solve it. work together to identify the issues. ask him what you can do to remove the obstacles to him delivering on time.

numbers help too. visability of the metrics you want to adjust will help him to keep on track.

Answer 6

He might want to take bigger issues just because he likes to have some solid ground for working and not worry about random little things. So, he has the right to like what he likes, of course, and if you give him the option to choose, you can't blame him - unless you start guiding and or measuring the project. Or maybe there are bigger but easier issues.

Sometimes few things depend on each other and they need to be built together. In that case you could link the subissues as related in the issue list. By linking you restrict the issues at least only to the selected ones.

If you create new features, sometimes whole design principles might be needed to be created. So the developer might want to delay the work in order to get the design issues done. I think this is acceptable, though you could make the design issues as their own issues and then link the actual features depending on the design issues. This way he could design bigger things while everyone knows what is going on.

Also if you have design guidelines, the developer could use them and it wouldn't take as much time to finish the work then. Design guidelines would restrict the development too, so someone creates the guidelines and that is it, no soloing around or the solo should be the architect or something. It is good to have consistent design principles, but everyone should be able to give ideas.

Answer 7

1. Ask the "over achieving" person to get work done (manage) from other "average" person. (This way he / she will understand though Individual contribution is good, it is prefered that Team is winning finally)

2. Give R&D intensive work and delegate business related funtional work to other folks

3. Talk to "over achieving" person and take them for outing (Quite often people get trapped in to work and never realize, world outside programming is also beautiful)

4. Give "more" non programming work such as organizing meeting, organizing events, paper presentation, taking trainings etc.

...

Answer 8

Sidestepping a little, it also goes the other way round. All too often I've seen managers who would want to push their overachievers to the extreme with more and more stuff. This is really frustrating and I don't know of any other solution than to quit the job even if the problems being solved were interesting.

Answer 9

If you are the team lead, it is up to you not him to distribute tasks. If he is given too much, then you need to reassign his tasks and be more careful in the future about what you assign. Do you know exactly what tasks each person is assigned to? You should consult that list and the due dates on the tasks (and your knowledge of the progress made onteh tasks) before assigning more work to any developer. If you keep up with the progress on tasks as they are being done, you will know when one task is going to cause other tasks to fall behind because the developer is stuck on task 1; that is the time to reassign, not after the deadline has passed.

Answer 10

Does he take on too many tasks at once or is that the few he does take on are large tasks and that is why he is late? I can picture either scenario for what you describe where if he is taking on say 7 tasks at once, you put in a rule about only allowing 3 tasks to be done at any one time for example. If on the other hand he only has a few things to do the question then becomes breaking things down so that the bite-size pieces that get worked on can be estimated properly as perhaps he just thinks something will take a couple day since the bug is easy to fix but then he tries his fix only to find it doesn't work 100% of the time.

I'm not sure I see this as an overachiever so much as someone that may not manage time well or make reasonable estimates. The overachiever is the person who delivers with all the bells and whistles that weren't requested as a sign of, "See, I am GOOD at this!" which I think I have been a few times though hopefully I'm getting past the need for external validation.

Answer 11

If you would use (parts of) scrum, you would have a scrum board with tasks (stickies work great if you are colocated) and everyone can pick one up and has to deliver first, before he/she can pick up the next one. It's visible and the work is bound to a physical thing that a person can get hold of. If he develops a huge pile of stickies on his desk w/o delivering, it might open his eyes. Another technique from scrum/agile is the daily stand up, where you answer three basic questions:

1. What have I done since the last meeting?
2. What am I going to do next?
3. Are there any impediments in my way to get my work done

It's reporting to the team and makes things visible. Scrum is not a panacea but could help you to create a more homogeneous team.

Answer 12

I've seen a LOT of poor answers for this one already.

First, the things you do NOT want to do. Which you seem to be very aware of already.

1. Do NOT stunt his enthusiasm.
2. Do NOT stop him forcefully (i.e. removing tasks) from being the over acheiver.
3. Don't try to shame, subvert, or do any of those other suggestions.

Any of these things as you are aware is one of the sure fire ways to lose the developer. Either he/she'll become totally withdrawn and become an "average" developer, or they'll just leave the company/project. Either way, you end up with the same result of less productivity, lower throughput, and unfinished projects.

So what do you need to do? First think about utilizing Agile with this person. Serious, tried and true pair programming and some other things. This spreads the "over acheiver" around to utilize what they know but also allows others to get up to that speed also.

Another thing, YOU have to manage better. If he/she falls behind on tasks then YOU are responsible for identifying this and controlling the flow of tasks and or "user stories".

All in all, this sounds like a case of waterfall or some other process getting in the way of an individual that could make much more of an impact toward the progress of a company/project/effort. Make sure to remove the barriers and let that person play a larger role.

Psychologically, profitably, morally, and ethically this is the appropriate thing to do. Hope that at least plants some ideas.

Answer 13

It's not unlike feeding children - their eyes are bigger than their stomach.

One solution is to give them a portion you feel is appropriate. If they ask for more, tell them to finish what they have first and they can always have seconds. Make sure to keep the dessert for the end (or when they need motivation), and they may actually finish faster just so they can get what's next.

Answer 14

He needs to learn how to do work systematically. He probably lucks regularity and discipline and needs to create for himself serious challenge which would constantly keep him moving. Unfortunately he probably does not realize why he does it also so it is useless to ask him for explanations. May be he needs somebody to create work rhythm for him? For example daily meetings tet-a-tet where you will discuss his work. No pressure. Just regular base lining. It will force him to analyze pragmatically where he is and how fast he is going.

Answer 15

ive worked with a coder like this before, they are rare. this guy was a bit of a 'pod' actually.

he would try gobble up too many tasks - more then he could chew. and whats worse, senior management would make him feel guilty when he didnt finish the work he promised.

adam has the exact answer; "If they ask for more, tell them to finish what they have first and they can always have seconds."

the way i used to work with this group of coders was there was a process of sharing out tasks (based on the project schedules). i would say "grab what screens you want", so the programmers would chose and negotiate amongst themselves what they wanted to do. if one programmer was ahead of the other, i would just tell them "go ask Tom for one of his screens".

see, managers sometimes miss the point of what management is about. its not 'telling people what to do', its making peoples lives easier so they can do what they need to do.

having an over-achiever/super enthusiastic person on your crew is a massive asset. you just need to figure out how to work with them well.

LM