The Bad Apple: Group Poison

blog
101

As a web-url-grammatical thing, your sentence

This apparently led Will to his next research project: can a group leader change the dynamics and performance of a group by going around and asking questions, soliciting everyone’s opinions, and making sure everyone is heard?

Links to your own ‘Are you an Expert?’ post when clearly the reader is expecting that you’re linking to something referencing Will’s next research project, and not linking to your anti-expert post which is totally offtopic to Will’s next project.

It’s almost like quoting yourself, and we all know how much we like people who quote themselves.

102

Where is management in all of this?

Isn’t it the role of management to manage the team?

If you have bad apples on the team who influence the team, then it isn’t the fault of the bad apple or the team, but the manager who should be directing activity and if possible motivation.

Sorry Jeff, but the last bunch of posts are really loosing me. Ever since you left your last job the posts seem to be less and less about IT.

How about focusing on IT issues? Code, how to code, and problems with code. You know… code!

103

Coding Horror is always a good starting point for a sweet little discussion. Thanks!

104

what about trying to turn the bad apple good? where is compassion in this story? and why are you peddling these studies that have so many unknowns and look as if it is skewed to support a certain view!!

And that is the worst management study I have come across and your solution is probably the most autocratic!!

105

i am very much taken aback to see and read about this article . i deeply thank you for bringing this article to the blog land and to eyes of people .

I work at a respectable company in a team , and i am sure to feel the above is true from my experiences .

The bad apple at my team is at a higher grade position and uses various techniques in order to make his decisions come alive (back stage politics) .

He normally uses his group , to discourage people , at public . comments on disadvantages and bad designs people have authored or performed in public . challenges that what they have implemented at work is false and way to failure in public and that only his method works . Literally smashes anyone who speaks against him .

But his methods do , work and thus destroys a person’s self esteem . we really begin to think and doubt if we are below him . we also begin to become a pessimist and lose our high hopes .

Wish me luck in fighting against him .

106

Even if it’s you. Punchlines are very effective.
well, Master Jeff cannot resist the temptation, too :wink:
:smiley: :smiley:

107

How can having a bad apple in the team not affect the average?

108

And this is a suprise? I think this is closely related to conformity studies in psychology and they are never as black and white as the majority of good apples win out, quite the opposite the minority tend the sway the group majority.

Plus, bad apples exist, maybe some work should be done into understanding their reasons instead of saying - Get rid of the bad apple.

Also, why does the bad apple exist? - you can get rid of them by the cartload, but that doesn’t acknowledge the fact that underneath their issues may be a team member whose contribution could actually be worth something.

Plus the idea of good and bad apples tend to be great for the high and mighty, but the whole concept is a crappy idea. Potentially elitist and certainly prejudice.

109

And thus the motification of the human race started: when everyone realized just how convenient it were if every team could have a mediator to solve potential conflicts. Unfortunately, human mediators do breed, so in the end they and not the whites turned into the dominant caste (good point: no warriors!).

110

@keppla, you’re arguing cross purposes. Your experience in a team that was already toxic and not open to better methodologies doesn’t in fact have anything to do with how a bad apple can reduce the effectiveness of a good team.

If you already have a bad team, well that’s your problem. Sounds like you did the only thing possible and got out of there.

(Not directed to @keppla)
What’s funny is that most of the responses this blog appear to be one of those know-it-all jerks. People who have no experience at this sort of thing, but are able to make sweeping condemnations on a subject they know nothing of. Pricks.

(general comment)
To be statistically relevant, the 3+bad apple team would have to perform significantly worse than 75% of a good 4 person team. 75% would be the best-case productivity of a good team with 1 ineffective non-poisonous teammate.

e.g.
4-person effective = 120 products
4-person, 1 ineffective = 90 products
4-person, 1 bad apple = 60 products

I’m sure the author realizes this (it was a Masters Thesis) and I’m looking forward to reading the paper instead of just making comments about something I never heard of until 5 minutes ago.

