
How to deal with difficult people on software projects - fridek
https://people.neilon.software/
======
xbdev
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.

------
tw1010
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
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
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
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
Talk about rigid ... it's humor.

~~~
manicdee
Is it a humourous address to the issue with some real options for resolution
such as introspection, or a humourous pisstakecwhich does nothing more than
reinforce that people can be pigeonholed and you can deal with them without
understanding what makes them behave a particular way towards you?

------
insickness
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.

------
ykevinator
Pleasantness is the most underrated quality in software hiring.

------
gtirloni
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
For reasonable people who take it in the light-hearted manner that it was
obviously intended, it doesn't need to come with warnings.

------
mlthoughts2018
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/55dcde36e4b0df55a96ab...](https://static1.squarespace.com/static/55dcde36e4b0df55a96ab220/t/55e5f374e4b04539eab51172/1441133428448/GrantGinoHofmann_Reversing.pdf)

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

~~~
cachvico
That would be The Idealist, presumably.

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

~~~
mikekchar
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
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
If you build something that DevOps can use, then there is no problem. I can't
tell you how to navigate the waters from the start of the project to success
-- that's all dependent upon the people involved and requires a fair amount of
people skills to do well. On the other hand I've seen enough "convenient for
developers, impossible for devops solutions" to know that sometimes developers
lack the background to get it right. Couple that with a bit of hubris and you
get the classic, "Well, I did _my_ job. It's not my fault that devops are
clueless and can't do their job".

I'm not in any way saying that this is what you do. How could I know one way
or the other? I'm just saying that it's a pretty common occurrence in my
fairly extensive experience (hint: all my hair has been grey for a decade and
I _still_ work as a programmer ;-) ).

Thus my answer: No, having problems with DevOps is not being a "diva".
Ignoring the problems of DevOps so that you can have things easier for you
_is_ an unfortunately common, but none-the-less disastrous approach. Are there
teams where DevOps are inflexible at the cost of everybody else involved? Of
course, that's common too: hence the "No".

------
newsbinator
> 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
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
Ha, I'm the same, I was thinking I fit into all of those descriptions in some
way or other.

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

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

