The Old Joel on Software Forum: Part 3 (of 5)

Troublesome Team Members

In Rapid Development, McConnell stated:

> The most common complaint about team leaders is that they don't address problems caused by troublesome team members. If you think you have a problem person, face up to that fact and eliminate the problem. Replace uncooperative team members even if they're key contributors. They cost more in team morale than they contribute technically.

Now, this is a hard truth, but I agree with it. The really hard part is of course "even if they're key contributors". I, mean wow, like that's a hard thing to accept, right since it seems like if you eliminate them the project is doomed? But the project is doomed anyway, as we who have been through this scenario know. Getting rid of the player who is creating negative productivity in the team due to morale being wasted at least gives the project a chance to move forward.

So take a time to think about that before I go to my controversial addition to McConnell's insight.

Ready, OK, here we go: In at least 2/3 of the projects I've been on that were doomed because a key but troublesome contributor was decimating the morale of the team, do you know who that key but troublesome contributor was? The manager!

So what do you do in such a situation? Thinking about it, I'd say float your resume and get out of there asap.

Dennis Atkins
Monday, November 24, 2003

I totally agree with McConnell and you. The worst experience of my career was being a project lead with the most experienced team member being the troublemaker. Everything I tried to do about it was nixed by the Dept. manager because he was terrified of losing this guy's experience. (He was VERY technically sharp, but an impossible personality).

So, yes, I started looking. Division was folded by company that bought us out just as I found a new job, so it turned out to give me a head start over others.

sgf
Monday, November 24, 2003

Your example is too global. If you team mates are not questioning direction, and approach, they are far more dangerous. I would in the department of "yes sir!"

Whatever the tech lead wants, everyone does it. How did it get like this? They dumped everyone who questions the manager or tech lead.

Do you think we have a better success rate?

aNoN
Monday, November 24, 2003

I managed a team of 5-7 people in a project. There was one the most smart team member, which also "troublesome" all others. I tried to "keep" "her" as long as possible to move project forward.

After the project was delivered to production, I said Ok to top managers to do what they want...

Evgeny Gesin /Javadesk/
Monday, November 24, 2003

aNoN has a point. From the manager's point of view, YOU may be the troublesome team member.

www.MarkTAW.com
Monday, November 24, 2003

You don't dump people for disagreeing with management, or disagreeing with each other. That's healthy, so long as the topic is a "how should we" or "which of the following" sort.

So what is unacceptably bad then? If the guy is actively insubordinate -- refuses to do his part of the work in the way the group and/or management finally decides on, to do it his way instead. If all implementation issues that come up lead back to "if you'd used /my/ design, you wouldn't have this problem" in lieu of more useful contributions.

It's interesting that managers won't even get rid of those people for you. It would seem obvious not to have people "working" for you who can't be given instructions and only contribute when it suits their ego. But apparently not.

The gray area of "usually bad for morale" is the legacy systems dude in the corner who objects to every single idea the rest of the team has. Sometimes they're interesting objections which lead to good ideas from the rest of the team, but it seems this happens purely by accident. He doesn't need to be directly insubordinate when he's been there long enough to use a more subtle approach. Generally this guy's boss thinks he's indispensable, and therefore puts so much importance on not pissing senior-dev off that essentially he does whatever the subordinate says.

The sort of place that has an org chart, and then a reality which is completely different. And yes, I agree with the OP; the acute embarrassment of having one of these guys working for you should be solved by getting rid of him, not by hiding in your office pretending it isn't like that.

Mikayla
Monday, November 24, 2003

To a good manager, "troublesome" doesn't describe someone who questions decisions and raises important issues. "Troublesome" means someone who's genuinely disruptive, who cannot or will not work and play well with others. Life is too short to work with such people, no matter how good they are.

The organizations that worry me are not those that value technical competence above all other things, but those that completely write off the importance of the ability to interact well with other human beings. Make technical competence your highest priority, and you won't get an argument from me. But if you insist on hiring social misfits who make life miserable for their co-workers, I'll work somewhere else, thank you.

Hardware Guy
Monday, November 24, 2003

MarkTAW -- if they think I'm the problem, I'd want to know so I could "fire my manager" sooner rather than later.

Mikayla
Monday, November 24, 2003

If I know that I need a "troublesome" worker to move project forward I will keep that worker in the team. Sometime we have no time or option to hire someone else to start production on time <-- that's healthy.

Evgeny Gesin /Javadesk/
Monday, November 24, 2003

"So what is unacceptably bad then? If the guy is actively insubordinate -- refuses to do his part of the work in the way the group and/or management finally decides on, to do it his way instead. If all implementation issues that come up lead back to 'if you'd used /my/ design, you wouldn't have this problem' in lieu of more useful contributions."

But what if he's right and the design that he's being asked to use is bad and causes long-term for the group? Then you're the problem, if you can't tolerate dissent.

Some_things_never_change
Monday, November 24, 2003

"causes long-term" should be "causes long-term problems"

Some_things_never_change
Monday, November 24, 2003

There's a difference between questioning design decisions and refusing to work. If your manager decides you do X instead of Y, even where Y is better, you register your complaint with him, and do Y. If it later becomes obvious that X was the better choice, you don't say "I told you so" or do anything else to make your manager feel stupid.

There is no hard and fast rule for dealing with managers, some may enjoy a healthy discourse, others don't want to be questioned. I wouldn't take anyone's advice that told you to always do one or the other.