111

Consider your own behavior on your own team – are you slipping into any of these negative bad apple behavior patterns, even in a small way?

No! Because I’m perfect and you’re not.

112

So…? A team of four workers out-performed a team of three workers and a decoy?

Perhaps I’d need to read the full text of the study to understand why this is significant.

113

There’s nothing wrong with constructive criticism. Other research shows that teams with depressive pessimists are more productive and end up with higher quality products precisely because there’s someone keeping them honest all the time. Slackers, sure, jerks, kick them out, but you lost me at pessimists.

114

@Console

Part of being right is to get the rest of the team along with you.
If all ways to make the sheep understand your clever
masterplan fail, eventually you have to give up complaining
about it and try to make the best of whatever plan you can agree on.
Otherwise you are just being a jerk, even if you happen to be right.

So, basically you are saying, that the results (failing or succeeding) do not count (…even if you happen to be right), but only that the team agrees?
By what definition is the critizizing the jerk, and not all the others the pessimists, then?

In my opinion, this whole bad apple stuff gets dangerously close to witch hunts, if the criteria to distinguish between beeing a jerk and beeing critical are left open.
To say that even the facts (beeing right) do not matter for labeling someone is just shocking to me.

He suggests creating a bubble of excellence around yourself.

Now for a practical example. Am i a pessimist, a jerk, or a slacker because, or do i just critizize honestly and try to save time?

Consider this:

The team won’t bother with source control? Install it
locally and use it yourself.

what for? the gain of source control is mainly centralization (how often do you ever used it for backup recovery or forensics?), so you gain very little, because you still have to merge the other coders code manually, and you get the overhead of managing the other coders code.

Nobody writes specs? YOU write specs.

what for? the point of specs is that they are followed and that you can resort to them argumentatively. Specs without authority aren’t specs, just documentation, which follows:

No documentation? Write it!

what for, if noone reads it, and worse, noone updates it (remember, wrong documentation is worse than no documentation)?
after all, it costs your time, where do you win time?

Please note: what for sounds very pessimistic, but it is the most important question for evaluating an action: can you justify the costs for the outcome?

For a company i worked in (i left because exactly these things pissed me of. luckyly i could.), i can say right from by heart: the costs are bigger, and people who are below such basics as source code control or testing do not see more than a waste of time in your actions. Worse even, they use it as proof that your methods don’t work.

In a way, this critizisms are even constructive: they offer the alternative of NOT wasting time. It is sad, but sometimes the best you can do is not shooting yourself in the foot.

So back to the bad apple question. Am i a bad apple? Maybe. I dont know. I hope not, i fear i could be.
But, honestly, noone else seems to know either. Just beeing the first who cries bad apple is not enough.

So, please, lets all just try to make informatics a science again and debate about facts we can prove and stop becoming those pointy haired bosses.

115

It’s interesting to examine the opposite of the bad apple effect, i.e. the good apple effect. Having a good apple on your team will dramatically change your team’s dynamic as well. It basically mirror the effect of an bad apple but positively. If you have a team member that’s extremely motivated, hardworking, passionate, and/or helpful, you’ll find that these positive behaviors / characteristics tend to spread across the team as well.

What’s more interesting is when you have both a bad apple and a good apple on your team. In my experience, the bad apple will pretty much ruin the team chemistry. And it will become the lowest common denominator over time. After all, I guess it’s much easier to be negative than positive.

116

@Keppla
So, basically you are saying, that the results (failing or succeeding) do not count (…even if you happen to be right), but only that the team agrees?
No, I don’t say that. What I am saying is that sometimes you don’t need to have a perfect solution in order to succeed.
It is better to reach a decision that lets the team move forward than to waste a lot of hours arguing technicalities. So you stop arguing, for the team’s sake.

