4 ms·

How to deal with difficult people on software projects

69 points by fridek 8y ago

lsofzz 8y ago
I'd have loved to see categorised infosec folks in there as well :)
ykevinator 8y ago
Pleasantness is the most underrated quality in software hiring.
amelius 8y ago
If there is a "professor" among designers, then why isn't there one among developers?
- cachvico 8y ago
  That would be The Idealist, presumably.
mothsonasloth 8y ago
Am I a diva if I think DevOps people are getting in my way from doing what I want?
- jon-wood 8y ago
  I probably wouldn't say that, but I'd suggest that either you or your ops person could do with learning a bit of empathy and better communicating what problems you're each trying to solve. Someone who actually gets the concept of devops (the collaboration between dev and ops) should be able to articulate why they're asking for particular things to be done, and what benefits will come from it in terms of reliability and being able to analyse issues as they come up. Unless the ops person on the other side of this conversation is really bad they're unlikely to be asking you to do things just for the sake of it - there'll be a good reason, just as you have your reasons for wanting to do things your way. Devops is all about finding a middle ground between those two places, and improving life for everyone involved.
- mikekchar 8y ago
  No. But if you are writing software that can't be maintained in production by the team that's doing the maintenance, then you a falling short in a massive part of your job. There are lots of reasons to have difficulty working with DevOps people, but you really do have to work it out in order to provide the kind of value that your company needs. I have met people that just don't care about that. They are only interested in a fairly selfish pursuit of what they find compelling in programming. I guess one could portray that as being a "diva", but I think it's a lot more complex than that. In any case, there really isn't any room for that kind of thing if the teams wants to be successful. I've worked with people like that before and as the project inevitably dies, they are the first to blame other people. Which is sad because they are often very skillful and will have no trouble finding another group to help crash.
  - mlthoughts2018 8y ago
    This reads to me like someone who has never seen a project die due to being stymied by unreasonable delays and forced technical constraints coming from devops or central IT, usually for reasons of their own political control or job security. This is why the cycle gets repeated and repeated where you have to break devops rules to innovate in some way that is deeply required by your project, you do so with great maturity towards the security implications, costs, maintainability, etc., of your new tooling, and deliver the whole thing as proof that devops was hindering unnecessarily, thus basically forcing devops to accept your changes, which is a horribly antagonistic way for it all to work, but it just goes on. The problem occurs when devops no longer takes a customer service attitude towards developer teams, especially regarding how to incorporate new technologies into production. The developer teams are the experts of whether that new technology is the right cost effective choice for the project, and that needs to be respected by devops. Their job is to get it working in production or else find equivalent solutions that meet the properties identified by the development team as necessary. Unfortunately, devops tries to be involved early on almost like a consultant to constrain what choices can be considered at each step, risking that the company can’t benefit from the expertise of developer teams in identifying solutions.
    - mikekchar 8y ago
amelius 8y ago
What about the type of developer who thinks he's a competent UI designer?
- cachvico 8y ago
  ...but he's not? Don't give him UI design tasks. ...and he actually is? If there is room for such cross-competency roles in the team, let him shine. It'll give him great work satisfaction. And if there isn't, don't give him UI design tasks.
tw1010 8y ago
Ever considered the idea that boiling down people to archetypes might be a core reason you'd need to consult something like this in the first place?
- nocitrek 8y ago
  You cannot recognize any of those roles in your company? Really? I find this article hilarious because some of those archtypes are sitting next to me.
  - tw1010 8y ago
    Maybe things are different in the US (where maybe peoples personalities are extra rigid because self image and the concept of identity is so amplified), but the people I tend to interact with are usually much more subtle than this, and can easily shift from looking or acting like one archetype to another with a little empathetic communication, without me having to characterize them into a framwork, as an obstacle I need to systematically figure out a way around.
    - mlthoughts2018 8y ago
      I agree. When you’re seeking to characterize unpleasant people you work with as “the dictator” or “the diva”, maybe you should look in the mirror and see “the reductionist” and try empathizing with people who anger you and treating them like human beings for a minute first. What feedback would they say about you?
      - jibal 8y ago
        Talk about rigid ... it's humor.
        mlthoughts2018 8y ago
        Even if the site is, not all of the responses are. People really do think this way!
