Handling non-team working, good programmers

Question

Let's say, you have a project and a very good team. The team leader is a very good programmer, with high professional performances, but without any team-playing competencies and with some non-conformist attitudes. For ex.

• arriving late to work, working in the nights (the management politics lets him do this, with having free program at the company). In this case the other members of the team have no possibility to collaborate with him
• the team has a big number of bug, but the team leader - being the best professional - takes the 85% of them.
• has an antisocial style

How should this situation be handled by the project management? Should the whole team adopt to the team leader's habits, the team leader should be moved somehow or both? I mention, that the project manager should take in consideration that the team leader is an antisocial and non-conformist person, with very good professional skills.

Answer 1

Interesting question. Before I could take action, I'd need to know two things (at least): 1. What is the impact on the project? 2. What are the duties of the team lead? What is the team lead accountable for?

90% of the PM's job is assessing the impact of an issue/risk/change/ on the project and communicating that impact to the relevant stakeholders. For example, the team lead setting his own working hours could have a negative effect on the project (limits collaboration), or it could have a positive effect on the project (greater productivity) (There is ample evidence that management endorsement of non-conformism significantly increases productivity). What is the real effect? Only after I know the impact on the project can I identify strategies to respond.

If the team lead is accountable for setting an example and a standard, then I've got no problem with his behavior. If the team lead is explicitly accountable for reducing bug count, implementing procedures to improve quality and training other programmers, then my response is to hold the team lead accountable for those behaviors. If the team lead is responsible for resolving bugs, then perhaps his practice of holding himself accountable for 85% of the bugs is effective? Is the team lead accountable for being social? (If so, why? How does social behavior lead to project closure?)

I suspect that the answer may be to discuss the quality improvement portion of the role with the team lead. Based on that discussion, either coach the team lead to a higher level of performance on that portion of his tasks, or reassign those tasks to someone better suited.

I'm very very skeptical of charges like "antisocial" and "nonconformist". The goal is to close the project successfully; if you can lead my project to closure, I don't care if you wear a plaid tutu and a tiara, discuss only Star Trek Voyager, and work only during prime numbered hours on alternate tuesdays. If you can't help me close my project, I don't care about your working hours or any other habit you have.

Answer 2

From your story it sounds like the current teamlead is not very good at being a teamlead and excels as a Senior Developer. I would suggest he is relieved of the task of coordinating work to his fellow developers and have the Project Manager appoint someone with more personal skills who will likely enjoy it more, ensure that the work this powerhouse leaves for the others is distributed evenly.

Other then that, I am curious where the huge amount of bugs are coming from. Is there a team of dedicated testers or are these findings from the developer-made automated tests or do they stem from user tests? Someone who is unable to share bug fixing has something to hide, I would like to know what it is.

Finally I would like to add that you seem to be very dependant on a prima-donna programmer who has little social skills. This in itself is a threat, who will maintain his code if he decides to leave, which he sooner or later will? You might add value now by having the other team members review and analyze his code to ensure they can work on it later.

If the lead-developer objects and/or gets angry at any of the above mentioned points, kick him off the team right away as he has no place in it.

Answer 3

I do agree with most of the presented, but believe would be interesting to think of the question from two different perspectives:

Short Term: The project, as it stands now, seems to be working fine. In despite of the team lead's lack of leadership, deliverables are flowing. If that's the case, keep things as they are, adjusting the rest of the team to fits into the top performer's behaviour IF REALLY REQUIRED.

Medium / Long term: Replace this person. Not from the development role, but from the leadership role. He's a great developer, and most of the great developers I know aren't good when talking with something that's not a compiler. Remember, however, that's also complicated to step down someone, so ideally this person could be moved to another environment (another project, for instance).

You must understand what the team and every member wants. Maybe the head developer only wants to work alone (out! out of my desk, now!); maybe there's another person dreaming about the leadership position; The easiest way to know is with a candid 1 to 1, but bear in mind that some people simple won't give you the tips.

Remember: No one is irreplaceable. You must avoid as much as you can to depend on one single person.

Answer 4

There are a couple of issues here where resolving one can exacerbate another. A high performing team requires individuals who can team. An individual who exhibits the behavior you describe is contraindicated if you have any hopes in furthering your team's maturity and performance. Putting such a character in the team lead role is nailing your coffin lid shut.

A high performing team is, as the name suggest, high performing: collective sense of success and failure, individual support and coverage, etc. It only takes one individual on a large team to destroy that.

On the other hand, there are certain types of jobs that attract certain types of personalities, i.e., certain jobs will have a prevailing personality type and behavior characteristics. Now, to be clear, I am not accusing that programmers have this type of behavior characteristic. I am, however, saying that there can be behavior and personality traits, like introversion that may be a prevailing personality type in this role, that can be interpreted as antisocial and anti-teaming by others.

It will be a balance between accepting some type of penalty to your teaming goals and working with the prevailing personality types you may have with the job role. As with most complex problems, no easy answer and no cookie cutter solution. You would be best served to understand the personality types so you can double check your interpretation of this person's behavior and assess how much risk you want to take with the teaming perspective. However, I think having him in a team lead role is probably not a good idea.