Dealing With Bad Apples

blog
#1

Robert Miesen sent in this story of a project pathology:

The fact that the customer signed off on this, however, did nothing to deter Joe from advocating JavaScript -- abrasively. Every time our project hit a bump in the road, Joe would go off on some tirade on how much easier our lives would be if we were only writing this job kiosk in JavaScript. Joe would constantly bicker about how we were all doing this all wrong because we weren't doing it in JavaScript, not even bother to learn the technologies we were actually using, and, whenever fellow teammates would try and gently bring him back into the fold (usually via email), Joe would just flame the poor guy. At the height of Joe's pro-JavaScript bigotry, he would regularly belt off comments like, "Well, if we had only done it in JavaScript," to such an extent that the team would have been better off if he had just quit (or was reassigned or fired.)

This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2008/07/dealing-with-bad-apples.html
#2

Its hard dealing with someone whoe isn’t productive, has a negative personality etc… Yes you need to address the problem as quickly as possible. First in foremost though, you need to avoid getting in that situation. A good hiring process will be your best defense. Always check references, always do your research. If someone is a bad apple, they probably have a history of it.

I think another good thing you can do is involve the team early on in the selection/hiring process. Its a lot easier to be critical of someone when they are just thrown into your group without having a say. Its also a lot harder to find problems with people when you were a part of the decision to bring them on.

#3

I generally hire using the NUTs (southwest airlines) philosophy… Hire for cultural fit. I would much rather have a good fit personally than get the best Java/C#/Perl developer. If the basic skillset is there and they mesh with the team, I’ll pick them over the 4.0, CS/Software engineering applicant that can’t function in a team setting.

I have also used the term cancer to describe a co-worker. Unfortunately, he is my bosses friend and has been in the organization longer than anyone else. Since I can’t remove him in any legal manner from the group, I (and about 30 others in the last 3 years) have decided to move on from this place. August 1st is my last day.

The project will continue and even improve over the next few years, but it could’ve been so much better without this one person. oh well, guess it’s no longer my problem!

#4

O/T, I know, and probably also asked and answered at some point, but: how/why do you post yesterday’s post today? I’m always flummoxed by the appearance of a new post dated yesterday, when I’ve already stopped by this blog at least once itoday/i. I don’t think there’s any place in the world where it was still 7/17 when the 7/17 post went up…

Ah. Probably some sort of limited-scope post-reviewing feature where you have some trusted few people check out a post before it goes live? And the timestamp doesn’t update when you hit Publish for real?

#5

huh… people like that don’t need to be fired or even disciplined… they usually just need recognition that they have skills that are not being utilized…

Yes, its possible to do it in JavaScript, and yes, we’re glad that we have someone like you with mad JavaScript skillz on the team… but the client said server-side code, and he’s paying the bills… and I need to keep this client otherwise I have to fire people. So we have to wait patiently until the next project to push JavaScript, k?

#6

All these cautionary tales have the opposite effect on me, I think that would be a nice problem to have.

I’ve just escaped from a place where all the developers complained about each other to all of the other developers; the managers complained about their own developers to the client (WTF!); and the developers complained about their management to the client!

Dysfunctional isn’t the word. I did suggest just locking the front door and calling it an asylum. Such was the state of the place that that comment wasn’t out of place.

#7

We have had this on our team before. Our problem bad apple was someone stuck in a programming mindset of well over 15 years ago and more importantly deathly afraid of anything remotely new. Having been hired before any of us, he had been able to convince management that his world view was actually still how it was. I was actually in a debate comparing the performance reliability of an Oracle database against a dBase file.

What is worse, all problems that were had for sometime were blamed on new technology. Database corruption (dBase) blamed on that new Win Server 2003 SP2 server it’s on for example, Win 2k was suggested because it had a better file system. Things like this completely frustrated the hell out of the rest of us.

Communication was also a problem, emails sent from him reminded me of a 4rd grader learning to type for the first time. Almost incomprehensible - 20 sentence paragraphs, missing important punctuation, or the exact opposite (overkill), and spelling anything over 5 letters was a challenge. But management just wrote it off as he’s busy!. Now we had to decipher what exactly he needed us to do. Worse, he was near silent in meetings, and could never explain his position or why something “wouldn’t work”. It was useless interacting with the guy, and I can tell you very honestly we all tried our best.

