In the end, even if it doesn't work out someone should have the decency to explain exactly what the problem is. Alienating him to get him out of the group is a pretty dick move.

That being said, booting off the person may not be the best course. He has to be good at something or this would have come up sooner right? Leverage his strengths if you can. If your manager is competent, have him address the individual in the context of self-improvement. This can be a great way to re-motivate someone or send a signal that things are not working out.

In any case, act soon and with tact. The last thing you want is an angry and incompetent person on your team.

Talk to his manager behind closed doors. Be reasonable. Provide data. Metrics can be misleading, but if you have them, now is the time. (I recall one coworker at a job, when we looked, had done 12 CVS checkins during a given period where the average was close to 100 and the next lowest was in the 30s, or something like that. Illustrative!)

I have seen people improve if someone lights a fire under them! That's his manager's job. More often this doesn't happen, but it's not uncommon for the chastised person to start job-hunting and solve the issue fairly quickly anyway.

I wouldn't confront him directly unless you are his manager. If you are, talk to him ASAP. Set up a plan with measurable deliverables, and make it clear that he'll either make the goals or be asked to leave.

Little is as bad for morale as the crappy employee that drags everyone down and isn't fired. Good managers understand this.

If the company doesn't care, it's just a matter of time before more bad employees sneak in, and like a cancer the good employees start slacking off more (because why not? The idiots are never fired!) and you don't have a fulfilling job anymore. So, that's when you dust off the resume yourself.

Good luck!

You are describing what a manager is supposed to do. And you don't give enough details to diagnose the situation. I've seen coworkers who seriously had ADD (and were on enough prescription meds that their pill jar looked like a bowl of skittles), and I've seen coworkers who've had problems at home.

The guy with ADD couldn't see the 10000 ft view if you hit him on the head with it because ... ooh, look, shiny! He had to be micromanaged because his own steering mechanism was faulty.

May I recommend that you read Dynamics of Software Development? Because it sounds a lot like you want to flip the bozo bit over there. http://www.amazon.com/Dynamics-Software-Development-Jim-McCa...

(I recall one coworker at a job, when we looked, had done 12 CVS checkins during a given period where the average was close to 100 and the next lowest was in the 30s, or something like that. Illustrative!)

Not a good example. Number of commits is an n-th level approximation to measuring productivity. As an example from my own life recently, I just finished doing a massive refactor on a rather integral part of my current employer's website.

Due to the bad shape this module was in, any change I made to it would result in a broken program until I had done a considerable amount more refactoring both within the module, and all the other places it was tightly coupled within the code. The philosophy of "if it works, don't fuck with it" didn't apply here, because it didn't work when it was thrown my way, and it was almost indecipherable as well. So I set to work refactoring, more to decipher the code than to fix the problem; it was impossible to keep enough of a logical model of it in my head to reason through the misbehavor. Every time I changed something, 3 other things would break, making building the mental model I needed even harder.

For a number of weeks, I had something non-functioning, and something that would be completely worthless if committed into repository (I was backing it up elsewhere at the time). The best these commits would've been is the SCM version of status reports of a system without cohesion, which would have been a complete waste of everyone's time.

To be clear, I am absolutely against monolithic refactorings about 99% of the time, and I did a tremendous amount of soul-searching through all of this. I worried that I was making this far more difficult than I needed to make it, that there were smaller changes than I was making that would allow everything to work out. But every time I'd try to find a easier way out, I'd hit a point where I found such tight coupling that changing one thing would necessitate 20 changes elsewhere, and things would cascade from there.

When I got to a point where it started functioning again, I committed all the changes in at that point. One commit, but a lot of lines of code, and even more deep thinking went into this work. At this point, I am now committing more frequently, as the remaining issues are worked out of the rewrite.

I guess the moral of the story here is: don't just focus on the number of commits, focus on what went into them. If these 12 commits were on par effort-wise with the 30 commits on average of everyone else, something is wrong; otherwise, the guy hitting 12 commits might just have deeper, more difficult work to do.

It can be useful to drive home what you already know, but not really to discover information.

At a functional software house, it's largely obvious to _everyone_ exactly how much work everyone else does. Think about your coworkers - do you know which ones are good and which are dead weight? I bet you do!

The situation will not get better by itself.

I'd first try to get the group to condense the 10,000-feet view into a single document, including priorities, and get the group to agree on it (presenting it as a 'helpful reference').

Then you'd have an easier time saying, "Hey Bill, whatcha working on?" "I'm really bogged down with <task>." "Huh, is <task> really that important based on the priorities in <document>?"

If "no": "Awesome, slash it and move on, dude. What's your next task?"

If "yes": "Huh. I'll talk with some of the others, see if they agree or if you can drop this and move on to something easier."

They might shed some more light on the situation. Hypothetically: "Oh, yeah, Joe's a great guy, but you're right. He doesn't really get the 10,0000ft view of things. He mentioned to me the other week that it hasn't really been explained to him clearly, so he just focuses on the task at hand. He doesn't get all of that business stuff either, and really doesn't want to embarrass himself by admitting it."

----------

His motivations, and incentives to work, might be different than you think too. Usually you really have to get to know someone, both at work and in their personal life, to truly understand what drives them. Money isn't always everything.

Maybe he's offloading work to other teammates so he can work on his startup instead, on the job! ;)

----------

But as others have said, it's great that you're friends! :) Talk to him about it in a non-threatening way (I know that's tricky sometimes). Ask him how he feels about things.

If you do the "we're going to have a manager/employee review" thing, and it comes off negatively from his perspective, that'll probably scare him. When people are scared they can become unpredictable.

He might start working harder, he might start looking for another job, he might complain to HR and fight back, etc... That all depends on the person.

Some sort of non-confrontational approach usually works best IMHO.

----------

Best of luck to you!

That said, you really should verify that he is the one who is incompetent. Pointing the finger at others has also been a clue that a given person isn't really a good person for a team.

The point about finding something he can do seems good. If someone knows they aren't good at difficult problems, it can work well since you can give them "grunt work" and they might be useful.

But really, the most damaging thing isn't someone's degree of incompetence but their exaggerated idea of their competence. If other people helping him is the worst effect this person has, he is low on my scale of damaging co-workers.

Exactly. The only more damaging person is someone who is openly poisonous and negative. The two in conjunction are a misery to everyone around them.

Blunder Twin Powers, Activate!

If you mean he is perfecting an aspect of the code that isn't important, that is a notorious engineer/Asperger's problem, which is a great strength when properly directed.

It's hard for me to believe that a software developer would have no empathy for this character flaw, so maybe that's not what you meant.

If you are the leader, its your job to get him working correctly or get him out. If you are not the leader -- ie you are his equal, its a little harder to go about, and it depends on his, the team, and the leaders personalities and operating style. There is no hard and fast rule.

But you should do something instead of being pissed off, certainly.

In my situations, I 'cope with incompetent team members' by firing them. But that is not always such an easy prospect if you are actually friends with this person, or you arent the boss. If you care more for the friendship than the job/project, then tell him what you think and help him yourself to get over it.