How to deal with people who are jerks
Christian recently asked, in a comment on how project managers get power:
How did you work with those infamous programmer-jerks? How did you handle rough inner team situations?
The best place to start is empathy. Why is someone acting like a jerk? There are basic psychological reasons for this: Either they are insecure, unhappy, or angry about something.
Ok, there is a fourth reason, that they are psychopathic hell spawn put on the earth to torture all living things in a 10 foot radius, especially you, but lets assume that’s not the case for a moment.
In all three cases it’s possible they have good reasons for behaving like a jerk. Perhaps they are angry at upper management for the same reasons you are, but they see you as part of management (which, if you’re a PM, you are). Or maybe their last project manager was incompetent. Who knows? Not you. You don’t have a clue.
Odds are good it has nothing to do with you – it has to do with how they feel about what’s going on around them. Starting with a little empathy opens the door to finding a solution. If you start with “Fred is a jerk so I will treat him like one” you are likely perpetuating his reasons for behaving like a jerk, and everyone loses.
That said, there are four assets you have: charm, ability, roles and allies.
- Charm to connect. Being likable goes a long way in dealing with people. I don’t mean false niceness or being a cheezeball. I mean using your sense of humor, your natural generosity, your shared interests with someone to establish some basis for positive interaction with another person. It could be almost anything, but look for it. Good morale events help make these connections happen. If you happen to like Metallica, or Porsches, and they do, you now have something positive to talk about where it’s safe for everyone to share and connect.
- Demonstrate your ability to help . If they love making great software, if that’s really what they want, then you just need to show you can help. Even if it’s just helping meetings run better, or eliminating stupid annoyances in how decisions get made, defusing politics, reducing meetings, etc. There are a thousand easy things a decent PM can do that the programmer will noticeably benefit from. Start by asking “what can I do to make you more effective? more productive?” And listen to their answer. Do some of what they ask, come back and ask if it helped. Even if it’s a small thing, you’ve now built a tiny basis of respect for how you can help them.
- Agree on the roles you both play. More than half the time PMs suffer because people do not understand what the PM is doing. What you need to do is sit down with the programmer and make three lists: what I do (write specs), what you do (write code), what we both do together (triage bugs). Invariably there will be disagreements as to who does what work, but by listing them you’ll find all the sore spots in your working relationship. If you strongly disagree on roles, and he thinks you should wash his car, you should be able to go to your respective bosses and ask for clarification.
- Get help from your Allies. Which programmers do you get along with best? These are your allies. Ask them for input on working with Fred. Get their perspective on the frustrations on being a programmer in your organization. You may be able to see Fred in a different light. Have other PMs worked with Fred? What insights do they have?
Of course if after investing some of this energy you decide Fred is, in fact, demon spawn hellbent on destroying all positive energy in the universe, talk to your boss. If Fred is as bad as you say, others will complain and it will become your managers job to solve the problem (fire Fred, move him to more isolated work, get him a therapist).
Most of the time the real problem is people not sharing goals, and not listening to each other. Two things that your average project manager should be good at identifying and resolving.
See also:
- Why project managers get no respect
- Top ten reasons managers become assholes
- Asshole driven development (Now with 285 comments)
You mean fourth rather than forth
Good catch – fixed!
So what if you’re the programmer and you do not have a project manager?
What if your regular manager doesn’t write specs but instead hand waves and says “something like the thing we did before, but better” and doesn’t let you talk to the user?
As a programmer, though, the project manager absolutely has to respect the programmer’s time. In my experience, one hour meeting are never worth the time. If the thing can’t be said in 15 minutes, it can’t be said in an hour.
You’re right that the project manager needs to make himself useful. If all the project manager does is make the job be harder, then the programmer will resent her.
The role of programmer is not to be a social, personable person. To be effective, a programmer has to think in absolute logic terms. It’s true or it’s false. And it has to be either true or false. “It depends” isn’t a computing term. When programmer ask a question and people answer: “it depends”, that’s not a real answer. A real answer is true, false, or a value (number, string). Something that can be measured to be either the expected result or not. The reality is that programmers are very good at programming for the very reason that they are highly logical creatures. That’s why most non-programmers get frustrated. For them “it depends” is an acceptable answer. For programmers, however, it means the question hasn’t been fully explored. Which means that to interact with programmers, non-programmers need to think deeply and not answer with blanket statements. They need to answer with very concrete and verifiable statements.
Also, project managers think they have a hard time dealing with programmers. They should try dealing with computers sometimes. Those machines need very careful hand-holding.
Christopher: Good points. Although I think the stereotypes have limited value – some programmers are good as thinking both logically and intuitively, as are some managers. Smart people by definition recognize when one way of thinking helps or hurts the solving of a particular problem, whether they like thinking that way or not.
Anyway, regarding your situation:
The first thing to try if you’re a programmer who works for a manager that hand waves is to say this: “Hey. I have a request that will make me more productive and possibly finish ahead of schedule. Let me try talking to the customer this once. If it doesn’t help, I won’t do it again. But if we agree that it does help, even if a small amount, I’d like us to discuss letting me do it next time as well.”
Pow. You’ve now promised him a better result, something he should very much want, in exchange for what you want, a simple change. If he says yes, you’d better live up to your end of the promise. When you do, you’ve earned credibility points. And in the future the right to ask for bigger changes, in exchange for bigger improvements in your performance.
If he says no, I’d try again on another request. If you have several examples and can prove he *always* says no, I’d look for another manager. He’s not actually interested in getting better results from you.
As I am getting laid off within 3 months, I think I’ll pass. However, I’ll keep that in mind for the next gig!
Christopher: Sorry to hear about that. Good luck on the next gig!
The role of programmer is not to be a social, personable person.
I really don’t agree with that. Programming these days is about being part of a team. If you don’t fit in with a team then you’re close to useless.
I’m not talking theoretically here, I’m talking from experience. I’ve seen amazingly strong programmers fail because their social skills suck, and I’ve seen sociable coders fail because their tech skills suck.
You need both. Tech skills aren’t enough.
+1 the modern developer is part analyst, part designer, part coder, part sys admin, part…well you get my point.
How about reframing this. Instead of “I am trying to work with a jerk,” try “I am having great difficulty working with a person who writes programs.”
Now I can ask myself all sorts of questions about myself (why do I think this person is difficult? why might I apply the “jerk” label to this person? What is this person doing that I dislike? etc).
I can answer questions about myself and do things about myself.
I dont think there are any jerk programmers. There are people who are jerks and those who are not.
Interdisciplinary squabble can be framed in many ways, but unfortunately its not useful information.
However, its been confirmed that people who are dealing with other people with the same level of experience in their respective fields get along much better than they would otherwise.
And simply put project management especially software project management is usually staffed by kiss ass bozos who have little or no skin in the game and who will go back to real estate when the time is right.
I have little to no respect for the software PM profession and until something changes, thats that.
footnote to earlier comment: the best PMs worthy of respect are ones who have 10 years or more of software engineering experience. Yes they exist and they do rock.
“what I do (write specs), what you do (write code), what we both do together (triage bugs). Invariably there will be disagreements as to who does what work”
I always though the PM job was to do three things (and in order)
– Get the project set-up
– Make the project move forward
– Finish it(including reflecting)
As a subcomponent sure it’s making sure the requirements are there(know) and making sure they are met. And yes the easiest way for a project manager is to jump into the role of requirements engineer. But depending on your project that might well not be the case – or the best way to go.
“What if your regular manager doesn’t write specs ” – imo that could be ok.
“but instead hand waves and says “something like the thing we did before, but better” and doesn’t let you talk to the user?”
– that kinda breaks making sure the project moves forward as important work doesn’t get done.
And with respect to that; the pm isn’t the only one who can talk to his manager.
“Which programmers do you get along with best? These are your allies.”
I would much rather label them as ‘easily available and valuable sources of information’ rather then allies as that kinda instills the us vs them culture. I’m sure you meant to say that but it didn’t have a nice flow to it. :)
I’ll go back to programming now..
Most of the PMs I’ve worked with have been pathetic morons barring one or two. This job involves marginal creativity and is certainly not management as far as I am concerned. PMs should not be paid more than 75% of the median salary for experienced developers. I’m sure there are some very good PMs out there, but they contribute only marginally to the finished product (if you count schedule jockeying as an intellectual activity).
“what I do (write specs), what you do (write code), what we both do together (triage bugs). Invariably there will be disagreements as to who does what work”
At my work, the people who write specs are not project managers, but product managers (a different PM).
But if you separate those things (specs and code), you are actually not getting the most out of your programmers. A programmer should be part of the process of creating a specification. It is them who know more about the technical restrictions anyway, and can also give valuable input.
There are those who hate the upper management which then makes them the pain the arse for PMs. But then, you’d have to put up with some developers who are way over their head and have absolutely no reason to be angry about. Guess there is. Insecurity, not concerning with management, but personal insecurity. This particular of programmer deserves a wake up call.
Project managers should definitely not write specifications.