Neither me nor Wayne said anything about how much arguing there was. In my case, from my side, mostly very little. I see no reason to fight for something which is not my opinion
but a widley accepted fact*, moreso if there are no counterarguments, just denying.
I have no problem following the teams way if it moves forward, but often enough, bad decisions are not bad because they move the project forward to slowly, but move it backwards.
It is as easy to destroy a project by moving fast enough in the wrong direction as it is by not moving at all.

In the very rare case where 1) a team of professionals are total idiots who are going to fail totally unless they listen to you
and 2) they refuse to listen to you, then you should still stop arguing and just quit. For your own sake.

no, that is the scary thing. they do not have to be complete idiots. in fact, they each had very strong abilities. But the team as a whole (not just the IT, btw) was
misguided, because they lived in their own little team world.
Thats why i am so oppsed to the kick the bad apple-approach: because i have seen how easy perception is fooled in a group.

The examples I gave were just examples from Joels article but I still want to respond:
Source control: You use source control because it is effortless and it will save your ass one day. It takes no time at all.

You underestimate the second best approach. It’s not that the ones who wont use SC will use all their data in a big crash one day, because they archive them manually.
Sure, its a waste of time, but you do not stop their use of time by your source control.
thats why i say that it saves no time: not as in a whiny it makes no sense, sniff, but as in the amount of time saved is -7 minutes per week.
It doesnt hurt, but its mainly for the ego.

Specs: You write specs because you yourself will want to know what it is you are supposed to do, verify it and make sure it makes sense before you go ahead.
You also want to verify your code against it later.
You can also show a spec to the PHB and ask him is this what the program should do? and be sure that the pogram is doing just that.

To make notes of what to do and having a basic plan before is not what i would call writing specs. Anyone does that.
I would only call it specs if they get some authority, and it makes sense to archive them, even if the authority is just the yes, thats what it should do from the stakeholder.
If the answer is either i already told you what it should do or something like a cointoss (go in a second time and you might get a different answer) it degrades to notes.
And when pulled out to explain a behaviour, it was seen as blaming or bad excuse, which gets you even more the bad apple look.
So effectivly, it did more harm than use.

Documentation: You write documentation so that the users know how to use your program, saving you from tons of support calls
and also giving the impression that the application is being maintained by someone who cares.

Your doumentation work has ultimately to pay of in higher user satisfaction and less work via support.
If you do not have the authority to pass it to the customers, this is not given. It even assumes, that you do not get in troubles for doing work not assigned to you.

Please note, except for the SC-thing i speak out of experience, i did not shun this approach in the first place. It just proved to not work, if you are really a grunt.

The trick is to stay positive and do the best you can, instead of finding reasons or excuses to NOT do the best you can.

it is irrelevant if you do your best, if your best if its still not enough, the world doesnt care if its you who is doing it.
The result is what counts, so check if it can be done good enough.

no, the trick is to do what can be done, and if some solutions are impossible, search for alternate solutions ways to solve the problem, instead of trying yourself to death. Think outside the box.

The solution to the problems with my old work was not giving the best but giving nothing at all anymore, as in quitting.
As a pessimist, i do enough questioning so that i can rephrase the question how to get things done as a grunt is wrong, and the first bullet point of the answer to the
real question how to get things done is fight beeing a grunt.

The difference between pessimistic slacker and honest critisism is that the honest critisism will offer an alternative action, not just empty opposition.

So, (a little bit ironic) if someone suggests shooting each teammember in the foot, you should suggest the small finger instead,
because if you just oppose to shooting anything, you are beeing pessimistic?

Let’s do this other thing! instead of What for?

Remeber that this other thing has to gain enough money on the long run to pay the time you work on it.
So, if you do not ask what for, you never face the sometimes cruel answer for to less gain. Just in the end one big our main customer jumped. we’re broke.
Again: what for is a constructive question (if it can be answered, you got the solution), just one noone seems to like.

based on the examples you gave, is in my opinion: [you are a] Pessimistic slacker.