I wish I could say there was one thing that finally convinced management that this guy was really something time forgot and a dud. (We actually thought he had naked pictures or something) It took several years of pain before people started realizing that projects built that didn’t involve this guy actually worked, usually timely - and more importantly didn’t have to be debugged for a few months after release.

If I did have to pick one turning point, it was when we realized as a team that these old programs processes this guy had worked on for years, while always seemingly complex as they constantly errored out, produced bad data and the guy was up all hours of the night working, were actually quite simple. We took the source code, and started porting them into our new environment - and quite simply made them work. We were actually shocked at how little code they guy actually had written over the years. We were expecting well over 75k lines to deal with, and it ended up being less than 15k. It was completely void of any internal validation, everything had to be perfect for it to work besides relying on a huge set of assumptions. Overall, we went from 15k to about 24k. He called it a waste of time, bloated, and wanted management just to ignore it, but we convinced them that there was nothing wrong in letting us at least test it.

In short, our ported new and validated processes completed nearly 2 hours faster and produced correct results. This used to be a 5 hour process. We didn’t get to know we were correct for another 36 hours, as magically - the old process broke in front of everyone (as we always knew it did privately) and took a full day and night to correct in production. After our CFOs review - ours balanced - his did not.

Publicly he resigned. We could easily have been 2 years ahead of where we are today if he hadn’t slowed everyone’s progress. His world was filled with fixed rigid rules that even a slight temperature change would break the system kept everything held back to the lowest common denominator.

#8

@Chuck: Wow, I didn’t even notice that! Oh god, we’re living in the past!

#9

Ah but sometimes its the team leaders/managers who are the problem, and the complaints from the other team members that continue load into the night are the voices of reason. Sometimes its the apples, sometimes its the basket.

#10

But seriously, makes you wonder what sparked this entry.

This ‘secret’ is revealed in the first line of the post: Robert Miesen sent in this story of a project pathology…

Can you really call it a spoiler when it’s the very first scene of the movie? :slight_smile:

#11

I have recently just been pulled out of a project for a bad case of bad-apple-itis, and although I certainly didn’t like it, I admit that it was necessary, as we had a 3-day timeframe to deliver.

A lot of the time, the bad apple isn’t aware of what they are doing. One of the big problems is that they feel like they haven’t had their say considered, and when you hire people in industries based on intelligence and aptitude, that’s a mortal sin.

My biggest problem is that I don’t usually have a clear scope of what we are doing, so what I think is me discussing new approaches is actually me wandering off into oblivion.

In my personal experience on both sides of this, I’d say a lot of the time the leaders need to step in much sooner than they do. I’ve seen a lot of groups crumble simply because the leader was only leading those following him/her, and wasn’t making an effort to corral the wayward, other than to tell them to stop being disruptive.

There are going to be those in a group that need special attention to keep them in line. It’s usually just as simple as TALKING to that person and finding out what’s happening.

And don’t patronize them either; you’re there to settle them and turn them around if you can. If you can’t, then you need to take real action before they start becoming a regret.

#12

Well, i see your point, but i must say, the only way to respond to criticism sent via email is with a good flaming. honestly, i can’t remember the last time i agreed with criticism sent in an email.

I give you a bit more leeway if you talk to me in person though, mainly because i don’t have my trusty keyboard to use as a weapon (sharp pangs to the heart with witty comments, or a mildly hurtful blow from it’s blunt surface, you pick).

#13

I’ve seen this happen a lot over the years. Only twice was the cancer treated by some means other than surgical removal.

On the first instance, we had a lot of bad apples in the company. It was so bad that management brought in a team of industrial psychologists to analyze us individually and as a team to find out what was wrong. The fix was to introduce a series of meeting norms and organizational processes for the project. It worked (along the way I found out I’m an ENTJ on Myers Briggs).

The second instance we had a guy who just couldn’t listen. He was always forming a counter argument. Always. You could see the counter argument taking shape before the other guy was even finished talking. He was always talking past the other person. This guy had to be privately challenged to listen. In fact, the manager forced him to use active listening techniques. He wasn’t allowed to present any counter arguments unless he could demonstrate that he understood what the last guy said, and the only way to do that was by repeating back in paraphrased speech. (That technique is used by marriage counselors on people who are very argumentative.) He was cured.