And yes, if your manager doesn't like you, you'll want to know so that you can "fire" him rather than the other way around.

www.MarkTAW.com
Monday, November 24, 2003

Note, in that specific case, which I talk about, all design and architectures were my. That "troublesome" worker had the best understanding, comparing to other team members, how to do it. She helped and teached others about the details. She's "troublesome" was not design or working performance, but making fast career, which is not so bad too...

I think each story has something specific, not every "troublesome" worker should be fired.

Evgeny Gesin /Javadesk/
Monday, November 24, 2003

I have a personal interest in this topic given that a few years back I'm sure I filled the role of the absolutely worst nightmare "troublemaker": I was a constant source of irritation because I refused to simply accept an absolutely disasterous design, a technically incompetent manager who insisted upon playing the part of code guru, a total lack of up-front designs and a propensity to jump into building a myriad of business and data layers for a totally undefined "problem", and an absolutely broken leadership chain. Because I was only one with any code legacy at the organization (the rest of the team was much newer), instantly I was set apart as the outsider, and I became the source of all perceived ills for the "team" (team being a malcontent group of industry bottom dwellers collecting a paycheque). I went my separate way, with a nudge as I smiled my way into quite a few extra paycheques.

Over the next 6 months 75% of the "team" left the organization -- apparently they'd yet to find the head vampire.

It's me!
Monday, November 24, 2003

Just wondering, but does anyone here work for a manager that's smarter than they are, or that they respect?

I notice that almost everyone has a war story about how stupid their manager is and how the world would be right if everyone would just listen to them. I never knew there were so many frustrated geniuses out there.

We must do something to right this grave injustice.

anon
Monday, November 24, 2003

The key element of the sort of troublesome that warrants removal despite being 'indispensible' is that the individual *poisons* the morale of the team. Arguing with others, disputing or questioning the manager or the subordinates, all of this can be done in a productive or diplomatic way. It's when this, or any other activity, destroys the team morale that there is a problem. And like I said, 2/3 of the time when someone is destroying the morale of the team, that person is the manager.

And yes, if a manager thinks that I am the latest in a long chain of different troublemakers who seem to poisoning the morale of every team they manage, I really would hope that that manager would fire me so I can get some unemployment benefits during the two or three days I am off before I get picked up by a competitor.

Dennis Atkins
Monday, November 24, 2003

People generally don't write "oh yeah...everything is ay ok". Of course you hear about the exceptions.

Having said that, of course there are a lot of incompetent managers (just as there are lots of managers who'll recount about incompetent employees) -- this is primarily true when a manager has overriding self-doubts so they attempt to portray the idea that they could fill the role of any of their "underlings" (though of course in software development it's supposed to be more flat with a manager being a role rather than a superior position).

It's me!
Monday, November 24, 2003

The issue of refusing to work is a different one. We are talking about a 'key contributor'. By definition, they are making indispensible and valuable contributions to the project every day they are there. That's why this seems such a dilemma to eliminate them. By 'troublesome', we mean that they are poisoning the morale of the group. The means by which they do this vary depending on the creativity and experience of the misfit -- some can decimate morale and productivity in spectacularly innovative ways -- for example the CEO of that corporation that eliminated offices and forced all designers to have lockers and little red wagons.

Dennis Atkins
Monday, November 24, 2003

Been my experience that the most troublesome team member is in fact the manager. At one company I asked them to fire the project manager, they didn't, I left. I reckoned if they could not perceive her incompetence then how did they perceive my competence ... I lost respect for their judgment and moved on. Well, they fired that manager 3 months later. My replacement was smarter than me which was a good thing. I think it's pretty easy to marginalize a cohort who doesn't produce especially if they don't produce. If they are a primma donna then it's just a question of balance: does their expertise compensate? I tend to give great leeway to those with more expertise and IQ than myself but I give very little to those with less. I've never had troulbe exposing a troublesome worker who did not produce and I've never wanted to expose a troublesome worker who did produce.

Me
Monday, November 24, 2003

Imagine if, say, the bread making industry was like ours, appointing non-experts as managers.

Say we were appointed as manager of the bun making area. We would be scared of our incompetence showing. The expert bakers would despair of our sometimes stupid decisions.

When batches of buns turned out flat, we would blame the oven, or the bakers, or someone.

It wouldn't be too long before some of the expert bakers became "troublesome." They would tell us were morons. Or perhaps they would just share this attitude with their colleagues.

That's about the state of IT management.

.
Monday, November 24, 2003

To combine the thread on Stupidity in Marketing and the Dog in the Manger developer, Drew Majors springs to mind. Now I could be doing him a disservice but from the Valley of Despair it looked like it was primarily he that shackled Novell and stopped it leapfrogging NT.

Not that that would have helped in the Wordperfect debacle (co-religonists is a poor reason for buying a company).

Simon Lucy
Monday, November 24, 2003

> But what if he's right and the design that he's being asked to use is bad and causes long-term for the group?

I'm sure that happens.

However, a scenario I've seen over and over again is that there are several ways to tackle a problem, and they may *all* be viable, but incompatible. The team needs to pick one.

Some of this is role playing: The Contrarian, The Rebel Alliance, The Lone Genius, The Spoiler, The Prima Donna, The Persecutor, The Martyr, The Nonconformist -- how many of these have you worked with?

Portabella
Monday, November 24, 2003