insickness 8y ago
Difficult people can potentially be far worse than having no one in their position. They may cast a cloud over every team meeting with a bad attitude. They can be a troll under the bridge, standing in the way of movement with excuses and a million reasons why it can't be done. Everyone on the team may end up walking on eggshells around that person, and end up doing everything they can to avoid interacting with them. It makes everyone else's job twice as hard.
gtirloni 8y ago
This should come with a big warning that it applies to people's current moods rather than having them in a fixed personality. There are extreme cases where someone is always an "Extreme Overestimator" but those are rare. People will often shift between all of this made up classifications depending on the circumstances, their goals, their past experiences, etc. It seems to be a nice tool to raise awareness for these potential states of mind but I wouldn't use it as an objective assessment of other people.
- jibal 8y ago
  For reasonable people who take it in the light-hearted manner that it was obviously intended, it doesn't need to come with warnings.
rjth 8y ago
There should be a Rockstar in each category (or it would be just easier to remove it from the developer category).
xbdev 8y ago
The website is obviously humorous. On a more serious note, the most toxic developers are those who constantly talk about perceived signs of toxicity in other people. They are also the most unproductive ones and tend to form cliques.
mlthoughts2018 8y ago
Just looking through the Product Manager section, I find it telling that almost all entries are “low” risk to the project, particularly the Sales Liason. The ones with high risk are about vague requirements, changing requirements without increasing deadlines, or being a people pleaser. In practice, none of the six companies I’ve worked for has ever used anything other than vague requirements at all times for all teams, whatever gives the most fungibility to the product / sales side of the organization. Adding scope definitely requires amending deadlines, so I can agree with that, but a Sales Liason is low risk to the project? No way. It makes me question who is writing this and what their personal perspective is for choosing the taxonomy of risks, which in turn makes this whole thing seem childish to me and certainly not any kind of broadly applicable way of analyzing people at work or risks that are posed. Meanwhile, there is actual research literature that attempts to study things of a similar vein, e.g. https://static1.squarespace.com/static/55dcde36e4b0df55a96ab220/t/55e5f374e4b04539eab51172/1441133428448/GrantGinoHofmann_Reversing.pdf https://static1.squarespace.com/static/55dcde36e4b0df55a96ab...
newsbinator 8y ago
> The Distrusted: A Designer who has lost all credibility with the project team, leading to their UI requirements being ignored as they are deemed to be not in the products’ best interest.
bacro 8y ago
Well I think today I fit in The Extreme Overestimator, The Bull in the China Shop, The Rockstar and The Hostage Taker, is this normal? :S
- mal808 8y ago
  Ha, I'm the same, I was thinking I fit into all of those descriptions in some way or other.

69 points by fridek 8y ago

lsofzz 8y ago

I'd have loved to see categorised infosec folks in there as well :)

ykevinator 8y ago

Pleasantness is the most underrated quality in software hiring.

amelius 8y ago

If there is a "professor" among designers, then why isn't there one among developers?

cachvico 8y ago
That would be The Idealist, presumably.

mothsonasloth 8y ago

Am I a diva if I think DevOps people are getting in my way from doing what I want?

jon-wood 8y ago
I probably wouldn't say that, but I'd suggest that either you or your ops person could do with learning a bit of empathy and better communicating what problems you're each trying to solve. Someone who actually gets the concept of devops (the collaboration between dev and ops) should be able to articulate why they're asking for particular things to be done, and what benefits will come from it in terms of reliability and being able to analyse issues as they come up. Unless the ops person on the other side of this conversation is really bad they're unlikely to be asking you to do things just for the sake of it - there'll be a good reason, just as you have your reasons for wanting to do things your way. Devops is all about finding a middle ground between those two places, and improving life for everyone involved.
mikekchar 8y ago
No. But if you are writing software that can't be maintained in production by the team that's doing the maintenance, then you a falling short in a massive part of your job. There are lots of reasons to have difficulty working with DevOps people, but you really do have to work it out in order to provide the kind of value that your company needs. I have met people that just don't care about that. They are only interested in a fairly selfish pursuit of what they find compelling in programming. I guess one could portray that as being a "diva", but I think it's a lot more complex than that. In any case, there really isn't any room for that kind of thing if the teams wants to be successful. I've worked with people like that before and as the project inevitably dies, they are the first to blame other people. Which is sad because they are often very skillful and will have no trouble finding another group to help crash.
- mlthoughts2018 8y ago
  This reads to me like someone who has never seen a project die due to being stymied by unreasonable delays and forced technical constraints coming from devops or central IT, usually for reasons of their own political control or job security. This is why the cycle gets repeated and repeated where you have to break devops rules to innovate in some way that is deeply required by your project, you do so with great maturity towards the security implications, costs, maintainability, etc., of your new tooling, and deliver the whole thing as proof that devops was hindering unnecessarily, thus basically forcing devops to accept your changes, which is a horribly antagonistic way for it all to work, but it just goes on. The problem occurs when devops no longer takes a customer service attitude towards developer teams, especially regarding how to incorporate new technologies into production. The developer teams are the experts of whether that new technology is the right cost effective choice for the project, and that needs to be respected by devops. Their job is to get it working in production or else find equivalent solutions that meet the properties identified by the development team as necessary. Unfortunately, devops tries to be involved early on almost like a consultant to constrain what choices can be considered at each step, risking that the company can’t benefit from the expertise of developer teams in identifying solutions.
  - mikekchar 8y ago

