programming and human factors
by Jeff Atwood
A recent episode of This American Life interviewed Will Felps, a professor who conducted a sociological experiment demonstrating the surprisingly powerful effect of bad apples.
Groups of four college students were organized into teams and given a task to complete some basic management decisions in 45 minutes. To motivate the teams, they're told that whichever team performs best will be awarded $100 per person. What they don't know, however, is that in some of the groups, the fourth member of their team isn't a student. He's an actor hired to play a bad apple, one of these personality types:
The conventional wisdom in the research on this sort of thing is that none of this should have had much effect on the group at all. Groups are powerful. Group dynamics are powerful. And so groups dominate individuals, not the other way around. There's tons of research, going back decades, demonstrating that people conform to group values and norms.
But Will found the opposite.
Invariably, groups that had the bad apple would perform worse. And this despite the fact that were people in some groups that were very talented, very smart, very likeable. Felps found that the bad apple's behavior had a profound effect – groups with bad apples performed 30 to 40 percent worse than other groups. On teams with the bad apple, people would argue and fight, they didn't share relevant information, they communicated less.
Even worse, other team members began to take on the bad apple's characteristics. When the bad apple was a jerk, other team members would begin acting like a jerk. When he was a slacker, they began to slack, too. And they wouldn't act this way just in response to the bad apple. They'd act this way to each other, in sort of a spillover effect.
What they found, in short, is that the worst team member is the best predictor of how any team performs. It doesn't seem to matter how great the best member is, or what the average member of the group is like. It all comes down to what your worst team member is like. The teams with the worst person performed the poorest.
The actual text of the study (pdf) is available if you're interested. However, I highly recommend listening to the first 11 minutes of the This American Life show. It's a fascinating, highly compelling recap of the study results. I've summarized, but I can't really do it justice without transcribing it all here.
Ira Glass, the host of This American Life, found Felps' results so striking that he began to question his own teamwork:
I've really been struck at how common bad apples are. Truthfully, I've been kind of haunted by my conversation with Will Felps. Hearing about his research, you realize just how easy it is to poison any group [...] each of us have had moments this week where we wonder if we, unwittingly, have become the bad apples in our group.
As always, self-awareness is the first step. If you can't tell who the bad apple is in your group, it might be you. 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?
But there was a solitary glimmer of hope in the study, one particular group that bucked the trend:
There was one group that performed really well, despite the bad apple. There was just one guy, who was a particularly good leader. And what he would do is ask questions, he would engage all the team members, and diffuse conflicts. I found out later that he's actually the son of a diplomat. His father is a diplomat from some South American country. He had this amazing diplomatic ability to diffuse the conflict that normally would emerge when our actor, Nick, would display all this jerk behavior.
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?
While it's depressing to learn that a group can be so powerfully affected by the worst tendencies of a single member, it's heartening to know that a skilled leader, if you're lucky enough to have one, can intervene and potentially control the situation.
Still, the obvious solution is to address the problem at its source: get rid of the bad apple.
Even if it's you.
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!
Philip on February 22, 2009 3:32 AMCoding Horror is always a good starting point for a sweet little discussion. Thanks!
regular reader on February 22, 2009 4:03 AMwhat 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!!
darth on February 22, 2009 7:00 AMi 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 .
BooTCaT on February 22, 2009 9:38 AMEven if it's you. Punchlines are very effective.
well, Master Jeff cannot resist the temptation, too ;-)
:-D :-D
How can having a bad apple in the team not affect the average?
Bibble on February 22, 2009 11:36 AMAnd 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.
goatslayer on February 23, 2009 2:07 AMAnd 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!).
Joe on February 23, 2009 5:30 AM@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.
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.
Charles on February 23, 2009 6:14 AMSo...? 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.
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.
Bogus on February 23, 2009 9:55 AM@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.
Keppla on February 23, 2009 12:04 PMIt'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.
David Dai on February 23, 2009 12:39 PM @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 ;)
*) 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
Keppla on February 24, 2009 2:08 AMi 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.
offtopic on February 24, 2009 3:12 AM@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 ;) ), 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.
Keppla on February 24, 2009 3:16 AM@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.
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.
Anand.V.V.N on February 24, 2009 5:58 AM@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.
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.
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.
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.
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.
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.
The difference between pessimistic slacker and honest critisism is that the honest critisism will offer an alternative action, not just empty opposition. Let's do this other thing! instead of What for?
With this in mind, the answer to
Am i a pessimist, a jerk, or a slacker because, or do i just critizize honestly and try to save time?
based on the examples you gave, is in my opinion: Pessimistic slacker.
Another interesting situation is when the good apples are a basket of idiots. Trying to maintain a brave face knowing the ship is sinking doesn't inspire people who don't want to patch the leak--thus, failure (or lack of success) can also be attributed to not enough bad apple to push people over the edge into proactivity.
Can you imagine team situations where the jerk/pessimist/slacker causes so much friction, the remaining members become determined to prove him/her wrong? Negativity can also paradoxically be galvanizing, the proverbial boot to the ass
BTB on February 24, 2009 7:29 AMI think I speak for everyone else in the comments, as well as everyone that has read this article, in saying that I am glad that I am not the bad apple and I have many ideas and thoughts on all the teams that I've been on that have had bad apples that were not me.
Ben on February 24, 2009 8:22 AM@Keppla I don't think you are relaxed. It appears you worked with a very slack team, or at least your position in the team degenerated into 'ignore Bob and stick him in the corner' syndrome. You sound bitter still despite protests otherwise. Sorry you had to suffer, but there are better teams out there.
Something to consider: Sometimes there's that person who always wants xyz infrastructure upfront, because without xyz we'll never finish and it'll never be any good. Teams often get tired of 'Bob's and his new flavor of xyz's every week and someone going in and ruining perfectly good code or process, etc.
Now I'm not saying you're wrong - let's not go through that again - but perhaps it's the way you approach a problem.
You're in a team so work as a team. What I mean by that is not to use the holier-than-thou attitude or i-told-you-so aloofness, but to show cost/benefit and slowly introduce change. Show that the change is being progressive and not just ramming things down your coworkers throats. Show that there is real value, and if you can't show the real value, then maybe there isn't any.
While I agree as professionals we should ask questions and dig into details and ponder the different outcomes. But we should also not suffer from analysis paralysis, and we should also, once a decision's been made, stick with the decision. Treat all decisions as a team decision.
During the decision making be active. Look at multiple sides of the problem. Dissect things. Once the decision's been made, whether you like it or not, embrace it. As you say, sometimes you need to let things blow up (hopefully only in dev) before people will notice. This is human nature. Get used to it.
'Hey Phil, what do you think of X? I was thinking X could do Y and Z and that would make it easier. Mind if I try?'
But see all that doesn't have anything to do with coding. It's everything to do with working in a team.
Get the rid of bad apples and you are ready to quit business. Your last employee will be 20 year old student living with his mom.
dzver on February 24, 2009 8:43 AMThe sub-prime tummyache was caused by too many good apples.
Anyway that study is hardly exhaustive, typical sociological pseudo science crap.
Well we know who the bad apple is in this bunch.
Rob on February 26, 2009 3:04 AMYou know of course that the bad apples never realize they are the bad apples.
Instead it's always everyone else's fault so when you say get rid of the bad apples you're assuming everyone is in agreement on who that is.
Mitur Binesderti on February 26, 2009 10:09 AMThis article amazed me.... because in base of my experience I can confirm that it's simply TRUE !!! Imagine if you have on your team both
the 'Depressive Pessimist' and the 'The Jerk'... it's devastating!!!
I am skeptical about group think in general. Well, there is informatin sharing and the division of labor which are beneficiary to the work process. The influence of the bad apple is what I would more appropriate call realist apple, mainly what are we doing here? and Is the group's decision necessarily or even in most cases the most wise decision or depends the truth of a proposition not on the number of people supporting it but on a more objective measure?
While I do not doubt the outcome of the experiment in terms of what has been tried to be shown, I remain skeptical about team work in general which is simply a compromise, based on limited time, to come up with a working solution which is mostly pragmatically valid, but not optimal.
Jeff, your conclusion that the worst team member is the best predictor of how any team performs cannot be extrapolated from this study. The study was about the style of *behavior* that the bad apple exhibited, not that one of them had lesser skills.
What you are saying is that any dev team that has a junior member on it is only as good as the junior member. Nonsense.
Tim on March 1, 2009 5:56 AMThere's tons of research, going back decades, demonstrating that people conform to group values and norms.
But Will found the opposite.
This reminds me a bit of people saying there's no global warming as it's been a cold summer in their town. Rejecting tons of research on the basis of one study is hardly scientific.
I would argue that a 45 minute task is nowhere near the time needed to develop true group working. I remember I once had to work with a real pessimist. Initially I would be reluctant to be the one to argue against them, not wanting to rock the boat, but after a while (ie a few meetings) their attitude became tedious and myself and other team members became more confident in contradicting her. It probably even helped cement the team.
Of course, then you have one team member who doesn't work well with the others, which is a bad thing, but not as destructive to the whole team as this study would imply.
Rhys on March 1, 2009 12:56 PMI don't believe this study holds water, as this is contradicted by the earlier and much more famous study (M. Jackson, J. Jackson, T. Jackson, J. Jackson, M. Jackson) entitled One Bad Apple Don't Spoil the Whole Bunch, Girl.
Case closed.
But then again, I'm a depressively pessimistic, slacker jerk...
Pauly Valent on March 2, 2009 3:42 AMAnd what about the golden apple or something, what's the influence of a very talented lider??
Rulas on March 10, 2009 9:56 AMNot much coding going on, since everyone seems to be here reading this stupid crap. And, yes, you bad apples do damage. I was working when I received this crap in my work email. Unfortunately, I must reveiw (and action) all emails presented me. So, the effect was that a colleague dragged me from work to review this crap.
Avoid being a bad apple by getting back to work. Or, do us a favor, stay home and out of the way. We'll send your checks to you and you are allowed to meet and conference amongst yourselves. But, whatever you do, don't come to or call the office, ever, ever. Luv Ya. Peace.
bradleywas on March 24, 2009 2:36 AMLooks very interesting. Thanks for sharing..
http://www.mpos.net/s/p4.asp
http://www.mpos.net/
After reading some of these replies, unless they’re all meant to be ironic, I’m thinking maybe you should add that to your blag.
grow taller 4 idiots on July 21, 2009 2:10 AMOf course, then you have one team member who doesn't work well with the others, which is a bad thing, but not as destructive to the whole team as this study would imply.
Fingerprint Scanner on July 22, 2009 4:35 AMsome knowledge to understand, thank you, the author
http://www.ew09.com/
You are very good!Thank you!
tianliang on August 6, 2009 8:43 AMhttp://www.batterieslaptop.net
some knowledge to understand, thank you, the author
http://www.laptopbatterystore.co.uk
Read this article, some knowledge to understand, thank you, the author
Here I was thinking the problem would be lemons!
Jason on February 6, 2010 11:13 PMWhile listening to that TAL episode, I realized that I had often been the jerk in a small way: I would say sarcastic things that I thought were funny (and didn't intend to be mean) and that other people laughed at, but the other people probably really didn't think it was funny.
That is an easy behavior to change, and I think it does make a big difference.
Jason on February 6, 2010 11:13 PMIts a nice example of herd psychology. But I think the experiment is flawed. Felps has defined only bad apple and assumes all other are good apples. A more appropriate classification would be bad apples, good apples and the herd apples. Good apples are people who are self driven wont get biased by others. Herd apples will just go by what they see in others. Bad apples' defn will remain the same.
In the case explained in Felps' experiment, there is a group of herd apples with a bad apple. As the herd is not intrinsically motivated, they get easily biased by a bad apple as explained by him.
But consider a case where there is a group of herd apples with a good apple. The good apple will be positive spirited, extremely motivated and hardworking. This would be the positive extreme of a bad apple.
I think something similar to the previous case would happen.
Generally in a group, majority will be the herd with few good apples and bad apples. And i feel bad apples are very necessary to maintain the social equilibrium in the presence of good apples.
Senthil Kumar on January 22, 2011 10:54 AMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |