Troublesome Team Members
In Rapid Development, McConnell stated:
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).
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!"
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.
Evgeny Gesin /Javadesk/
aNoN has a point. From the manager's point of view, YOU may be the troublesome team member.
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.
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.
MarkTAW -- if they think I'm the problem, I'd want to know so I could "fire my manager" sooner rather than later.
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/
"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."
"causes long-term" should be "causes long-term problems"
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.
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...
Evgeny Gesin /Javadesk/
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.
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.
People generally don't write "oh yeah...everything is ay ok". Of course you hear about the exceptions.
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.
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.
Imagine if, say, the bread making industry was like ours, appointing non-experts as managers.
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.
> 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?
Fog Creek Home