14 Jan

Bad Apple Behaviors

Category:General PostTag: :

One of my non-technical enjoyments in life is listening to the This American Life podcast, from Public Radio International. It isn’t always my political cup of tea but it is always entertaining.

I was catching up on some past shows recently, when I ran across this episode:

December 19, 2008: “Ruining it For the Rest of Us.”

The prologue to this episode is the first 13 minutes and is a wonderful discussion of team dynamics. I strongly suggest downloading and listening to it.

From the This American Life website:

A bad apple, at least at work, can spoil the whole barrel. And there’s research to prove it. Host Ira Glass talks to Will Felps, a professor at Rotterdam School of Management in the Netherlands, who designed an experiment to see what happens when a bad worker joins a team. Felps divided people into small groups and gave them a task. One member of the group would be an actor, acting either like a jerk, a slacker or a depressive. And within 45 minutes, the rest of the group started behaving like the bad apple.

How many of us have met one of these people on a team we have worked in? How many of us have committed the sin of being one of these people at some point in our careers?

The Jerk

The jerk is someone who attacks or insults others. The jerk is a voice of derision and operates by tearing down others. Tag lines of the jerk include:

  • Are you kidding me?
  • Have you ever actually taken a [fill in technical area of expertise] course?
  • Do you have any idea what you’re doing?
  • Lots of eye rolls

The Slacker

The slacker consistently endeavors to do less work. Typical slacker behaviors include:

  • Lean back, feet up
  • Texting another person in a meeting
  • Commonly says, “Whatever.”
  • Often overheard saying, “I don’t care.”
  • Will ultimately be heard claiming, “This job doesn’t matter. Let’s just get it done.”
  • Lots of eye rolls

The Depressive Pessimist

A depressive pessimist is a doom and gloomer. This is the person on the team most often nicknamed “Eyore”. Common Eyore traits include:

  • Head down on the table/desk
  • State that the effort is unenjoyable
  • Overheard saying, “This work won’t matter when we’re done anyway.”
  • Body language slackens and hunches down
  • Lots of eye rolls

Some bad apple statistics

The following statistical findings were claimed in the study discussed in the segment.

  • A team with a bad apple member will perform 30-40% worse than a team with no bad apples.
  • The presence of a bad apple on the team results in less communication between others.
  • People mirror bad behavior in working with others.

And finally, it comes to this: A team isn’t often elevated by its best member, but depressed by its worst.


5 thoughts on “Bad Apple Behaviors

  1. Ooh, I can talk about this — it fails to note the gap between team dynamic and organizational culture to create hasty generalizations that don’t apply to specialized fields! (I do get to use that college education after all!)

    See, between Brooks’ observation that the best software developers are 10x better than the worst ones, and Wall’s observation that good software developers manifest Laziness, Impatience and Hubris as virtues, I would be more surprised by a technical team without “bad apples” successfully producing high quality software than by a technical team with “bad apples” genuinely performing 30-40% worse than if the “bad apples” were removed.

    Consider: If somebody like, say, Robert C. Martin rebukes somebody like, say, me for not crafting software of an appropriate caliber for a project he’s working on, he might come off as a bit of a jerk — with my lack of quality contributing to the size of the rebuke which reflects on the sender of the rebuke, Uncle Bob, rather than the appropriate recipient, me and my piss-poor skills. (Yes, I have been personally rebuked by Uncle Bob; No, my skills — while far from astonishingly fabulous — aren’t really piss-poor.) But this makes Uncle Bob the bad apple from a organizational communication team perspective, because that perspective doesn’t understand that the output of our work is *not* fungible. So, at this point, 10 things:

    01) If the team is astonishingly balanced to the point of fungibility so that nobody can rightly be bored with a project and snapping at their lessers, there’s probably not a lot of internal coaching/mentoring/growing going on. You don’t have to look at the statistical liklihood of getting good-vs-poor developers to realize that a reduced-growth situation is more likely to hold less ambitious and thus less committed developers. There’s a chance that it’s a team of bored superstars, but it’s more likely that they got a MS McCertification and are just there to collect a paycheck.

    10) If you get rid of a bad apple as determined by that short list above, you’re more likely to be getting rid of the good programmers, the people who have the experience to say “this is a solved problem, let’s just reuse that solution” and the people with the guts to say “No, really, why am I here if you’re not ready to make this decision?” It’s going to be the good apples that would rather not make waves than force issues, that “tackle challenges” rather than “solve problems,” et al, that stay behind to do the work in the way that seems obvious to them. The claim that a team lacking in highly-qualified and capable people can generally perform better without them is ridiculously obtuse to the same degree as claiming that Subprime mortgages are generally good investment opportunities.

    This isn’t to say that good programmers shouldn’t try to be nice, helpful and hopeful. It is to say that the “bad apple” wisdom can be very quickly conflated into shooting the messenger for bringing bad news about the project team. And frankly, it’s bad enough that the poor project got saddled by rat-hole-digging time-wasting morons who are underperforming in their job role and soiling everybody else on the project by association without a bunch of dead messengers on it, too.

  2. Some jobs, you can’t help but be a slacker or a pessimist because the project is just bad. When you are that point in the project where it’s obvious the path you are on will lead to failure, but there is no going back, and management is looking at the sunk cost saying “We can’t quit now, look at how much we’ve already spent.”

    It’s that point where you think you should look for new work, but this job is pretty lucrative, and if you distance yourself from caring, it’s kind of funny too.

    So the secret is to be a Cheerful Pessimist. Then you can’t be quantified as a bad apple and in the long run, we’re all dead anyway. 🙂

  3. @NNeko

    I think the distinction should be made between role and behavior. Of course a rebuke is often desireable. Does the rebuker need to start the discussion with, “Hey, asshole…”?

    No, then he’s being a bully.

    I would suggest the acceptance of bad behavior in high performers has ultimately led to the acceptance of bad behavior in the industry as a whole.

    This allows people to write off, “Those technical guys” as “just that way.”

  4. @NNeko

    You need to make a clear distinction between someone offering criticism, vs. just being a Jerk. Criticism is a fact of life and when done in a professional manner it is not a sign of a bad apple. Regardless of what “authority” the rebuker speaks from, *How* they deal with others is more important than what they claim to know.

    I boil this down to constructive criticism vs. destructive criticism. A constructive example is pointing out a potential flaw and discussing & pairing better alternatives. Destructive critics are the people that act like a Jerk. They point out other people’s mistakes but offer no assistance to help improve the whole of the team or the problem at hand aside from “you should go read up on {insert design pattern}.” coupled with a crude remark or condiscending look on their face.

    Given I manage a team of 6 developers of reasonable skill with one highly skilled “lead”; If that lead acts like an elitist jerk harming the morale of the team, I’ll much sooner get rid of that lead than wait for the rest of the team to quit. Even if that lead has considerably more experience and knowledge than any other member. If they’re not capable of being constructive and sharing that knowledge and getting the whole product (not just “their” sections) built to the best reasonable quality, they aren’t worth it. Just say “no” to Holy Cows.

Comments are closed.