Mixing
How do I deal with a team member that keeps taking on tasks that he cannot solve?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
23
down vote
favorite
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.
colleagues team
asked Mar 13 '13 at 18:34
waxwing
21827
 |Â
show 5 more comments
up vote
23
down vote
favorite
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.
colleagues team
asked Mar 13 '13 at 18:34
waxwing
21827
14
This is of course why most companies don't let people pick what they want to do. It only works if everyone is really good and really responsible. Inteh real world that is not true.
– HLGEM
Mar 13 '13 at 18:46
2
Are you his manager?
– CincinnatiProgrammer
Mar 13 '13 at 18:46
No, I am not. We have the same title, but I have worked about five years longer at the company than he has. I was his mentor when he started and he does listen to me. He is almost never difficult or unfriendly.
– waxwing
Mar 13 '13 at 18:51
1
Break the problems into smaller pieces? Make him write design documents that will be collectively vetted? Send him back to school (kidding)?
– Deer Hunter
Mar 13 '13 at 18:56
2
Breaking the problem into smaller pieces is actually very good advice. It's often the developer who picks a task who is also responsible for breaking it into subtasks, so it would not be strange for me to suggest to him to subdivide it further if he gets stuck. The risk is that we end up with something half-finished, but that might be a more manageable situation.
– waxwing
Mar 13 '13 at 19:58
 |Â
show 5 more comments
up vote
23
down vote
favorite
up vote
23
down vote
favorite
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.
colleagues team
asked Mar 13 '13 at 18:34
waxwing
21827
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.
colleagues team
asked Mar 13 '13 at 18:34
waxwing
21827
edited Mar 18 '13 at 20:43
asked Mar 13 '13 at 18:34
waxwing
21827
asked Mar 13 '13 at 18:34
waxwing
21827
asked Mar 13 '13 at 18:34
waxwing
21827
21827
14
This is of course why most companies don't let people pick what they want to do. It only works if everyone is really good and really responsible. Inteh real world that is not true.
– HLGEM
Mar 13 '13 at 18:46
2
Are you his manager?
– CincinnatiProgrammer
Mar 13 '13 at 18:46
No, I am not. We have the same title, but I have worked about five years longer at the company than he has. I was his mentor when he started and he does listen to me. He is almost never difficult or unfriendly.
– waxwing
Mar 13 '13 at 18:51
1
Break the problems into smaller pieces? Make him write design documents that will be collectively vetted? Send him back to school (kidding)?
– Deer Hunter
Mar 13 '13 at 18:56
2
Breaking the problem into smaller pieces is actually very good advice. It's often the developer who picks a task who is also responsible for breaking it into subtasks, so it would not be strange for me to suggest to him to subdivide it further if he gets stuck. The risk is that we end up with something half-finished, but that might be a more manageable situation.
– waxwing
Mar 13 '13 at 19:58
 |Â
show 5 more comments
14
This is of course why most companies don't let people pick what they want to do. It only works if everyone is really good and really responsible. Inteh real world that is not true.
– HLGEM
Mar 13 '13 at 18:46
2
Are you his manager?
– CincinnatiProgrammer
Mar 13 '13 at 18:46
No, I am not. We have the same title, but I have worked about five years longer at the company than he has. I was his mentor when he started and he does listen to me. He is almost never difficult or unfriendly.
– waxwing
Mar 13 '13 at 18:51
1
Break the problems into smaller pieces? Make him write design documents that will be collectively vetted? Send him back to school (kidding)?
– Deer Hunter
Mar 13 '13 at 18:56
2
Breaking the problem into smaller pieces is actually very good advice. It's often the developer who picks a task who is also responsible for breaking it into subtasks, so it would not be strange for me to suggest to him to subdivide it further if he gets stuck. The risk is that we end up with something half-finished, but that might be a more manageable situation.
– waxwing
Mar 13 '13 at 19:58
14
14
This is of course why most companies don't let people pick what they want to do. It only works if everyone is really good and really responsible. Inteh real world that is not true.
– HLGEM
Mar 13 '13 at 18:46
This is of course why most companies don't let people pick what they want to do. It only works if everyone is really good and really responsible. Inteh real world that is not true.
– HLGEM
Mar 13 '13 at 18:46
2
2
Are you his manager?
– CincinnatiProgrammer
Mar 13 '13 at 18:46
Are you his manager?
– CincinnatiProgrammer
Mar 13 '13 at 18:46
No, I am not. We have the same title, but I have worked about five years longer at the company than he has. I was his mentor when he started and he does listen to me. He is almost never difficult or unfriendly.
– waxwing
Mar 13 '13 at 18:51
No, I am not. We have the same title, but I have worked about five years longer at the company than he has. I was his mentor when he started and he does listen to me. He is almost never difficult or unfriendly.
– waxwing
Mar 13 '13 at 18:51
1
1
Break the problems into smaller pieces? Make him write design documents that will be collectively vetted? Send him back to school (kidding)?
– Deer Hunter
Mar 13 '13 at 18:56
Break the problems into smaller pieces? Make him write design documents that will be collectively vetted? Send him back to school (kidding)?
– Deer Hunter
Mar 13 '13 at 18:56
2
2
Breaking the problem into smaller pieces is actually very good advice. It's often the developer who picks a task who is also responsible for breaking it into subtasks, so it would not be strange for me to suggest to him to subdivide it further if he gets stuck. The risk is that we end up with something half-finished, but that might be a more manageable situation.
– waxwing
Mar 13 '13 at 19:58
Breaking the problem into smaller pieces is actually very good advice. It's often the developer who picks a task who is also responsible for breaking it into subtasks, so it would not be strange for me to suggest to him to subdivide it further if he gets stuck. The risk is that we end up with something half-finished, but that might be a more manageable situation.
– waxwing
Mar 13 '13 at 19:58
 |Â
