How do I deal with a team member that keeps taking on tasks that he cannot solve?

Question

I was hesitant whether I should post this on programmers instead, but I think that this problem is generally applicable.

We have a junior team member (about two years with the company) who keeps assigning himself to big, tricky tasks that would have been more suited for a more senior developer. Since anyone is allowed to pick any item from the backlog, it is difficult to avoid this.

It is of course good that he is ambitious, but when he gets stuck he gets desperate. Instead of taking a step back and consider why things don't work, he often ends up going way too far down the wrong path. Then he starts bombarding other developers with questions that we often cannot answer because he doesn't give the context.

Given that I want us to work as efficiently as possible as a team, I have tried a couple of different solutions:

• Tell him exactly what to do. Consumes a lot of time for me and in the end he might not even understand his own solution.
• Give hints instead of specific answers. Sometimes this is successful, but sometimes he just ends up down the wrong path even further, especially if I don't understand the problem completely.
• Pair programming. He was quite reluctant to the idea, and when we tried it didn't work that well. He didn't take command, he just waited for me to tell him what to write.
• Right out tell him not to take a particular task. It's worked once or twice, but required a little white lie of why he shouldn't take that task. I don't feel I have the authority to forbid him from working on some tasks.

---

Update: Thanks for all the answers. Hopefully they will continue to be useful for future visitors. As for my story...

I brought it up with my manager (who had already observed the behavior) and suggested that we try to involve ourselves earlier and try to make sure that he splits too big tasks into smaller parts. My manager was more in the line that he should outright tell him not to take on difficult tasks. I'm not entirely happy, but we will see.

Answer 1

Self-organizing teams in an Agile development environment (any environment, really) can be wondrous things and produce great results both tangible (product) and intangible (culture, morale, etc). But at the root of self-organizing teams that work are typically these basic principles:

• competency: everyone knows how to do the tasks
• collaboration: everyone works together rather than as individuals
• motivation: everyone has good focus and interest in the tasks at hand
• trust and respect: everyone recognizes the competency of others on the team, through collaboration and general work efforts
• continuity: everyone has been together and has learned to work as a team for some time

From what you describe, your team has some issues with three of these things: someone is not competent in some aspect of the job, attempts to collaborate and solve this problem are not going well, and because of that the trust and respect is probably suffering as well.

This does not make for a happy and productive team, as you well know...and this is precisely what the manager of the team (or team lead, or whatever you call the person to whom the members of the team officially report) has to step in and manage the person who is having difficulty with some aspect of the process because of something that he or she lacks. In this case, the lack of ability to adequately judge the tasks at hand, the lack of ability to ask for help and productively collaborate, etc.

These are not things that are on the rest of the team to solve, even if you are a self-organizing team; there's still a functional manager whose job it should be to solve these issues.

Now, all of that being said, you (all?) should be commended for picking a bunch of things that are completely reasonable and usually work in these situations. Remove the ability to "choose" for a bit and tell the person directly what to do? Great idea, and also one that the manager should be responsible for, not members of the team, unless it isn't onerous for you all (but it will be). Push someone toward the right path that they don't see? Super -- that's a form of collaboration. But if they don't get there? Then they're still not there and you're in the same position plus further behind. Pair programming? Brilliant -- works for a lot of people, is a great form of direct collaboration, and that he was hesitant to do it or do it well shows that there is a people-problem there to be solved by someone not you (e.g. the manager).

The team lead who reports to me had this exact situation recently, and together we worked through each of the steps above, 1:1 between this manager and his not-quite-up-to-par employee who was messing up the rest of the team, and the outcome was that the team member was let go -- not for lack of trying on everyone's part, but for lack of fit and to some extent competency.

So, the solution for you all to enact is that you can't enact a solution. Please get your manager involved and frame the issues as clearly as you have here, both in terms of what you've tried, where it's gone awry, and where you and your team need help.

Answer 2

There is a reason why for hundreds of years tasks were assigned by managers, you know. You have just run into why.

If you want to continue doing this (which I recognize is a current fad - one I feel was not well thought out), then perhaps you need to classify the tasks by what kind or level of developer can take them on. If someone wants to transition to a more senior role or one outside their current experience, then perhaps they are allowed to take on those tasks but only with a specific kind of guidance (like doing it as part of a pair) or only on the approval of the team lead after the person makes the case for how he would handle it. It is disastrous to let developers run amok in tasks they are not currently trained to do or have the judgement or experience to be able to do them. It is bad for the company, it is bad for the clients and it is ultimately bad for the devs who get overfaced.