amelius 8y ago

What about the type of developer who thinks he's a competent UI designer?

cachvico 8y ago
...but he's not? Don't give him UI design tasks. ...and he actually is? If there is room for such cross-competency roles in the team, let him shine. It'll give him great work satisfaction. And if there isn't, don't give him UI design tasks.

tw1010 8y ago

Ever considered the idea that boiling down people to archetypes might be a core reason you'd need to consult something like this in the first place?

nocitrek 8y ago
You cannot recognize any of those roles in your company? Really? I find this article hilarious because some of those archtypes are sitting next to me.
- tw1010 8y ago
  Maybe things are different in the US (where maybe peoples personalities are extra rigid because self image and the concept of identity is so amplified), but the people I tend to interact with are usually much more subtle than this, and can easily shift from looking or acting like one archetype to another with a little empathetic communication, without me having to characterize them into a framwork, as an obstacle I need to systematically figure out a way around.
  - mlthoughts2018 8y ago
    I agree. When you’re seeking to characterize unpleasant people you work with as “the dictator” or “the diva”, maybe you should look in the mirror and see “the reductionist” and try empathizing with people who anger you and treating them like human beings for a minute first. What feedback would they say about you?
    - jibal 8y ago
      Talk about rigid ... it's humor.
      - mlthoughts2018 8y ago
        Even if the site is, not all of the responses are. People really do think this way!

insickness 8y ago

Difficult people can potentially be far worse than having no one in their position. They may cast a cloud over every team meeting with a bad attitude. They can be a troll under the bridge, standing in the way of movement with excuses and a million reasons why it can't be done. Everyone on the team may end up walking on eggshells around that person, and end up doing everything they can to avoid interacting with them. It makes everyone else's job twice as hard.

gtirloni 8y ago

This should come with a big warning that it applies to people's current moods rather than having them in a fixed personality. There are extreme cases where someone is always an "Extreme Overestimator" but those are rare. People will often shift between all of this made up classifications depending on the circumstances, their goals, their past experiences, etc. It seems to be a nice tool to raise awareness for these potential states of mind but I wouldn't use it as an objective assessment of other people.

jibal 8y ago
For reasonable people who take it in the light-hearted manner that it was obviously intended, it doesn't need to come with warnings.

rjth 8y ago

There should be a Rockstar in each category (or it would be just easier to remove it from the developer category).

xbdev 8y ago

The website is obviously humorous. On a more serious note, the most toxic developers are those who constantly talk about perceived signs of toxicity in other people. They are also the most unproductive ones and tend to form cliques.

mlthoughts2018 8y ago

Just looking through the Product Manager section, I find it telling that almost all entries are “low” risk to the project, particularly the Sales Liason. The ones with high risk are about vague requirements, changing requirements without increasing deadlines, or being a people pleaser. In practice, none of the six companies I’ve worked for has ever used anything other than vague requirements at all times for all teams, whatever gives the most fungibility to the product / sales side of the organization. Adding scope definitely requires amending deadlines, so I can agree with that, but a Sales Liason is low risk to the project? No way. It makes me question who is writing this and what their personal perspective is for choosing the taxonomy of risks, which in turn makes this whole thing seem childish to me and certainly not any kind of broadly applicable way of analyzing people at work or risks that are posed. Meanwhile, there is actual research literature that attempts to study things of a similar vein, e.g. https://static1.squarespace.com/static/55dcde36e4b0df55a96ab220/t/55e5f374e4b04539eab51172/1441133428448/GrantGinoHofmann_Reversing.pdf https://static1.squarespace.com/static/55dcde36e4b0df55a96ab...

newsbinator 8y ago

> The Distrusted: A Designer who has lost all credibility with the project team, leading to their UI requirements being ignored as they are deemed to be not in the products’ best interest.

bacro 8y ago

Well I think today I fit in The Extreme Overestimator, The Bull in the China Shop, The Rockstar and The Hostage Taker, is this normal? :S

mal808 8y ago
Ha, I'm the same, I was thinking I fit into all of those descriptions in some way or other.