i got used to the label pessimist (even if it turns out that mostly i was a realist), but what makes you think that i am a slacker?

If we’re at labeling, i give you the label kill the messenger. But relax, it’s an comfortable label. Much more comfortable than the messenger label :wink:

*) as in a Project consisting of hundred of files of 500+ lines of legacy-PHP, without a separation between model/controller/view, with many behaviour-redundant objects
needs refactoring. Or as in There is no way to let the system display the correct invoices if they are provided wrong by the deliverers

**) again, nothing i inventend myself. even in this blog there is a post about it

117

i think some of you are going way offtopic on this one. You’re either making arguments on long tangents or defending criticism you’ve received in the past (or perceived) and justifying it because you were acting like a jerk or something but you were right (of course).

And ‘jerk’ is just a label here. Read the article or listen to the interview. These labels are specific personalities that were observed in another study. The author then used those results as the basis for his own experiment - namely trying to measure if the perceived effect in the original study was a valid conclusion to draw from the original data.

You can objectively determine a ‘jerk’ ‘slacker’ or ‘pessimist’ and I think they should be fired. Sometimes people are not normally that way, but they’re in the wrong environment and they need to boot to change direction.

The flip side is if the toxic person stays, the good people leave.

118

@offtopic
Your experience in a team that was already toxic and not
open to better methodologies doesn’t in fact have anything
to do with how a bad apple can reduce the effectiveness of
a good team.

The main point there was not that their team was toxic (it feels good bitching about my former employes, though :wink: ), but to give an exaple of criticism, so one can demonstrate a algorithm to
determine if i am a bad, or a good but critical apple (Now for a practical example. Am i a pessimist […]? ).

In my opinion, to say a good team can be destroyed by bad members is worthless if the sole definition of a bad member is someone who destroys the team. So, if one cannot provide a better algorithm, the suggestion to ged rid of bad apples is useless in the best case (because it is not better than pulling matches), and dangerous at worst, because it has the potential to kill chances of improvement.

119

@Keppla

The trick is to do what can be done, and if some solutions are impossible, search for alternate solutions ways to solve the problem,

This is what I am saying. So we agree. I think bad apples stop at impossible and don’t come up with alternative solutions. Or they themselves come up with impossible solutions and refuse to do anything else, which is the same thing.

We are attacking straw-men here really. I am not suggesting that any manner of idiocy should go unopposed in the name of democracy.
I am pretty sure you are not claiming that everyone who refuses to follow the team rules is a hero either.

But in my experience, the lone genius in a flock of idiots is as common as a flying pig, and the jerk who is too full of himself to accept any other opinion than his own is as common as bacon.

I didn’t really call you a slacker, you wanted an assessment based on an example. Based on that example I am sure we are dealing with a slacker. The examples were things that any professional developer should be doing already, not things that should be debated. Widely accepted facts, if you like. So a what for here is a slacker response, IMHO.

That nobody else does it is also a typical slacker excuse. You should do it yourself anyway even if nobody even notices, because it is the efficient, professional, correct way to do your work. Which is Joels point. Read the entire thing, it’s very insightful.

Your explanations for why one should not use SC, not write specs, not write documentation are just…weird. How can you believe any of that and still function as a developer?
You sure worked in a strange, dysfunctional place if what you say is really based on your experiences. I don’t think you should carry it with you now that you have quit, most places are not like that.

120

I agree with this post. Had few personal experience. One was very touching in the sense there was a personal conflict more of a ego clash and there was shouting which few people over heard.I esculated it ot higher up, and he resolved the conflit in a manner which was good for both the parties involved and now things are fine, so far so good. I have seen a few bad apples in our company, they are the slacker kind and also they have a bad influnce on people becuase of their management styles. Some times unfortunately, the bad apple can be your own team lead, or team manager. In our case what we observed is that a bad apple from one team interacting with another team can have a bad effect too.