Answer 3

Encourage His Good Habits

Taking on challenges is good. Asking questions is good. Trying to work things out himself is good. Whatever solution you end up pursuing, be sure that you aren't going to harm the positive aspects of him as a team member, otherwise you are going to suffer in the long run.

Identify His Bad Habits

So what is the real problem here? You've listed a bunch of symptoms:

• He cannot solve the problem
• He asks questions with no context
• He takes time from other developers

But why does this happen? What is the actual bad habit at the heart of these behaviors? Is it that he doesn't realize when he's bitten off more than he can chew? Is it that he has too much pride to ask for help on tackling the issue from the start since he picked it? Is it that he wants to learn new things but doesn't have any easy way to get guidance when he can't justify it as a part of solving an issue?

I'd suggest getting involved earlier. Since you were his mentor, and he trusts you, you could step in earlier in the process in a non-threatening way to give him an easy way to talk about what he's doing to you. Something like, "Wow, that issue you're working on seems like a really interesting challenge. I'd love to hear your thought process on it -- I'm always looking for new ways to solve these more complicated issues." It's a non-threatening way to see what the actual issue is, and it helps get in at an earlier stage.

Find a Way to Work Around His Bad Habits

It is much easier to grow talent than to correct bad habits. If you understand his motivation better, and why he runs in to problems, you can find the best way to avoid those pitfalls while keeping him motivated and using those good habits for the best. If he wants positive feedback on taking challenging issues, you can suggest good issues for him to tackle that won't be over his head and be sure to compliment him when he does a good job. If he needs to get support in the early stages to work through the entire issue before he starts, you can find a way to set time during team meetings to have some brainstorming, or otherwise create an opportunity to have him work with someone for the conceptual stage (but not to the point of pair programming).

It is always easier to focus on the bad habits because those are always the nagging things that cause issues for other folks. The problem is that focusing on bad habits without cultivating the good ones runs the risk of killing motivation and dulling his natural talent by making him focus his energy on what he's not good at.

You don't need to be a manager to act like one, supporting team members is good practice for anyone at any position.

Answer 4

You should probably have an up front conversation regarding his negative impact on the team's workflow when he "bites off more than he can chew". If you can give pointed examples on where he has dropped the ball and how it has impacted the team. The objective should not be just to have him stop exceeding his reach, but to develop a strategy to hone the skills he needs to become a better programmer. At least you are reaching out and having the conversation.

Answer 5

Try recommending projects for him to take, you could play it up as if they are important and need to get done right away. If this doesn't work take him aside for a moment and sit him down. Explain to him it's important to get the basics down and since he's knew to the company he should be focusing on the other tasks. Don't tell him to take simpler tasks, find an alternative way to say this; for example say take a task that only uses these 3 files which are commonly used (or whatever). You can mention how he often gets muddled up with some tasks and say it is best to take the ones that are less intrinsic and shorter to complete.

You could say something like "I know you're ambitious, and this is great, but considering how you've been getting stuck on these tasks you should familiarize yourself with the simpler ones such as these first".

Answer 6

If you are having this issue, then the rest of the team will be having the same issue. I am curious as to why this isn't then escalated to the manager of the team, because there will obviously be some impact to the project progress as a result of the extra delays caused by the inefficiencies. Since it is a team environment, and people really need to work together harmoniously, this should be solved together as a team so that he also won't take it too personally. Worst case is that the person is not a right fit for the team (technically or socially) and that he may need to be removed (if nothing else works). But it is not really your issue to deal with, but the team leader/manager's issue, so make sure it is raised with the appropriate person(s).

Answer 7

Hopefully, the manager will deal with it, so be up front with this person about the position he has put everyone in when the manager asks for feedback. Let him know that you're not going to lie and these are the things I'm going to say.

Offer to help. If you think he has taken too big of a task, setup guidelines. Let him know that he can spend a short period of time on it and then show some progress or get off the task. Allow questions at a determined time. He is not allowed to just interupt. He has abused that privelage for some time.

If he is reluctant to pair program, you shouldn't expect it to work at first. He is going to resist and be difficult like a child. It will get worse before it will get better. You feel this is important, stick with it until he gets onboard or suffer the consequences. And there should be consequences.

Seems to me, everyone would be better off if he did nothing instead of all this counter-productive efforts. Even if he assigns himself to a task, put someone else on it as well. I just don't see what you have to lose. The boss will figure it out a lot sooner.