Dealing With Bad Apples

The bad apple thing can go boths way. Some teams will label someone a bad apple when they don’t fall in line, or conform with the team, when that person is fighting for the best interests of the project.

I’ve seen this a lot in environments where nepotism runs rampant. Where being buddies is more important than the success of the project.

What if the bad apple is not a team member, but rather your team lead? This is the situation I am in. My team lead is pretty close to useless. He is like the headless nail - once hammered in, he’s nearly impossible to get out. And because he’s been here waaaay longer then me, the powers that be are not going to rock the boat. I like the quote I read above - If you cant change the place you work, change the place you work. That might be my new motto.

Actually, there’s no might about it. I’m gone.

@ Donald Duck

Bingo.

Bad apples are bad for a reason. Sometimes that’s incompetence, sometimes that’s their managers, but sometimes apples go bad because of where they’re kept. Apples need to breathe, people need to be heard.

I think your first response was the correct one: After reading this story, I had to resist the urge to lean forward, hand placed thoughtfully under my chin, brow furrowed, and ask – have you tried JavaScript?

You were giving the person a voice, a person who probably thought he was fighting for the best interests of the project.

Being a manager is like being a parent. You don’t throw a baby in the garbage when it doesn’t behave.

This blog would be sooo much better if it allowed JavaScript in the comments…

@ Shog9

It would be even better if it allowed PHP in the comments. And you don’t know what you’re talking about. :stuck_out_tongue:

Not being a team player is learned behavior, reinforced by management. Managers are usually so clueless most don’t learn anything until one bad apple causes real damage.

It’s probably also worthwhile to note that there is a distinct difference in-between people who are capable of being bad apples (in the truest sense of the team scope, meaning that they in some way negatively impact the team) in SOME instances, but not chronically.

Some of the other comments have mentioned this, but to go into a little more depth, some people don’t always react to different levels or kinds of stress in the same way, and some people won’t even react consistently to the act same amount of stress on a daily basis.

The post made me evaluate my role on my team and where and when I’ve been a bad apple (which thankfully retrospectively SEEMS to be far less often than when I’ve been a good contributor) and the causes of it. If there are no ‘third-party’ influences of your ‘bad apple’ status (i.e.; predisposition to dislike you in management or cliquish behavior/nepotism, or any other kind of generic ‘high school environment’) then you should always be open to considering what causes these reactions and find your own personal workarounds for them.

My professor once said: When you fire your worst employee, give him the best recommendations so hi can go work for your competitor

they usually just need recognition that they have skills that are not being utilized…

It’s not that simple. People are way too dynamic to just rest on the bounds of We know you’re good, but

It really takes some will and determination toward dealing with bad apples. In short, you really need to study their life a little. You need to find out if there is something else going on that drives as the fuel to the problem.

Dealing with bad apples is absolutely horrible experience, but leaving them to spoil the rest of the team is far worse. If you see a bad apple, make note of it and pass it on to your leaders. Listen to them. Talk to them. Just don’t simply ignore them as a lost cause because they ticked you off. Half the battle trying to figure out if the bad apple is spoiled for good. And you’re not going to figure it out by standing by praying that somebody else takes care of it.

And for the love of all things sacred, don’t solve character problems over the internet via e-mail. You’re just asking for a cake of misunderstanding. Find time (after work? gasp).

Read up on Maslow’s hierarchy of needs. It’s weird how much sense it makes after you’ve had to endure bad apples in your life.

So, I guess I’ll play the bad apple here since everybody else is just too impressed with the way you’re stating the obvious - or too lazy to actually switch brain on while on the interweb.

Aside from the no-brainers that you cited (for the trillionth time or so, echo, echo?) there’s also a slippery slope in there that you chose to leave completely unmentioned:

In every organization there will always be one person who knows what is going on. That person must be fired.
– Conway’s Law

At least point 4 and 6 in your list are very slippery because they can just as well (and in my personal expirience: at least as often) indicate a broken team/organization rather than a broken individual.

Honestly, how often have you seen software projects completely screw up? I mean really completely, from A-Z by all metrics. If your answer is anything other than quite often then you must be living in a different universe or just don’t get out very often.

Your bad apple list works in reverse in these doomed projects. I’m doing consulting gigs for a living and thus have witnessed quite a few of that kind.

I’m on the team that gets called in right after $important_but_difficult_person was walked out the door but - oops - management failed to notice that this very person was pretty much running the show. We even have a name for that, it’s the Clueless CEO vs eloquent CTO-Scenario. We call it that way because most of the time you’ll find an technically less than adept but very talkative CTO that suddenly can’t deliver anymore when the incognito workhorse was removed.

