Passive aggressive colleagues.
-
I received a newsletter today with a tip on dealing with passive aggressive colleagues: It can be incredibly frustrating when a co-worker agrees with a plan of action, only to go off and do his own thing. This type of sabotage is all too common and can make it difficult to achieve your goals. When you have a co-worker who says one thing and does another, try this: 1. Give feedback. Explain to your co-worker what you're seeing and experiencing. Describe the impact of his behavior on you and provide suggestions for how he might change. 2. Focus on work, not the person. You need to get the work done despite your peer's style, so don't waste time wishing he would change. Concentrate on completing the work instead. 3. Ask for commitment. At the end of a meeting ask everyone (not just the troublemaker) to reiterate what they are going to do and by when. Sometimes peer pressure can keep even the most passive-aggressive person on task. My experience in this is that if I did that, the passive aggressive behaviour would simply become aggressive behaviour. I can't see this advice being worth the electrons that sent it. What's your experience in this kind of thing?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
I have both been a part of development teams and been responsible for them. I agree that the troublemaker will remain a trouble maker no matter what. I have taken the approach to ask the passive agressive individual to take the lead on a particularly difficult aspect of the job at hand. 9 times out of 10 they eventually turn around or leave on their own.
'With hurricanes, tornados, fires out of control,mud slides, flooding, severe thunderstorms tearing up the country! from one end to another, and with the threat of bird flu and terrorist attacks, are we sure this is a good time to take God out of the Pledge of Allegiance?' - Jay Leno
-
I received a newsletter today with a tip on dealing with passive aggressive colleagues: It can be incredibly frustrating when a co-worker agrees with a plan of action, only to go off and do his own thing. This type of sabotage is all too common and can make it difficult to achieve your goals. When you have a co-worker who says one thing and does another, try this: 1. Give feedback. Explain to your co-worker what you're seeing and experiencing. Describe the impact of his behavior on you and provide suggestions for how he might change. 2. Focus on work, not the person. You need to get the work done despite your peer's style, so don't waste time wishing he would change. Concentrate on completing the work instead. 3. Ask for commitment. At the end of a meeting ask everyone (not just the troublemaker) to reiterate what they are going to do and by when. Sometimes peer pressure can keep even the most passive-aggressive person on task. My experience in this is that if I did that, the passive aggressive behaviour would simply become aggressive behaviour. I can't see this advice being worth the electrons that sent it. What's your experience in this kind of thing?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
All kidding aside, I have found that compensation works as a great lever to achieve the desired results. If developers were compensated on what they produce, they focus on getting the job done. The historical method of setting a fixed salary works to attract the least common denominator "Wally" types who will go off and play with some bright shiny toy instead of getting the work done that makes the company money. That being said, there must also be time to play with new technologies which is structured into the system of compensation. In the end, friction causing and unproductive members of a team compensated in this way find their own path out the door. Side benefit is that it can save you mountain of H.R. paperwork. I'm not pitching that this solution is perfect, but when the actions at work affect the amount of money a resource sees in their paycheck the focus is on completing the work the company needs. (Shameless plug, but this is addressed in detail in my book Agile Development & Business Goals.) It sounds ruthless, and to some it is not acceptable, but it works and developers have to realize at some point that they are adults and responsible for their own futures. If a developer goes off and does something, and it works out better than what you had in mind, so what? As long as the goals were met and the work won't impede future development you're in great shape. I frequently let two competing approaches develop in parallel for a short time so that the team really understands the benefits and detriments of different approaches. If someone isn't working out, terminate their employment quickly. Do not let the problem fester.
-
I received a newsletter today with a tip on dealing with passive aggressive colleagues: It can be incredibly frustrating when a co-worker agrees with a plan of action, only to go off and do his own thing. This type of sabotage is all too common and can make it difficult to achieve your goals. When you have a co-worker who says one thing and does another, try this: 1. Give feedback. Explain to your co-worker what you're seeing and experiencing. Describe the impact of his behavior on you and provide suggestions for how he might change. 2. Focus on work, not the person. You need to get the work done despite your peer's style, so don't waste time wishing he would change. Concentrate on completing the work instead. 3. Ask for commitment. At the end of a meeting ask everyone (not just the troublemaker) to reiterate what they are going to do and by when. Sometimes peer pressure can keep even the most passive-aggressive person on task. My experience in this is that if I did that, the passive aggressive behaviour would simply become aggressive behaviour. I can't see this advice being worth the electrons that sent it. What's your experience in this kind of thing?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Passive-aggressive is quite common amongst developers because most of them think they know best! One tactic I've seen used to really good effect was to appeal to the person's vanity. Along the lines of "you're being asked to do this task because your the best at it".
-
All kidding aside, I have found that compensation works as a great lever to achieve the desired results. If developers were compensated on what they produce, they focus on getting the job done. The historical method of setting a fixed salary works to attract the least common denominator "Wally" types who will go off and play with some bright shiny toy instead of getting the work done that makes the company money. That being said, there must also be time to play with new technologies which is structured into the system of compensation. In the end, friction causing and unproductive members of a team compensated in this way find their own path out the door. Side benefit is that it can save you mountain of H.R. paperwork. I'm not pitching that this solution is perfect, but when the actions at work affect the amount of money a resource sees in their paycheck the focus is on completing the work the company needs. (Shameless plug, but this is addressed in detail in my book Agile Development & Business Goals.) It sounds ruthless, and to some it is not acceptable, but it works and developers have to realize at some point that they are adults and responsible for their own futures. If a developer goes off and does something, and it works out better than what you had in mind, so what? As long as the goals were met and the work won't impede future development you're in great shape. I frequently let two competing approaches develop in parallel for a short time so that the team really understands the benefits and detriments of different approaches. If someone isn't working out, terminate their employment quickly. Do not let the problem fester.
-
Number1 should be changed to this: 1. Give feedback. Tell him that if he doesn't perform the assigned work in the manner described, he will be fired. and then, there's item #4: 4) Take him on a field trip to a local shooting range. Mention that you go to the range whenever you need to "blow off steam" when an employee doesn't perform as expected. On the way back to the office, ask him how he thinks he's performing.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997modified on Wednesday, February 16, 2011 8:17 AM
works as long as the cohort isn't carrying concealed.
-
I received a newsletter today with a tip on dealing with passive aggressive colleagues: It can be incredibly frustrating when a co-worker agrees with a plan of action, only to go off and do his own thing. This type of sabotage is all too common and can make it difficult to achieve your goals. When you have a co-worker who says one thing and does another, try this: 1. Give feedback. Explain to your co-worker what you're seeing and experiencing. Describe the impact of his behavior on you and provide suggestions for how he might change. 2. Focus on work, not the person. You need to get the work done despite your peer's style, so don't waste time wishing he would change. Concentrate on completing the work instead. 3. Ask for commitment. At the end of a meeting ask everyone (not just the troublemaker) to reiterate what they are going to do and by when. Sometimes peer pressure can keep even the most passive-aggressive person on task. My experience in this is that if I did that, the passive aggressive behaviour would simply become aggressive behaviour. I can't see this advice being worth the electrons that sent it. What's your experience in this kind of thing?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
What if the passive/aggressive is me. I work in a very small company that develops software. Mind you, I am not talking about a collective here. This is between me and my boss micro-managing me at atomic level. A boss who is asking me to write the code in such a way that the people supporting our app would understand the code (read "dumb down" the code), or who asked me to consult him before doing anything in an "unusual fashion". You know what is unusual for him: properties - yes, the things with the getter and setter. Other unusual things: encapsulation, aggregation or composition, xml comments (they need not be xml and need to be the underneath the method signature) ... and many other things we don't have the time but I hope you got the ideea. So again it is only between him and me beacuse this is how he chose to do things. He rejects meetings where the collective mind could come up with something that he doesn't like. We don't have meeting for the programmers so it is basically a dictatorship regime. He asked me to not use properties because they are weird and hide functionality in the getter and setter and people could miss it when troubleshooting.:confused: Anyway, enough with this. Some of you may still want to lapidate me because I am the troublemaker, some will just pity me. I agree with the second bunch but I was and I am just stuck for now with this situation (I am not getting into details but I am working towards freeing myself). So, yes, I sometimes agree with my superior and when I code I change stuff slightly. I change by encapsulating by making the code more organized by reducing methods spanning 8 display screens to what they should be ... doing stuff the modern way and not necessarily for feeling better about myself but because it is more efficient for the company. It is better for everybody and I have plenty of people agreeing with me so I continue to do it even though I am the only one crazy enough. Just to be clear, what is agreed in a collective of peers after everybody spoke his mind I would follow 100%. That would be my word given to people who are my peers and respect me for what I can bring to the table not some bully like my boss. Anyway, I hope I will get there soon, a place where I don't have to fight to use "lambda expresions" or "extension methods" or ... properties and where I don't have to hide to do good. Can you see my perspective?
sly
-
A trouble maker is a trouble maker and usually will never change. I think you are spot on with the "aggressive behavior" bit. I would also throw in resentment as well from the trouble maker. I agree with Dave. If they don't shape up, then they ship out.
The "Shape up or ship out" approach may solve the problem of dealing with a slacker but you also very well may be cutting off your nose to spit your face to use a common term. The "shape up or ship out" method, while effective is also not very smart. You may get rid of your problem but you may also in the process lessen the effectiveness of your output. What if the trouble maker could be doing more and or better than non-troublemakers if only X weren't going on? Perhaps the trouble maker actions arise from something at work that you don’t know about and because of your shape up or ship out attitude you don’t bother to look into and so you ending up firing someone who later on at a competitor turns out to be the worker of the year now that they’ve been moved to an environment that doesn't have the problem that produced the trouble-maker like behavior in the first place? I'm not saying that for a majority of the cases the trouble-maker is most likely a problem and needs to go. What I’m saying is that taking the attitude of “shape up or ship out” is not only poor management skills but it’s also a sign of an aggressive control personality which in itself leads to poor management. I’ve managed people before and I know how hard it is and never desire to do it again. I prefer solving problems then figuring out people.
-
On the subject on "compensation" there used to be bonus schemes in operation for IT projects. They were a great motivator, but I've haven't come across one in a long while.
The system I use for compensation is a little different than some future promise of a "bonus". First, twice a quarter representatives from the business and the development staff physically sign a document to enumerate what is to be developed during the iteration. This forces the business side to clearly articulate and prioritize the needs. The first week of each iteration is when this negotiation takes place. Second, bonuses are paid as soon as possible after the iteration ends and not at until the end of the year (iteration ends mid-month, then the bonus is paid at the end of the month). This is baked into the compensation and not based on a whim at some later date. Point is, if the business is telling the software development group what is important (and they are honest about it), success follows. As software development happens (well) ahead of a product roll-out, basing a developers compensation on sales (6-12 months or more in the future) does not tie successful development efforts to the future sales. Base pay is reasonable; no one would starve if the goals are not met and a bonus is not paid. Bonus compensation typically ranges from 10-20% of overall compensation. At the end, if all development goals are met, total compensation is above market. Businesses use incentive pay, MBOs (management by objective), etc., for positions for which they expect results. Why doesn’t this mentality cover software development?
-
I received a newsletter today with a tip on dealing with passive aggressive colleagues: It can be incredibly frustrating when a co-worker agrees with a plan of action, only to go off and do his own thing. This type of sabotage is all too common and can make it difficult to achieve your goals. When you have a co-worker who says one thing and does another, try this: 1. Give feedback. Explain to your co-worker what you're seeing and experiencing. Describe the impact of his behavior on you and provide suggestions for how he might change. 2. Focus on work, not the person. You need to get the work done despite your peer's style, so don't waste time wishing he would change. Concentrate on completing the work instead. 3. Ask for commitment. At the end of a meeting ask everyone (not just the troublemaker) to reiterate what they are going to do and by when. Sometimes peer pressure can keep even the most passive-aggressive person on task. My experience in this is that if I did that, the passive aggressive behaviour would simply become aggressive behaviour. I can't see this advice being worth the electrons that sent it. What's your experience in this kind of thing?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
The whole point of passive-aggression is to make confrontation go away without doing the work. If you take that tool away, then either the colleague has to do what he commits to, or his failure becomes obvious to everybody, including the folks who make hiring and firing decisions. Either way, it should focus attention on the behavior. There is another solution; a passive-aggressive solution. Grit your teeth while looking for new work. If you have a non-worker on the team and management isn't doing anything about it, then you have at least two frustrating problems, and very probably more. A perceptive person such as yourself has more choices.
-
I received a newsletter today with a tip on dealing with passive aggressive colleagues: It can be incredibly frustrating when a co-worker agrees with a plan of action, only to go off and do his own thing. This type of sabotage is all too common and can make it difficult to achieve your goals. When you have a co-worker who says one thing and does another, try this: 1. Give feedback. Explain to your co-worker what you're seeing and experiencing. Describe the impact of his behavior on you and provide suggestions for how he might change. 2. Focus on work, not the person. You need to get the work done despite your peer's style, so don't waste time wishing he would change. Concentrate on completing the work instead. 3. Ask for commitment. At the end of a meeting ask everyone (not just the troublemaker) to reiterate what they are going to do and by when. Sometimes peer pressure can keep even the most passive-aggressive person on task. My experience in this is that if I did that, the passive aggressive behaviour would simply become aggressive behaviour. I can't see this advice being worth the electrons that sent it. What's your experience in this kind of thing?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Think about the source of the behaviour. It might not be what you think. The behaviour creates a symptom that makes it appear as though they are simply being difficult and own their own path. However, generally passive aggressive behaviour comes from a lack of self confidence and insecurities. They probably were not socialised properly as puppies.. lol The person may not have the skills for the social manners required for group discussions or know how to get their ideas across to others in a way they are understood, which would create frustration for themselves which turns into inpatients and a behaviour that is somewhat antisocial, which of course is where the problem started. The question is, do you tolerate it or try to work with the person in a way that will give you the best result. To approach it with a normal management style of, this is what I expect from you, this is what you must give to the team will probably just leave them in a situation where they feel more insecure and more of an outcast which is why approaching it that way would make it seem like the passive aggressive has simply turned to aggressive. This behaviour is very common in the world of software development. How many of you NON IT friends care about your technical ramblings? Try talking software development to them and see how quickly they run.. haha What do I base these things on. 1. At one stage at a previous employer, relationships got so bad that we got to experience classes in personality, behaviour and conflict resolution. 2. My sister is a qualified in this field, also has an business IT degree. Our father was a programmer, I am a programmer and she did a degree in IT while still working out what she really wanted to do. Ask her and us IT people all have borderline personality disorders. (generalising of course)
-
works as long as the cohort isn't carrying concealed.
What's wrong with concealed carry? I'd like to see everyone carrying, all the time. Regardless, you should always treat someone as if they are packing; which really means professionally and with respect at all times anyway. Open doors for women and help old ladies across the street too. :)
-
I received a newsletter today with a tip on dealing with passive aggressive colleagues: It can be incredibly frustrating when a co-worker agrees with a plan of action, only to go off and do his own thing. This type of sabotage is all too common and can make it difficult to achieve your goals. When you have a co-worker who says one thing and does another, try this: 1. Give feedback. Explain to your co-worker what you're seeing and experiencing. Describe the impact of his behavior on you and provide suggestions for how he might change. 2. Focus on work, not the person. You need to get the work done despite your peer's style, so don't waste time wishing he would change. Concentrate on completing the work instead. 3. Ask for commitment. At the end of a meeting ask everyone (not just the troublemaker) to reiterate what they are going to do and by when. Sometimes peer pressure can keep even the most passive-aggressive person on task. My experience in this is that if I did that, the passive aggressive behaviour would simply become aggressive behaviour. I can't see this advice being worth the electrons that sent it. What's your experience in this kind of thing?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
It's important to recognise that there's a spectrum of aggression, from being a bit grumpy sometimes to actively sabotaging and bullying other coworkers and basically acting like a sociopath. I've been lucky enough never to (knowingly) encounter the last type, but of course I've met people who can barely contain their disdain when they disagree with something you say. So strategies for sorting out the problem will vary wildly depending on the situation at hand. For anyone considered persistently toxic or worse, letting them go immediately might be the best solution. Good people often leave jobs to get away from toxic bullying coworkers - it completely destroys the working environment. If anyone ever resigns and says "I cannot work with X anymore", take it seriously and investigate in depth.
-
I see the subtle humor of your question, but I think it's gonna take most of the folks here a couple minutes to get it. :)
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
What if the passive/aggressive is me. I work in a very small company that develops software. Mind you, I am not talking about a collective here. This is between me and my boss micro-managing me at atomic level. A boss who is asking me to write the code in such a way that the people supporting our app would understand the code (read "dumb down" the code), or who asked me to consult him before doing anything in an "unusual fashion". You know what is unusual for him: properties - yes, the things with the getter and setter. Other unusual things: encapsulation, aggregation or composition, xml comments (they need not be xml and need to be the underneath the method signature) ... and many other things we don't have the time but I hope you got the ideea. So again it is only between him and me beacuse this is how he chose to do things. He rejects meetings where the collective mind could come up with something that he doesn't like. We don't have meeting for the programmers so it is basically a dictatorship regime. He asked me to not use properties because they are weird and hide functionality in the getter and setter and people could miss it when troubleshooting.:confused: Anyway, enough with this. Some of you may still want to lapidate me because I am the troublemaker, some will just pity me. I agree with the second bunch but I was and I am just stuck for now with this situation (I am not getting into details but I am working towards freeing myself). So, yes, I sometimes agree with my superior and when I code I change stuff slightly. I change by encapsulating by making the code more organized by reducing methods spanning 8 display screens to what they should be ... doing stuff the modern way and not necessarily for feeling better about myself but because it is more efficient for the company. It is better for everybody and I have plenty of people agreeing with me so I continue to do it even though I am the only one crazy enough. Just to be clear, what is agreed in a collective of peers after everybody spoke his mind I would follow 100%. That would be my word given to people who are my peers and respect me for what I can bring to the table not some bully like my boss. Anyway, I hope I will get there soon, a place where I don't have to fight to use "lambda expresions" or "extension methods" or ... properties and where I don't have to hide to do good. Can you see my perspective?
sly
I've worked with managers that I've respected and with idiots. Luckily the latter are few and far between.
mirceaion wrote:
not use properties because they are weird and hide functionality
Obviously you are stuck with the latter. My condolences. Well, at least he isn't telling you to not make any comments because they don't do anything, and you are wasting your time making them. It's unfortunate that he doesn't have a clue about what modern languages can do for everyone and isn't interested in learning about it either. I think I would be missing "passive" on my part.
-
I received a newsletter today with a tip on dealing with passive aggressive colleagues: It can be incredibly frustrating when a co-worker agrees with a plan of action, only to go off and do his own thing. This type of sabotage is all too common and can make it difficult to achieve your goals. When you have a co-worker who says one thing and does another, try this: 1. Give feedback. Explain to your co-worker what you're seeing and experiencing. Describe the impact of his behavior on you and provide suggestions for how he might change. 2. Focus on work, not the person. You need to get the work done despite your peer's style, so don't waste time wishing he would change. Concentrate on completing the work instead. 3. Ask for commitment. At the end of a meeting ask everyone (not just the troublemaker) to reiterate what they are going to do and by when. Sometimes peer pressure can keep even the most passive-aggressive person on task. My experience in this is that if I did that, the passive aggressive behaviour would simply become aggressive behaviour. I can't see this advice being worth the electrons that sent it. What's your experience in this kind of thing?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Chris Maunder wrote:
1. Give feedback.
This is absolutely required when you intend to fire someone. You first start out by giving feedback on their behaviour that has to change. They do it, then great! You succeeded in getting someone who is willing to colabborate and work together to get a good result. They don't do it. You start documenting their failures. Explain to them you are doing this in order to expedite their removal when they continue to fail. The end result: They get to continue being aggressive. Elsewhere. Win-Win. You both get what you want. They get to be aggressive. You get a team willing to work together to get the results you want.
Chris Maunder wrote:
Focus on work, not the person
Great advice. Don't let it become a personality clash situation. Keep it directed on performance. This will aid in the process of firing a non-performer.
Chris Maunder wrote:
Ask for commitment.
More great advice. You can document all the cases where they committed to doing something and then failed to do so. After hearing over and over again that he commits to doing something and then fails to do it over and over, the whole team will be happy to see his sorry "as" leave.