But can the team leader avoid the bad apple? A bad apple can be a good apple that got bad. In this case the team leader is also not doing her job if she doesn’t communicate properly with her team and doesn’t avoid getting into a damaging situation by setting clear expectations early. This way, an apple can decide to accept that path, quit or (hopefully not) become a bad apple. I’m sure that most of the bad apples didn’t have that chance and became bad without knowing it and thinking they where doing the best for the project and that they could change it’s direction for better. It’s irrelevant if she was right or not. A bad apple could be a very good apple in another team. And the opposite is also true.
Of course, a bad apple could be just bad from the start in wich case you shouldn’t have hired her.
When you are managing projects you can choose to use a carrot or a stick, the trick is knowing when to apply either one.
The case study you have presented uses plenty of sticks, but I see no carrots.
Most conflicts tend to be two very stubborn people refusing to budge an inch.
Having a team member that has not bought into the project will often result in net negative code (another wonderful McConnell term).
When faced with this problem I tend to use a positive approach at the beginning rather than attempting to thump the person into submission.
If the team member truly believes that JavaScript is better than give them the opportunity to prove it. Let them build a small sample using the technology and then compare it to the PHP/Zend sample.
Three things can happen.
They fall on their face and aren’t able to make anything work (the usual scenario).
Surprise, surprise, they present something amazing (very rare).
They cobble something together that barely works but isn’t efficient or workable or is in fact a security risk.
First two scenarios are extremely easy to deal with, and the second one is awesome. Third one can be measured with metrics and performance statistics.
What you call a bad apple MIGHT be considered thinking outside the box by others.
One of my teammate kind of becoming a bad apple. Despite his big talking about design patterns and stuffs, his codes are ‘over-designed’ big ball of spaghetti that has too many inheritance all over the places. It almost impossible to change anything without ripple the effects in large scale. Things are getting more and more complicated when we have to integrate everything together and he refused to change his coding styles. Though I knew all his intention was for the good of the project itself, I think the main reason was his lack of good understanding of good designs.
So I think, the bad apple might not be aware of his being the bad apple. From his point of view, he might be the one that trying to do something great and that no one is understanding him. I don’t think dropping the bad apple out is fair for him and it’s something the team lead should step in and try to turn him the other way around.
I am very happy at my present job for precisely the reason that bad apples/duds get the ax quite fast. It’s high end consulting work and not everybody can do it. It takes top notch people skills, deep technical expertise, and the humility to do some very low end stuff to get things done. We interview very thoroughly, but a few undesireable people still creep in.
My boss gives them one chance to fix themselves. Most are gone a month later. On occasion, they take it to heart and fix the problem.
Not to say that these people are all dirtbags (some are), but that not everybody is cut out for the kind of work we do. I’m sure they could succeed in another job with differing expectations. There’s no use in keeping them in a position that they won’t be successful at. It’s painful for both parties, but also ultimately beneficial for both.
I was that guy 13 years ago. Went from a company using relation DB’s, to a a place moving from btrieve to MS Access. Their biggest complaint? Access doesn’t have arrays. I tried to explain basic relational theory to the people very senior to me, only to be met with the same complaint. In the end - the problem was me. No matter how much I thought I was right, I should have have kept my mouth shut. Sometimes fitting in means leaving a finding a place where you share a like mindset.
Bad Apple in the original example was half right - to the extent that client-side Javascript would have been useful for preventing some obvious crap from being sent to the server in the first place - but totally wrong in thinking it could replace server-side validation.
The question is never which to use, it’s whether to use both or let the server do all the work. Any web-based app that trusts that data coming in has already been been validated is a security nightmare waiting to happen.
Jeff - Don’t ever work for someone else where the coding standard uses #region’s
I think we all have the potential to be bad apples - right now it may be me with respect to a recent decision by management regarding a problem-tracking tool-set. However, in that case I don’t think the final decision has been made and I therefore think it is appropriate to be clear on my reasons against the current choice.
Charles mentioned Myers Briggs personality analysis, and it is often considered good to get people into a team who do NOT match the personality type of those who currently staff it. And at team or company level, you probably have experience of sales teams who seem to be a frequent IT bugbear - because they do and say things that at some level seem distasteful to us - but we nevertheless (probably) need them so we have work.
My point being that sometimes it is important to challenge our own beliefs with a different perspective. If we all think and code the same way, can we be open to alternatives?
That said, to harp on about stuff, even if we BELIEVE IN IT, after the ‘decision day’ will understandably have a negative impact and should be stopped by managers.
Most people just can’t leave their ego at the door.
Be passionate and debate (big) changes, but when the team makes a decision, it’s the teams decision, and it doesn’t matter who sparked the idea, it now belongs to the team. Likewise, even if you think you had a better idea, the decision’s been made, so shut up and never be Mr I-told-you-so.
Sometimes it’s better to appear humble and lead someone else to see the light as opposed to ramming it down their throat.
Sometimes you’re wrong, and being wrong is okay. Learn from you mistakes.
Sometimes you cannot just let go of a bad apple, even though it the the right thing to do. For example when dealing with a buyers market of technical skills it is extremely hard to find people with the right skills. On top of that you have the investement that is made when you bring them onsite.
These two factors make you work really hard to coach the bad apple. When the bad apple cannot be coached then the hard decisions have to be made.
This is coming from personel experiance. I have a bad apple on my team today. He cannot be coached, but I cannot find a qualifed resource to replace him. Even if I could then it would take about 12 weeks of investement to make this person productive. In our management team meetings we discuss this delima almost weekly, we know we need to throw out the bad apple, but we cannot!!!
I’ve been a bad apple for 2 years in a software development firm. I just couldn’t integrate into the insanity of the team. And by insanity I mean real insanity. Everything was done wrong, the stuff that was done right was overcomplicated and had too many bugs, etc. Every suggestion I made (before shutting up) was either rejected or implemented in such a horrible manner that I refused to take the credit for it.
Jeff, have you thought about that? That the team is loony/broken/insane/fine and dandy in their collective madness and the newcomer is trying to point it out, but in the process he gets to be the bad apple for not fitting in.
For two years I did what I was told and kept my mouth really shut. Then I got fired. That was the best day of my life.
For some autistic people, this seems to be a no-go.
I agree. We don’t know the context here except that it was before the launch.
But: before the launch ist often synonyme with a lot of overtime. So I’ll take this as a scenario:
I myself find it horrible shortsighted to heap overtime on overtime for the teams sake, hooray, hooray.
If the member wants a day off to clear his mind and do , give it to him. He’ll be of more use the next day.
If denied, only solution as developer is: put yourself into a position that you just have to take the day off, because of . Your boss might frown, you colleagues will understand.
Sometimes bad apples happen because the manager promotes his ex-IBM buddies. Writing on the wall here.
Overcome bad apples and massive egos with strong management or get other developers to grow a backbone. Seriously sad when people have to deal with other people with a school yard mentality. These people are on a team for a reason. The complainers are part of the team too. If they don’t call out the bad apple they are bad apples also. Fire them all.
I’m currently in a team of two working on database access through the web browser - generally we work well together but I do find my team mate doesn’t really input many ideas into the project, he seems to readily accept mine but then when I check to see whether he’s completed his bit so we can integrate components, it’s usually something completely different to what we agreed!
Hi, the point I would like to make concerns the simple firing of people.
Firing people can be incredibly difficult in some countries and the work and effort needed to manage someone out of the team (and therefore out of the company) can be real drain on everyone’s time and energy. Even through you know it is the right thing to do, it becomes a very time consuming process. The last thing you want to be dealing with is a work tribunal. You often have to prove that the work of the bad apple is not to standard and prove that the person is aware of quality of work needed. Next there is the warnings needed; first verbal warning, then a written warning before dismissal.
Of course, when the bad apple is verbally warned or given a written warning, they can become a jobs worth and just do exactly what is required and nothing more. It this point you hope they jump ship, but if they want to dig their heals in the ground then the cancer and really set in.
Reorganizing the team so the position no longer exists and offering redundancy means a) you can’t create a new position for a length of time and b) a loss of moral as the rest of the team see this behavior rewarded with redundancy money.
The moral of the story is - Don’t do anything without HR being involved. Otherwise you can leave yourself open to being sued and that can also wreck your companies image of being a good employer and heap a whole load of stress onto you. In fact the whole process is stressful but you have to believe in what you are doing.
Courageous managers confront the bad apples on the their problem behaviors. The cliche says that people never change, but I have seen bad apples reform themselves in response to being taken to the woodshed.
Bad apples in the IT industry still stun me. Were they all excused the week of kindergarten where we were taught how to get along? I don’t care how smart you are, how much of a stick in the mud, how opinionated, whatever: talk to people like they’re human beings, not strange fleshy manifestations of IrCbots.
Actually the thing that annoys me most and I see it as Bad Apple Syndrome, is a team member that doesn’t update/commit to version control enough. I think you have to update at least once per day (The whole project) and committing should be whenever an important milestone happens/when the code works/at the end of the day but only the working bits. At my workplace we have a few people that allergic to updating. About once per week they will have a problem and mention something like, Oh have you noticed this bug? and I will say Yes, we fixed that 3 weeks ago, why don’t you update? and they will say Which file? and I will be like $#@#$(%###$(#(!!! and my head will explode.