In all other cases, I’ve seen the cancer removed.

#14

I’ve been that bad apple, disagreeing with bad practices and voodoo programing.

If you cant change the place you work, change the place you work. Go somewhere else.

We’re paid to solve problems. If your team doesn’t give you the slightest consideration and listen to the points you make, they don’t know how to solve problems. The inability for a team to give a valid and sound response to Why Not, is a clue they suk.

Unreasonable men force their surroundings to fit them.
Reasonable men change themselves to fit their surroundings.
Thus all progress is made by the unreasonable.

#15

The warning signs for bad apples something are very loud and clear, developers asking for random days off with 1 day warning without giving a reason is very frustrating for everyone on the team.

However, when does it go from someone who just has a different way of working everyone else or that they should be voted off the island, or worse?

Another warning sign I think is when they talk about projects they did 10 years ago on completely different requirements and think everyone should follow the same approach.

#16

… a level of basic personal and professional respect is mandatory for any team to function normally.

I used to think I suffered from being the bad apple - but not for any reason other than because my skills are simply on par, they’re nothing genius-like or even /good/ often suffering behind those that are really good at what they do. Then I realized, that skills can be honed and improved upon, which I’m still in training for :slight_smile: - but basic personal skills and professionalism is where I make up for lack of tech skills… it’s absolutely crucial for team cohesiveness, even if a team member is not that good skill-wise… we had a bad apple on our team recently that also quit recently. Everyone complained about that person because they simply would not keep their mouth shut and argued everything. Relief set in when I showed up one day and without a goodbye, that person was no longer with us - and if they’re reading this, so long; but it’s the truth.

Great and relevant article Jeff, cheers.

#17

In fact, the manager forced him to use active listening techniques.

A great story. How I wish we were all lucky enough to have managers this smart and effective! If you get only one thing out of this post, it is this:

If you’re the team leader or manager, dealing with bad apples is YOUR JOB. And if you are not actively doing it, you’re causing your own project to fail, even though you may not be able to see it.

If you work on a team with a bad apple, you can gently prod the leader/manager to do their job – maybe if you’re truly desperate not-so-gently go over their head – but unfortunately that’s about it.

#18

Sometimes it’s the other way 'round - you’re the one good apple and the rest of the team are the bad ones.

For example, my current employer began migrating from Delphi to C# over a year ago, and things haven’t gone too well because the senior staff desperately attempt to apply their Delphi worldview to the .NET Framework, with predictably poor results.

I’ve told them numerous times that they’re going about things in entirely the wrong way - using the wrong technologies for the job, or misusing the correct tech - and that hasn’t exactly endeared me to the team. But given the choice between being the bad apple and being correct, or just another good, yet wrong, apple, I’d much rather be the former than the latter.

Thankfully, they are starting to realise that just because I’m a junior doesn’t mean I’m always wrong. :slight_smile:

#19

Assimilator, see:

http://www.yafla.com/dforbes/Effectively_Integrating_Into_Software_Development_Teams

Also, I agree with some of the other commenters, above; if you find yourself constantly the odd man (or woman) out with highly diverging opinions from the rest of your team – maybe you’re in the wrong job. I mean that in a good way, mind you.

See also, Changing Your Organization (for Peons)

http://www.codinghorror.com/blog/archives/000689.html

#20

I have worked in places where I was a superstar, I have worked in places where I was a bad apple. The difference? The places where I was a superstar had flat organizations, where everyone had a voice. The places where I was a bad apple were places where the manager knew best.

As a manager, I have also had to deal with bad apples. I never got rid of any of them because of personality, though I have gotten rid of a couple because of simple incompetence.

What you are essentially saying is that the only role managers can play in dealing with bad apples is to get rid of them. The reality is that managers more often than not are responsible for creating the bad apples. Simplistically, people get frustrated if they are not respected. People get frustrated if they are not listened to. The fact that you have bad apples in your group reflects on your skill as a manager.

So, really, to the majority of the engineering managers out there: Get educated! Would you hire a person in your team without an engineering degree? Why do you think that you can be a good manager without having studied it? Being a manager is not in your genes, it is a skill that you have to learn, just like engineering was. Learn how to deal with your people, including your bad apples. You might actually find, like me, that a bad apple is better than most of the sheep you hire.

If you manage him right, that is.