So, I’m not saying that bad apples don’t happen or are not harmful.
Just don’t forget to inspect (read: listen to) your suspected bad apple very thoroughly before dropping him out.

I had this problem on a project back in college. It wasn’t even something important and the jerk had t fight the entire group about it. Basically he wanted to force everyone to use Hungarian notation on the project, because they used it at his previous internship and it was just so much better. Nevermind that most of the group had never even heard of it, OR that our school had it’s own standards we were supposed to follow…

In the end we just gave him a section of the project to work on and the rest of us worked on the rest. Unfortunately we lost points for not effectively working as a team… :frowning:

What happens if the bad apple is the project manager himself? certain doom?

Right on, Jeff. :slight_smile: This is so true, and something that I see all the time. There are some people who are never going to get better and they just need to emgo/em.

-Max

Unfortunately this is particularly difficult to address in an academic setting. I’ve found myself as team leader on projects with some bad apples, but when you’re doing it as part of a research experience, senior project, volunteer diversity in computing project, etc., being team leader does not give you the authority to take someone off a project. That authority is usually held by someone distant or unapproachable, and in the interest of learning (even when it’s not class-related) you have to drag the bad apples through the entire process, slowing down your progress and degrading the quality of your work.

I hope that many of my peers do a LOT of growing up before they get to the real jobs, because if they don’t they will not be well-liked and they will not be successful.

What happens if the bad apple is the project manager himself? certain doom?

Quite certainly so, yes. Bad management has many times been the doom of really interesting and good projects. See Borland/Delphi and Netscape as most famous examples.

I have some bad-apple potential myself, as I’m rather rigid about the use of certain tools. But I’ve learned to leave the other devs alone with it - as long as people allow me to do most of my code work in Vim and not force me to use too many GUIs to code, I’m fine.

One thing about the code reviewing remark, Jeff: there’s a nice allegory: There is no (good) novel (or scientific paper, for that matter) without a decent editor, there is (nearly) no good musical album without a producer, there is no good code without a reviewer. People have to just accept that. If nobody reviews your stuff, you’re stuff’s sure to contain errors. Maybe your name is Donald Knuth and you can give everyone who finds a bug in your software a cheque (in fact, if you deny review of your code, you should be forced to do so), but chances are, you’re not Donald, and so you’d better hand it in so someone can have a look at it.

This should be mandatory standard in industry and academia, as well as in open source. I’m quite frustrated that it isn’t… (although I’m sure finding good reviewers is hard).

The second instance we had a guy who just couldn’t listen.

At my fraternity I have a friend that is exacly like that, he study chemistry and don’t know almost a thing about computers, but he just can’t accept right away anything that I say about programming (or anything else) at all. He always has a (usually inconsistent) counterargument to say and takes forever to prove your point. Fortunaly for all developers, he study chemistry, not computer science. Anyway I will try those tecniques to make him listen.

I completely agree that you shouldn’t be DOGmatic in any choice of tool. But I hate to see my baby (JavaScript) always DOGged.

JavaScript is a fine language, it gets a bad wrap from browser inconsistencies. But, with a good choice of library, I might get away with a plug for http://JavaScriptMVC.com, it can make certain applications much easier.

But of course, you should never rely on JS for validation.

I work in a large team of developers with one bad apple. That bad apple has been here rotting for 14 years (I’ve only been there 3). He has the ability to bring any meetings or discussions to a screeching halt. Any productivity can be ruined in just a few minutes of idle conversation about how we will all be laid off next week (a saying he’s been using for 14 years since he was last laid off).
A negative attitude for whatever reason will ruin everyone else’s day. I’m currently looking for a new job due to his bad-apple-itis spreading to a few more people lately and that is not an environment I can tolerate.

But seriously, makes you wonder what sparked this entry.

If your team leader or manager isn’t dealing with the bad apples on your project, she isn’t doing her job.

So… there is a woman involved, too? :slight_smile:

a developer asked for the day off.

For some autistic people, this seems to be a no-go.

I say the contrary: If a day off is a no-go, then something in the team is going terribly wrong.
In good projects, where every team-member has at least one substitue, it should be no problem to allow a day off. If you have to think about such cases, you should think what you have done wrong.

A day off is only disallowed one day AFTER a new launch - despite all testing, some things will show only then :frowning: