Posted by Sam on Jul 23, 2008 at 06:43 AM UTC - 6 hrs
Aside: It was tempting to satisfy my desire to entitle a blog post using two clichéd proverbs and an OrColon: Subtitle, but I refrained from calling this "Bad Apples Don't Always Spoil The Bunch, Or: Don't Throw The Baby Out With The Bathwater." I also could have used the subtitle, "Or: A Four Course Meal To Avoiding Disaster On Your Team." Such titles are great for posting to reddit/programming, but I've had enough cheese today on my pizza.
However, so that I don't neglect the cheese lovers among us who have a craving for the moldy substance, I'll tide you over with this morsel:
Mmmmmmm...
Appetizer entertainment from The Osmond's aside, we can get to the salad plate of our four course meal: Jeff Atwood wrote a blog post about Dealing With Bad Apples where he quotes some of Steve McConnell's work:
If you tolerate even one developer whom the other developers think is a problem, you'll hurt the morale of the good developers. You are implying that not only do you expect your team members to give their all; you expect them to do it when their co-workers are working against them.
He goes on to quote McConnell's reporting of the data (something valuable McConnell always offers):
In a review of 32 management teams, Larson and LaFasto found that the most consistent and intense complaint from team members was that their team leaders were unwilling to confront and resolve problems associated with poor performance by individual team members. (Larson and LaFasto 1989).
All of that is to say: software developers with bad attitudes should not be tolerated for long, lest they destroy the team from the inside.
He continues, citing ways in which to identify miscreants on your team, finally concluding that
You should never be afraid to remove -- or even fire -- people who do not have the best interests of the team at heart. You can develop skill, but you can't develop a positive attitude. The longer these disruptive personalities stick around on a project, the worse their effects get. They'll slowly spread poison throughout your project, in the form of code, relationships, and contacts.
There's nothing too striking here. In fact, I didn't think twice about it until I read Brian Cunningham's response:
I agree with this wholeheartedly. But you also have to ask yourself whether there's something you could have done to prevent things from getting to this point.
...
Whenever a bad apple is discovered on your team, you should always consider the possibility that it could have been prevented. In many cases there's nothing you can do -- it's simply a conflict of personalities. But if you find situations where the bad apple could have been prevented, that means there's something in the management of the team that needs to be addressed. (Strong emphasis mine)
And then Jeff's words stuck out, reminding me of me:
You can develop skill, but you can't develop a positive attitude.
In my case, it was me who decided to develop the positive attitude. But that doesn't mean it couldn't have been developed by a skilled manager who noticed the problem.
Retrospective action is useful in avoiding the problems of today in the future, but often misunderstandings, miscommunication, and a lack of clear goals or motivation can be the cause of friction or a bad-apple attitude.
So I take it a step further to the main course of our meal: Not only should you reflect on how the problem could have been averted upon discovery of the subversive, you should actively scan for potential problems and address them before they germinate.
It would not result in firings or team destructions, but instead focus on resolving the conflicts before they fully emerge. (Of course, if the problem is allowed to grow and fester, firings are encouraged.)
I'm not sure how to do that.
I don't personally have the answers regarding strategies for identifying problems and understanding what people really mean in conflict resolution, but I'm confident they exist. I've read as much. But I searched the all-knowing Google and didn't find the sources I sought. So at the moment, they remain outside
my realm of knowledge. Therefore, I'd like to ask: What are your strategies? How do you handle problem developers or teammates? What are the reading materials discussing these issues that I'm looking for?
I supplied the dinner. Can you provide us with dessert?
Hey! Why don't you make your life easier and subscribe to the full post
or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate
wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!
Last modified on Jul 23, 2008 at 06:48 AM UTC - 6 hrs
Posted by erik9000
on Jul 25, 2008 at 09:47 AM UTC - 6 hrs
The best strategy I've found is to simply be direct and honest with the 'bad apple' about their behavior. Don't call them out in a public forum, but pull the aside and confront them with specific examples as soon as possible after you have observed them. Tell them why their behavior is counter productive to the rest of the team and really to their own career growth. Offer them alternate ways of behaving that are more acceptable, and if possible offer them ways to rectify the situation immediately. Making them do something about it right then and there to make things better not only forces the bad apple to behave more appropriately, but also shows the other good apples that their peer is capable of doing good stuff, too. I don't mean this in a condescending way, but it's really not much different than how to deal with a problem child as a parent. None of us would ever fire our children, so we're forced to deal with it and help the kid be the best they can be. I think the same patience and support should be shown an employee by their manager. Hope this helps.
Posted by Eric
on Aug 11, 2008 at 11:15 AM UTC - 6 hrs
@erik9000 - indeed, that's on my list of must read books. It's a long list, and I haven't got around to reading it yet. Thanks for the suggestion.
@Eric - Thanks for the advice. That certainly sounds like a solid plan, very reasonable.
Posted by Sammy Larbi
on Aug 12, 2008 at 08:28 AM UTC - 6 hrs
