How to deal with difficult people on software projects

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.

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.

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.

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

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