Part 2 of my reply to Dan Vacanti: following yesterday's post about gardeners, today I discuss those who simply won't do the job, those with a posture or attitude that makes them dysfunctional on the team.

It's easy to argue that the attitudinal is responsible for his own performance. He can choose to change his attitude and start to perform. Were this to happen his performance may well come up to or exceed that of the average team member. As a team, we'd certainly be able to factor his performance into our estimates. We could take him off the bench.

Team members with an attitude problem are usually not difficult to spot. They simply don't behave according to established team norms. For example, their attendance at the morning meeting is sporadic and when they do attend, they don't act like a functional team member. The body language (and sometimes the spoken language is all wrong). [Now it is true that there can be the fifth columnist who hides their dysfunction and let it manifest itself as poor quality code or very slow code production. This is harder to spot and requires intelligence from the grapevine - best gathered through the managing by taking coffee or managing by having lunch approach].

So, once again its the managers responsibility. The manager has to talk to the individual with the attitude. Make it plain to them why they need to change and that the manager will not tolerate it or bend the rules. There can be no exceptions. It's like parenting.

I've seen all sorts of attitudes. The most common perhaps is the "I'm God's gift to software engineering" often coupled to the complaint that "the team doesn't give me any of the cool stuff to work on". The advice: try doing the mundane stuff and doing a good job of it and earning the trust and respect of your peers. If you do the mundane stuff well and they learn to trust you then they will realize that you can help them to be successful and you will be given the harder, sexier tasks.

The second job is once again to take the attitudinal out of the estimate. Don't have the rest of the team carrying the burden. Treat them as bench slack or give them individual tasks to perform that are off the critical path of the deliverable. This has a side-effect. The attitudinal is isolated from the team and can never be integrated.

By maintaining a firm stance on expected norms, the attitudinal will either (a) change his attitude, earn the trust and respect of other team members and re-integrate as a functional team player, or (b) self-select out of the organization.

So, to Dan's point, I believe that the individual is responsible for their professionalism and their discipline, for their attitude towards their job, the business and their fellow team members. They can choose to work functionally with the team or they can strike a pose and behave like a spoiled toddler. But when it comes to writing code, they aren't responsible for their performance. That will always vary according to the techniques employed. Improving the techniques, reducing the variation and increasing the mid-point (or mean) productivity is the responsibility of the whole team and the manager. The team member simply has to agree to be a part of the learning organization. To strive to be professional and to show a willingness to learn.

I'm separating out productivity from dysfunction. When as managers, we couple the two together, we expect miracles. We expect that somehow magic will happen and the team will learn to use new techniques and become more productive with lower variation in productivity. But this can never happen on its own. The team will never take a risk to change because of the J-curve effect and general fear of change and feeling of insecurity whilst adopting new techniques. It needs the manager to give permission to change. To provide coaching and encouragement. To create a space and to provide air cover whilst the team works through the J-curve. By learning to treat dysfunction as a separate management problem, we free ourselves to focus on better productivity.