show 5 more comments
7 Answers
7
active
oldest
votes
up vote
15
down vote
accepted
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.
answered Mar 14 '13 at 15:08
jcmeloni
21.6k87393
Your analysis of the problem is spot-on: we are indeed starting to see that trust and respect within the team is starting to suffer. I'm hoping that he will not have to be let go, because I think it can be turned around and he can be reintegrated as a part of the team again if he started to focus on things he are good at.
– waxwing
Mar 18 '13 at 20:57
add a comment |Â
up vote
13
down vote
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.
answered Mar 13 '13 at 18:54
HLGEM
133k25227489
This would not be my first option, but you have a point. We need a barrier that prevent too inexperienced team members from just delving into whatever they feel like, even if it is with the best of intentions.
– waxwing
Mar 13 '13 at 20:07
1
I was going to comment and ask "who is the manager?" because this is why you have (presumably?) managers.
– Elysian Fields♦
Mar 13 '13 at 23:20
3
As an aside, "hundreds of years" is an overstatement as the current concept of management is a product of the industrial revolution and mass production, and probably less than 100 years old.
– jmac
Mar 13 '13 at 23:56
3
Well, masters ordering their apprentices about is quite old. And almost all management science eventually comes from the Army background, from Greek Hoplites and Roman Legionaries to Ghenghis Khan... Think we have to be thankful that the practice of decimation is not that fashionable.
– Deer Hunter
Mar 14 '13 at 3:46
2
Learning a skill (how to smith, how to farm, how to cobble) is very different from office work. At the end of the day, you learn how to make a shoe from a shoemaker in the former, and in the latter you do what the boss says regardless of whether it makes a shoe or a doughnut (even if you're supposed to make a shoe) because that's your job. The current concept of "management" is born in the factory where the end product is unclear, but the goal of getting from A to B is.
– jmac
Mar 14 '13 at 15:17
 |Â
show 2 more comments
up vote
10
down vote
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.
answered Mar 14 '13 at 0:23
jmac
19.4k763137
+1 for tackling the problem... and using headings while you were at it :-)
– KK.
Mar 17 '13 at 7:55
I think his main bad habit is that does not realize when he's heading in the wrong direction and is developing something that won't work. Early involvement is good but does not always work. Even if we discuss the problem in the start, the lined out solution can turn out to be incorrect, as we didn't understand the entire problem. Then it feels like I made matters worse.
– waxwing
Mar 18 '13 at 20:27
Don't get me wrong though, you have some really good points that I Will try to remember when I need them. :)
– waxwing
Mar 18 '13 at 20:37
Perhaps I'm a lowly mortal, but generally when doing creative work trying to find a constructive problem, I try things that end up not working too. I tend to call this process of failure and success "learning".
– jmac
Mar 18 '13 at 23:02
Upvoted. Hopefully, the OP has daily standup meetings where any roadblocks can be voiced. If not, the developer in question may not feel as though he has an outlet for the issues.
– lunchmeat317
Mar 20 '13 at 20:52
add a comment |Â
up vote
5
down vote
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.
answered Mar 13 '13 at 19:00
user2166929
511
I think he's aware of the problems he's causing, but it's conflicting with his drive to prove himself. I have told him before starting a task that he should "read up on technology X", but that didn't help. I feel like for this to work I need to come up with something more concrete to tell him. Not bad advice though!
– waxwing
Mar 13 '13 at 19:44
add a comment |Â
up vote
4
down vote
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".
It's a good idea but I am worried that I cannot constantly watch everything he does. Often we don't realize it's a problem before it's already too late. I really like your examples on phrasing though!
– waxwing
Mar 13 '13 at 19:53
Managing who does what work is really the job of the manager. Have you brought up your concerns with him?
– user8119
Mar 13 '13 at 21:02
Not yet. I'm going to have a personal meeting with my manager tomorrow. That's why I asked the question, to get ideas on how to tackle what I perceive as a problem.
– waxwing
Mar 14 '13 at 8:02
add a comment |Â
up vote
2
down vote
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).
answered Mar 13 '13 at 23:09
Michael Lai
8131820
add a comment |Â
up vote
2
down vote
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.
add a comment |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
7 Answers
7
active
oldest
votes
7 Answers
7
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
15
down vote
accepted
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.
answered Mar 14 '13 at 15:08
jcmeloni
21.6k87393
Your analysis of the problem is spot-on: we are indeed starting to see that trust and respect within the team is starting to suffer. I'm hoping that he will not have to be let go, because I think it can be turned around and he can be reintegrated as a part of the team again if he started to focus on things he are good at.
– waxwing
Mar 18 '13 at 20:57
add a comment |Â
up vote
15
down vote
accepted
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.
answered Mar 14 '13 at 15:08
jcmeloni
21.6k87393
Your analysis of the problem is spot-on: we are indeed starting to see that trust and respect within the team is starting to suffer. I'm hoping that he will not have to be let go, because I think it can be turned around and he can be reintegrated as a part of the team again if he started to focus on things he are good at.
– waxwing
Mar 18 '13 at 20:57
add a comment |Â
up vote
15
down vote
accepted
up vote
15
down vote
accepted
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.
answered Mar 14 '13 at 15:08
jcmeloni
21.6k87393
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.
answered Mar 14 '13 at 15:08
jcmeloni
21.6k87393
edited Mar 14 '13 at 16:25
answered Mar 14 '13 at 15:08
jcmeloni
21.6k87393
answered Mar 14 '13 at 15:08
jcmeloni
21.6k87393
answered Mar 14 '13 at 15:08
jcmeloni
21.6k87393
21.6k87393
Your analysis of the problem is spot-on: we are indeed starting to see that trust and respect within the team is starting to suffer. I'm hoping that he will not have to be let go, because I think it can be turned around and he can be reintegrated as a part of the team again if he started to focus on things he are good at.
– waxwing
Mar 18 '13 at 20:57
add a comment |Â
Your analysis of the problem is spot-on: we are indeed starting to see that trust and respect within the team is starting to suffer. I'm hoping that he will not have to be let go, because I think it can be turned around and he can be reintegrated as a part of the team again if he started to focus on things he are good at.
– waxwing
Mar 18 '13 at 20:57
Your analysis of the problem is spot-on: we are indeed starting to see that trust and respect within the team is starting to suffer. I'm hoping that he will not have to be let go, because I think it can be turned around and he can be reintegrated as a part of the team again if he started to focus on things he are good at.
– waxwing
Mar 18 '13 at 20:57
Your analysis of the problem is spot-on: we are indeed starting to see that trust and respect within the team is starting to suffer. I'm hoping that he will not have to be let go, because I think it can be turned around and he can be reintegrated as a part of the team again if he started to focus on things he are good at.
– waxwing
Mar 18 '13 at 20:57
add a comment |Â
up vote
13
down vote
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.
answered Mar 13 '13 at 18:54
HLGEM
133k25227489
This would not be my first option, but you have a point. We need a barrier that prevent too inexperienced team members from just delving into whatever they feel like, even if it is with the best of intentions.
– waxwing
Mar 13 '13 at 20:07
1
I was going to comment and ask "who is the manager?" because this is why you have (presumably?) managers.
– Elysian Fields♦
Mar 13 '13 at 23:20
3
As an aside, "hundreds of years" is an overstatement as the current concept of management is a product of the industrial revolution and mass production, and probably less than 100 years old.
– jmac
Mar 13 '13 at 23:56
3
Well, masters ordering their apprentices about is quite old. And almost all management science eventually comes from the Army background, from Greek Hoplites and Roman Legionaries to Ghenghis Khan... Think we have to be thankful that the practice of decimation is not that fashionable.
– Deer Hunter
Mar 14 '13 at 3:46
2
Learning a skill (how to smith, how to farm, how to cobble) is very different from office work. At the end of the day, you learn how to make a shoe from a shoemaker in the former, and in the latter you do what the boss says regardless of whether it makes a shoe or a doughnut (even if you're supposed to make a shoe) because that's your job. The current concept of "management" is born in the factory where the end product is unclear, but the goal of getting from A to B is.
– jmac
Mar 14 '13 at 15:17
 |Â
show 2 more comments
up vote
13
down vote
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.
answered Mar 13 '13 at 18:54
HLGEM
133k25227489
This would not be my first option, but you have a point. We need a barrier that prevent too inexperienced team members from just delving into whatever they feel like, even if it is with the best of intentions.
– waxwing
Mar 13 '13 at 20:07
1
I was going to comment and ask "who is the manager?" because this is why you have (presumably?) managers.
– Elysian Fields♦
Mar 13 '13 at 23:20
3
As an aside, "hundreds of years" is an overstatement as the current concept of management is a product of the industrial revolution and mass production, and probably less than 100 years old.
– jmac
Mar 13 '13 at 23:56
3
Well, masters ordering their apprentices about is quite old. And almost all management science eventually comes from the Army background, from Greek Hoplites and Roman Legionaries to Ghenghis Khan... Think we have to be thankful that the practice of decimation is not that fashionable.
– Deer Hunter
Mar 14 '13 at 3:46
2
Learning a skill (how to smith, how to farm, how to cobble) is very different from office work. At the end of the day, you learn how to make a shoe from a shoemaker in the former, and in the latter you do what the boss says regardless of whether it makes a shoe or a doughnut (even if you're supposed to make a shoe) because that's your job. The current concept of "management" is born in the factory where the end product is unclear, but the goal of getting from A to B is.
– jmac
Mar 14 '13 at 15:17
 |Â
show 2 more comments
up vote
13
down vote
up vote
13
down vote
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.
answered Mar 13 '13 at 18:54
HLGEM
133k25227489
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.
answered Mar 13 '13 at 18:54
HLGEM
133k25227489
answered Mar 13 '13 at 18:54
HLGEM
133k25227489
answered Mar 13 '13 at 18:54
HLGEM
133k25227489
answered Mar 13 '13 at 18:54
HLGEM
133k25227489
133k25227489
This would not be my first option, but you have a point. We need a barrier that prevent too inexperienced team members from just delving into whatever they feel like, even if it is with the best of intentions.
– waxwing
Mar 13 '13 at 20:07
1
I was going to comment and ask "who is the manager?" because this is why you have (presumably?) managers.
– Elysian Fields♦
Mar 13 '13 at 23:20
3
As an aside, "hundreds of years" is an overstatement as the current concept of management is a product of the industrial revolution and mass production, and probably less than 100 years old.
– jmac
Mar 13 '13 at 23:56
3
Well, masters ordering their apprentices about is quite old. And almost all management science eventually comes from the Army background, from Greek Hoplites and Roman Legionaries to Ghenghis Khan... Think we have to be thankful that the practice of decimation is not that fashionable.
– Deer Hunter
Mar 14 '13 at 3:46
2
Learning a skill (how to smith, how to farm, how to cobble) is very different from office work. At the end of the day, you learn how to make a shoe from a shoemaker in the former, and in the latter you do what the boss says regardless of whether it makes a shoe or a doughnut (even if you're supposed to make a shoe) because that's your job. The current concept of "management" is born in the factory where the end product is unclear, but the goal of getting from A to B is.
– jmac
Mar 14 '13 at 15:17
 |Â
show 2 more comments
This would not be my first option, but you have a point. We need a barrier that prevent too inexperienced team members from just delving into whatever they feel like, even if it is with the best of intentions.
– waxwing
Mar 13 '13 at 20:07
1
I was going to comment and ask "who is the manager?" because this is why you have (presumably?) managers.
– Elysian Fields♦
Mar 13 '13 at 23:20
3
As an aside, "hundreds of years" is an overstatement as the current concept of management is a product of the industrial revolution and mass production, and probably less than 100 years old.
– jmac
Mar 13 '13 at 23:56
3
Well, masters ordering their apprentices about is quite old. And almost all management science eventually comes from the Army background, from Greek Hoplites and Roman Legionaries to Ghenghis Khan... Think we have to be thankful that the practice of decimation is not that fashionable.
– Deer Hunter
Mar 14 '13 at 3:46
2
Learning a skill (how to smith, how to farm, how to cobble) is very different from office work. At the end of the day, you learn how to make a shoe from a shoemaker in the former, and in the latter you do what the boss says regardless of whether it makes a shoe or a doughnut (even if you're supposed to make a shoe) because that's your job. The current concept of "management" is born in the factory where the end product is unclear, but the goal of getting from A to B is.
– jmac
Mar 14 '13 at 15:17
This would not be my first option, but you have a point. We need a barrier that prevent too inexperienced team members from just delving into whatever they feel like, even if it is with the best of intentions.
– waxwing
Mar 13 '13 at 20:07
This would not be my first option, but you have a point. We need a barrier that prevent too inexperienced team members from just delving into whatever they feel like, even if it is with the best of intentions.
– waxwing
Mar 13 '13 at 20:07
1
1
I was going to comment and ask "who is the manager?" because this is why you have (presumably?) managers.
– Elysian Fields♦
Mar 13 '13 at 23:20
I was going to comment and ask "who is the manager?" because this is why you have (presumably?) managers.
– Elysian Fields♦
Mar 13 '13 at 23:20
3
3
As an aside, "hundreds of years" is an overstatement as the current concept of management is a product of the industrial revolution and mass production, and probably less than 100 years old.
– jmac
Mar 13 '13 at 23:56
As an aside, "hundreds of years" is an overstatement as the current concept of management is a product of the industrial revolution and mass production, and probably less than 100 years old.
– jmac
Mar 13 '13 at 23:56
3
3
Well, masters ordering their apprentices about is quite old. And almost all management science eventually comes from the Army background, from Greek Hoplites and Roman Legionaries to Ghenghis Khan... Think we have to be thankful that the practice of decimation is not that fashionable.
– Deer Hunter
Mar 14 '13 at 3:46
Well, masters ordering their apprentices about is quite old. And almost all management science eventually comes from the Army background, from Greek Hoplites and Roman Legionaries to Ghenghis Khan... Think we have to be thankful that the practice of decimation is not that fashionable.
– Deer Hunter
Mar 14 '13 at 3:46
2
2
Learning a skill (how to smith, how to farm, how to cobble) is very different from office work. At the end of the day, you learn how to make a shoe from a shoemaker in the former, and in the latter you do what the boss says regardless of whether it makes a shoe or a doughnut (even if you're supposed to make a shoe) because that's your job. The current concept of "management" is born in the factory where the end product is unclear, but the goal of getting from A to B is.
– jmac
Mar 14 '13 at 15:17
Learning a skill (how to smith, how to farm, how to cobble) is very different from office work. At the end of the day, you learn how to make a shoe from a shoemaker in the former, and in the latter you do what the boss says regardless of whether it makes a shoe or a doughnut (even if you're supposed to make a shoe) because that's your job. The current concept of "management" is born in the factory where the end product is unclear, but the goal of getting from A to B is.
– jmac
Mar 14 '13 at 15:17
 |Â
show 2 more comments
up vote
10
down vote
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.
answered Mar 14 '13 at 0:23
jmac
19.4k763137
+1 for tackling the problem... and using headings while you were at it :-)
– KK.
Mar 17 '13 at 7:55
I think his main bad habit is that does not realize when he's heading in the wrong direction and is developing something that won't work. Early involvement is good but does not always work. Even if we discuss the problem in the start, the lined out solution can turn out to be incorrect, as we didn't understand the entire problem. Then it feels like I made matters worse.
– waxwing
Mar 18 '13 at 20:27
Don't get me wrong though, you have some really good points that I Will try to remember when I need them. :)
– waxwing
Mar 18 '13 at 20:37
Perhaps I'm a lowly mortal, but generally when doing creative work trying to find a constructive problem, I try things that end up not working too. I tend to call this process of failure and success "learning".
– jmac
Mar 18 '13 at 23:02
Upvoted. Hopefully, the OP has daily standup meetings where any roadblocks can be voiced. If not, the developer in question may not feel as though he has an outlet for the issues.
– lunchmeat317
Mar 20 '13 at 20:52
add a comment |Â
up vote
10
down vote
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.
answered Mar 14 '13 at 0:23
jmac
19.4k763137
+1 for tackling the problem... and using headings while you were at it :-)
– KK.
Mar 17 '13 at 7:55
I think his main bad habit is that does not realize when he's heading in the wrong direction and is developing something that won't work. Early involvement is good but does not always work. Even if we discuss the problem in the start, the lined out solution can turn out to be incorrect, as we didn't understand the entire problem. Then it feels like I made matters worse.
– waxwing
Mar 18 '13 at 20:27
Don't get me wrong though, you have some really good points that I Will try to remember when I need them. :)
– waxwing
Mar 18 '13 at 20:37
Perhaps I'm a lowly mortal, but generally when doing creative work trying to find a constructive problem, I try things that end up not working too. I tend to call this process of failure and success "learning".
– jmac
Mar 18 '13 at 23:02
Upvoted. Hopefully, the OP has daily standup meetings where any roadblocks can be voiced. If not, the developer in question may not feel as though he has an outlet for the issues.
– lunchmeat317
Mar 20 '13 at 20:52
add a comment |Â
up vote
10
down vote
up vote
10
down vote
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.
answered Mar 14 '13 at 0:23
jmac
19.4k763137
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.
answered Mar 14 '13 at 0:23
jmac
19.4k763137
answered Mar 14 '13 at 0:23
jmac
19.4k763137
answered Mar 14 '13 at 0:23
jmac
19.4k763137
answered Mar 14 '13 at 0:23
jmac
19.4k763137
19.4k763137
+1 for tackling the problem... and using headings while you were at it :-)
– KK.
Mar 17 '13 at 7:55
I think his main bad habit is that does not realize when he's heading in the wrong direction and is developing something that won't work. Early involvement is good but does not always work. Even if we discuss the problem in the start, the lined out solution can turn out to be incorrect, as we didn't understand the entire problem. Then it feels like I made matters worse.
– waxwing
Mar 18 '13 at 20:27
Don't get me wrong though, you have some really good points that I Will try to remember when I need them. :)
– waxwing
Mar 18 '13 at 20:37
Perhaps I'm a lowly mortal, but generally when doing creative work trying to find a constructive problem, I try things that end up not working too. I tend to call this process of failure and success "learning".
– jmac
Mar 18 '13 at 23:02
Upvoted. Hopefully, the OP has daily standup meetings where any roadblocks can be voiced. If not, the developer in question may not feel as though he has an outlet for the issues.
– lunchmeat317
Mar 20 '13 at 20:52
add a comment |Â
+1 for tackling the problem... and using headings while you were at it :-)
– KK.
Mar 17 '13 at 7:55
I think his main bad habit is that does not realize when he's heading in the wrong direction and is developing something that won't work. Early involvement is good but does not always work. Even if we discuss the problem in the start, the lined out solution can turn out to be incorrect, as we didn't understand the entire problem. Then it feels like I made matters worse.
– waxwing
Mar 18 '13 at 20:27
Don't get me wrong though, you have some really good points that I Will try to remember when I need them. :)
– waxwing
Mar 18 '13 at 20:37
Perhaps I'm a lowly mortal, but generally when doing creative work trying to find a constructive problem, I try things that end up not working too. I tend to call this process of failure and success "learning".
– jmac
Mar 18 '13 at 23:02
Upvoted. Hopefully, the OP has daily standup meetings where any roadblocks can be voiced. If not, the developer in question may not feel as though he has an outlet for the issues.
– lunchmeat317
Mar 20 '13 at 20:52
+1 for tackling the problem... and using headings while you were at it :-)
– KK.
Mar 17 '13 at 7:55
+1 for tackling the problem... and using headings while you were at it :-)
– KK.
Mar 17 '13 at 7:55
I think his main bad habit is that does not realize when he's heading in the wrong direction and is developing something that won't work. Early involvement is good but does not always work. Even if we discuss the problem in the start, the lined out solution can turn out to be incorrect, as we didn't understand the entire problem. Then it feels like I made matters worse.
– waxwing
Mar 18 '13 at 20:27
I think his main bad habit is that does not realize when he's heading in the wrong direction and is developing something that won't work. Early involvement is good but does not always work. Even if we discuss the problem in the start, the lined out solution can turn out to be incorrect, as we didn't understand the entire problem. Then it feels like I made matters worse.
– waxwing
Mar 18 '13 at 20:27
Don't get me wrong though, you have some really good points that I Will try to remember when I need them. :)
– waxwing
Mar 18 '13 at 20:37
Don't get me wrong though, you have some really good points that I Will try to remember when I need them. :)
– waxwing
Mar 18 '13 at 20:37
Perhaps I'm a lowly mortal, but generally when doing creative work trying to find a constructive problem, I try things that end up not working too. I tend to call this process of failure and success "learning".
– jmac
Mar 18 '13 at 23:02
Perhaps I'm a lowly mortal, but generally when doing creative work trying to find a constructive problem, I try things that end up not working too. I tend to call this process of failure and success "learning".
– jmac
Mar 18 '13 at 23:02
Upvoted. Hopefully, the OP has daily standup meetings where any roadblocks can be voiced. If not, the developer in question may not feel as though he has an outlet for the issues.
– lunchmeat317
Mar 20 '13 at 20:52
Upvoted. Hopefully, the OP has daily standup meetings where any roadblocks can be voiced. If not, the developer in question may not feel as though he has an outlet for the issues.
– lunchmeat317
Mar 20 '13 at 20:52
add a comment |Â
up vote
5
down vote
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.
answered Mar 13 '13 at 19:00
user2166929
511
I think he's aware of the problems he's causing, but it's conflicting with his drive to prove himself. I have told him before starting a task that he should "read up on technology X", but that didn't help. I feel like for this to work I need to come up with something more concrete to tell him. Not bad advice though!
– waxwing
Mar 13 '13 at 19:44
add a comment |Â
up vote
5
down vote
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.
answered Mar 13 '13 at 19:00
user2166929
511
I think he's aware of the problems he's causing, but it's conflicting with his drive to prove himself. I have told him before starting a task that he should "read up on technology X", but that didn't help. I feel like for this to work I need to come up with something more concrete to tell him. Not bad advice though!
– waxwing
Mar 13 '13 at 19:44
add a comment |Â
up vote
5
down vote
up vote
5
down vote
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.
answered Mar 13 '13 at 19:00
user2166929
511
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.
answered Mar 13 '13 at 19:00
user2166929
511
answered Mar 13 '13 at 19:00
user2166929
511
answered Mar 13 '13 at 19:00
user2166929
511
answered Mar 13 '13 at 19:00
user2166929
511
511
I think he's aware of the problems he's causing, but it's conflicting with his drive to prove himself. I have told him before starting a task that he should "read up on technology X", but that didn't help. I feel like for this to work I need to come up with something more concrete to tell him. Not bad advice though!
– waxwing
Mar 13 '13 at 19:44
add a comment |Â
I think he's aware of the problems he's causing, but it's conflicting with his drive to prove himself. I have told him before starting a task that he should "read up on technology X", but that didn't help. I feel like for this to work I need to come up with something more concrete to tell him. Not bad advice though!
– waxwing
Mar 13 '13 at 19:44
I think he's aware of the problems he's causing, but it's conflicting with his drive to prove himself. I have told him before starting a task that he should "read up on technology X", but that didn't help. I feel like for this to work I need to come up with something more concrete to tell him. Not bad advice though!
– waxwing
Mar 13 '13 at 19:44
I think he's aware of the problems he's causing, but it's conflicting with his drive to prove himself. I have told him before starting a task that he should "read up on technology X", but that didn't help. I feel like for this to work I need to come up with something more concrete to tell him. Not bad advice though!
– waxwing
Mar 13 '13 at 19:44
add a comment |Â
up vote
4
down vote
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".
It's a good idea but I am worried that I cannot constantly watch everything he does. Often we don't realize it's a problem before it's already too late. I really like your examples on phrasing though!
– waxwing
Mar 13 '13 at 19:53
Managing who does what work is really the job of the manager. Have you brought up your concerns with him?
– user8119
Mar 13 '13 at 21:02
Not yet. I'm going to have a personal meeting with my manager tomorrow. That's why I asked the question, to get ideas on how to tackle what I perceive as a problem.
– waxwing
Mar 14 '13 at 8:02
add a comment |Â
up vote
4
down vote
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".
It's a good idea but I am worried that I cannot constantly watch everything he does. Often we don't realize it's a problem before it's already too late. I really like your examples on phrasing though!
– waxwing
Mar 13 '13 at 19:53
Managing who does what work is really the job of the manager. Have you brought up your concerns with him?
– user8119
Mar 13 '13 at 21:02
Not yet. I'm going to have a personal meeting with my manager tomorrow. That's why I asked the question, to get ideas on how to tackle what I perceive as a problem.
– waxwing
Mar 14 '13 at 8:02
add a comment |Â
up vote
4
down vote
up vote
4
down vote
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".
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".
answered Mar 13 '13 at 18:59
user8119
It's a good idea but I am worried that I cannot constantly watch everything he does. Often we don't realize it's a problem before it's already too late. I really like your examples on phrasing though!
– waxwing
Mar 13 '13 at 19:53
Managing who does what work is really the job of the manager. Have you brought up your concerns with him?
– user8119
Mar 13 '13 at 21:02
Not yet. I'm going to have a personal meeting with my manager tomorrow. That's why I asked the question, to get ideas on how to tackle what I perceive as a problem.
– waxwing
Mar 14 '13 at 8:02
add a comment |Â
It's a good idea but I am worried that I cannot constantly watch everything he does. Often we don't realize it's a problem before it's already too late. I really like your examples on phrasing though!
– waxwing
Mar 13 '13 at 19:53
Managing who does what work is really the job of the manager. Have you brought up your concerns with him?
– user8119
Mar 13 '13 at 21:02
Not yet. I'm going to have a personal meeting with my manager tomorrow. That's why I asked the question, to get ideas on how to tackle what I perceive as a problem.
– waxwing
Mar 14 '13 at 8:02
It's a good idea but I am worried that I cannot constantly watch everything he does. Often we don't realize it's a problem before it's already too late. I really like your examples on phrasing though!
– waxwing
Mar 13 '13 at 19:53
It's a good idea but I am worried that I cannot constantly watch everything he does. Often we don't realize it's a problem before it's already too late. I really like your examples on phrasing though!
– waxwing
Mar 13 '13 at 19:53
Managing who does what work is really the job of the manager. Have you brought up your concerns with him?
– user8119
Mar 13 '13 at 21:02
Managing who does what work is really the job of the manager. Have you brought up your concerns with him?
– user8119
Mar 13 '13 at 21:02
Not yet. I'm going to have a personal meeting with my manager tomorrow. That's why I asked the question, to get ideas on how to tackle what I perceive as a problem.
– waxwing
Mar 14 '13 at 8:02
Not yet. I'm going to have a personal meeting with my manager tomorrow. That's why I asked the question, to get ideas on how to tackle what I perceive as a problem.
– waxwing
Mar 14 '13 at 8:02
add a comment |Â
up vote
2
down vote
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).
answered Mar 13 '13 at 23:09
Michael Lai
8131820
add a comment |Â
up vote
2
down vote
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).
answered Mar 13 '13 at 23:09
Michael Lai
8131820
add a comment |Â
up vote
2
down vote
up vote
2
down vote
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).
answered Mar 13 '13 at 23:09
Michael Lai
8131820
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).
answered Mar 13 '13 at 23:09
Michael Lai
8131820
answered Mar 13 '13 at 23:09
Michael Lai
8131820
answered Mar 13 '13 at 23:09
Michael Lai
8131820
answered Mar 13 '13 at 23:09
Michael Lai
8131820
8131820
add a comment |Â
add a comment |Â
up vote
2
down vote
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.
add a comment |Â
up vote
2
down vote
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.
add a comment |Â
up vote
2
down vote
up vote
2
down vote
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.
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.
answered Mar 14 '13 at 18:06
user8365
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f10249%2fhow-do-i-deal-with-a-team-member-that-keeps-taking-on-tasks-that-he-cannot-solve%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
14
This is of course why most companies don't let people pick what they want to do. It only works if everyone is really good and really responsible. Inteh real world that is not true.
– HLGEM
Mar 13 '13 at 18:46
2
Are you his manager?
– CincinnatiProgrammer
Mar 13 '13 at 18:46
No, I am not. We have the same title, but I have worked about five years longer at the company than he has. I was his mentor when he started and he does listen to me. He is almost never difficult or unfriendly.
– waxwing
Mar 13 '13 at 18:51
1
Break the problems into smaller pieces? Make him write design documents that will be collectively vetted? Send him back to school (kidding)?
– Deer Hunter
Mar 13 '13 at 18:56
2
Breaking the problem into smaller pieces is actually very good advice. It's often the developer who picks a task who is also responsible for breaking it into subtasks, so it would not be strange for me to suggest to him to subdivide it further if he gets stuck. The risk is that we end up with something half-finished, but that might be a more manageable situation.
– waxwing
Mar 13 '13 at 19:58