How to Deal with Difficult People on Software Projects

You can explore these Problem Personalities with the visual map.

Product Managers

  • The People Pleaser – A Product Manager who believes their core job responsibility is to seek concessions and compromises between the development teams and stakeholders.
  • The Scope Wiggler – A Product Manager who bypasses change control and impact analysis by presenting a big requirements change as a series of small changes distributed over time.
  • The Patent Author – A Product Manager who produces such a high volume of requirements documentation that it creates a barrier to adapting to change, as the documentation must be kept up to date.
  • The Napkin Sketcher – A Product Manager whose requirements are so vague that the development team must fill in the gaps, only to be told their decisions were incorrect.
  • The Executive Assistant – A Product Manager who only documents what the stakeholders have asked for, but denies access to the stakeholders, such that requirements cannot be negotiated.
  • The Sales Liaison – A Product Manager who is only concerned with meeting the demands of the sales team, giving no thought to a holistic product vision.
  • The Dictator – A Product Manager that rejects any idea that did not come from them.
  • The Scope Creeper – A Product Manager who increases the scope of a project while keeping the delivery date the same.

Designers

  • The Note Taker – A Designer who is relegated to doing nothing more than documenting the ideas of others.
  • The Disenfranchised – A Designer who feels they are powerless to influence the design of the project, and therefore are not providing design direction.
  • The Artist – A Designer who is more concerned with how the product looks and feels than if it does anything useful for the end user.
  • The Professor – A Designer so committed to the science and theory of user interface design, that they ignore the UI requirements coming from the stakeholders.
  • 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.
  • The Blueprinter – A Designer who specifies every detail of the UI to such a fine level of specification that there is no leeway for developers to choose alternative implementations that can reduce development time.

Project Managers

  • The Meeting Scheduler – A Project Manager who believes all project problems are caused through a lack of communication and coordination, and that copious amounts of meetings are the solution.
  • The Statistician – A Project Manager who is only concerned with establishing lists and checking items off, regardless of what those items are.
  • The Delusional – A Project Manager so out of touch with the realities of the project, that they are representing falsehoods to the stakeholders.
  • The Pessimist – A Project Manager that has concluded that the project will fail, cannot be convinced otherwise, and is vocal about their belief.
  • The Optimist – A Project Manager that has convinced themselves of project success regardless of evidence to the contrary.
  • The Cheerleader – A Project Manager who focuses on making sure everyone on the project is happy, rather than if the project will be successful.
  • The Tyrant – A Project Manager that treats project members with contempt in the name of motivating them to work harder.
  • The Process Obsessed – A Project Manager so obsessed with process, they forget their job is to help the project be successful.
  • The Hoverer – A Project Manager who believes that constantly asking for status keeps people focused on completing their tasks.

Development Managers

  • The Formerly Technical – A Development Manager who was a software developer as some point in their past, leading them to believe their technical opinion in still relevant with today’s technology.
  • The Non-Technical – A Development Manager with no technical knowledge, and are therefore out of their depth when managing developers.
  • The Ladder Climber – A Development Manager with ambitions to advance their career, and sees their development team only as a means to do so.
  • The Peacemaker – A Development Manager who believes arguments are counterproductive, and therefore works to suppress debate of any kind.
  • The Wants-to-be-Technical – A Development Manager who wishes to return to the life of coding, after discovering that the life of a development manager is not for them.

Developers

  • The Diva – A Developer so convinced of their irreplaceability that they adopt an attitude of arrogance that makes them impossible to manage.
  • The Idealist – A Developer is so obsessed with achieving architectural elegance and code perfection that they forget their job is to add business value.
  • The Rock Star – A Developer so talented, so productive, so essential that if they were to leave, the entire project would collapse.
  • The Aspiring Manager – A Developer who has decided that to escape the difficulties having to code, their career path should be one of management.
  • The Hostage Taker – A Developer who has written a piece of mission-critical software, and refuses to let any other developer work on it so that they may remain indispensable.
  • The Bull in the China Shop – A Developer so focused on getting the work done, that they completely forgo any notion of quality.
  • The Incompetent – A Developer who lacks the intelligence or skill to do the job of writing software.
  • The Extreme Underestimator – A Developer who consistently massively underestimates the amount of time needed to complete a task.
  • The Extreme Overestimator – A Developer who has become so afraid of missing their deadlines that they ask for as much additional time as they can get away with.
  • The Soldier – A Developer who does exactly what they are told without questions, regardless if it is the right thing to do.
  • The Technology Enamored – A Developer that is so excited to try new technologies that they will introduce them into the project regardless of if they are appropriate.
  • The Legacy Maintainer – A Developer whose only capability is the maintenance of legacy software, and therefore is incapable of taking on new work.

Quality Assurance

  • The Firehose – A QA who floods the developers with so many bug reports so quickly that they overwhelm the development team with a backlog of bugs they will never finishing working through.
  • The Blamer – A QA who accuses the developers of not testing their work whenever they find a bug.
  • The Alarmist – A QA who has declared that the entire product is of an unacceptable level of quality based only on their first impressions.
  • The Scientist – A QA who spends the majority of time documenting bugs, rather than finding new bugs.
  • The Misleader – A QA who often reports bugs inaccurately, leading the developer down the wrong path as they attempt to reproduce and fix the problem.
  • The Downtrodden – A QA who has been beaten down by developers to the point that they hardly report any bugs for fear of developer bullying.
  • The Random Clicker – A QA who looks for bugs by simply clicking on whatever they feel like.
  • The Flippant – A QA whose bug reports are so passive aggressive that developers interpret them as being rude.

 

30 thoughts on “How to Deal with Difficult People on Software Projects

  1. Hi Neil,

    I ran across your site, and subsequently this book after watching your talk on CoffeeScript vs TypeScript vs ES6. Super good talk by the way! Since this post didn’t have a date on it, I was curious to see if you had a time frame in mind that your book may be available. I am eager to grab a copy to share with the folks at work. Thanks.

    CD

  2. Enjoyed reflecting upon the ideas of these personality patterns. Something to keep in mind, for one’s self as well as the people working for them.

  3. Very insightful. Thank you.

    It would be nice to have a final description in each section that represents your ‘ideal’ for the role, but maybe it’s too situationally dependent.

    • I’m glad you liked it. I’m toying with the idea of wrapping this content in an actual book (Kindle & Audiobook). Talking about the ideal characteristics for each role could go in there. Then again, *this* was supposed to be an eBook, and I decided to release it on my blog for free. I’ll keep it in mind…and try to think of what my ideal would look like for each role. FWIW, my thought is that it’s not very situationally dependent.

  4. Cool stuff Neil!

    Wanted to ask: Were you heavily influenced by Robert Greene? I noticed some similarities between your work here and his books 48 Laws of Power, Art of Seduction, etc.

    • Thank you! Generally, I have been influenced by Robert Greene’s works, but it was a pure coincidence when I tallied them all up that there were 48 personalities. My biggest influence for Personality Patterns were the Jungian archetypes as expressed in Myers-Briggs tests.

    • Not forgotten, but definitely not represented. My suspicion is that your role might be in either operations or support? If so, I apologize for not being more comprehensive, but my exposure to those aspects of organizations is limited, and I did not (and do not) feel confident that I would do anything more than speculate. As I mentioned in another comment, I am thinking of creating a community driven process for submitting new archetypes, and that would be the system under while operations/support roles would be proposed.

    • I’ve served in all of these roles (as one tends to have to in startups), but most would say my core experience is as a software developer. I will openly admit that all of the descriptions are laden with my own perceptions, which explains (among other things) why I find so many problems with developers. “The Rockstar” developer – at least in my experience – is the only high-performer that can put the entire project at risk. If a high performer in other roles leaves their will be an impact, but the project tends to become less efficient, but not wrecked. The dangerous part about “The Rockstar” is they make the other developers lazy (something I have not directly observed in other roles), and are often the targets of poaching by other companies (whereby other roles are not as actively poached). All I can ask is forgiveness for the presence of my bias’, but hopefully they’re obvious enough such that my perspective can be taken with a grain of salt, rather than as something intended to be universally accurate.

    • This is the most common and recurrent questions I get asked about this analysis. It was actually the very first piece of feedback I got from the very first reviewer of the original draft (it started as a book). My answer to that reviewer is the same I’ve given ever since: I think it’s a reflection of my own personal bias’: I view people with the absence of problems as having no problems. As a case in point, in the “Are you a Dysfunctional Developer” quiz, it is possible to get a “No problems” result. The alternative doesn’t connect with my world view (whether it’s right or wrong). I tend to set my expectations very low for people I work with, and let them exceed those expectations. In that way, I’m never disappointed. I would imagine if someone who was less jaded on the industry wrote a similar book, it would focus on the positive rather than the negative, but I’ve too many battle scars from too many projects given to me by too many people to remember what it’s like to think of the best in people. I have played with the idea of creating a podcast series where I detail my experiences on software projects, so that a minimum people can say, “Wow…now I understand why Neil is so jaded”, but the wounds are still too fresh at this point in my life. Still, what would you think of a podcast series of that nature?

      • I was about to ask the exact same thing as Daniel and I agree with your analysis. I find the sum of your personal experiences. In addition, is really really hard to come up with a definition of what the word ‘best’ encompasses. Even developers with certain traits can be considered the worst in one industry and the very best in another.

        With that in mind, I would love to see a series about what is it that, from your point of view, constitutes a healthy project. Sometimes the problem is not the people, is the situation those persons were put into. From projects without metrics, to over-blown budgets, to one-man projects, to all-bleeding-edge teams the list can go on and on…

        Move from ‘what traits make you successful’ to ‘what success is supposed to look like’

  5. I just stumbled upon this site, and love it.

    I feel like you’re missing an entire horizontal here though, for the CTO office / architecture group. We have a variety of personas in the mix as well and they all directly influence a project (for the better or worse) 🙂

    • Thanks for the positive feedback – much appreciated! I am definitely picking up the generalized feedback of “You’re missing stuff”. For architects I can think of several missing archetypes, but I will confess that I am hesitant to put my thoughts on executives (especially CTO/CIOs) out there because I’m still in contact with most of the ones I’ve worked for. While I know their flaws, I’m not sure if I want them to know I know their flaws, as they’re still valuable business contacts for me. I think the hesitation I feel has to do with the Carly Simon effect: “You’re so vain I bet you think I’m talking about you” – but in the case of CTO/CIOs comparative to other roles, I’m only worked with a handful (a dozen, at most?) so in fact I *would* be talking about them, and that would be clear. I think this falls under the category of topics best handled by community proposals, as it allows me to be a coward and quietly up-vote archetypes I agree with and play dumb if I ever run into one of them at a cocktail party: “Oh, ‘The Authoritarian’ – no that wasn’t me, it was submitted by the community.”

  6. I miss a category here. Not sure about the name, but a developer that is a curmudgeon / pessimist – overwhelmed by all the things that are wrong and unable to contribute. Afraid of being destroyed / consumed by touching the montrousity that is the current production code. Knowing that for eternity, your name will be attached to whatever you edit, and people may think you have contributed to the evil spaghetti.

    • This seems to reinforce the idea of a community submission process. I think “The Curmudgeon” is a winner of a name, and I have met several of them.

  7. I did really appreciate the book content as the visual representation per se. And was thinking about if could I localizate it to brazilian portuguese?

    • I appreciate the offer and may take you up on it. The challenge right now is that this content has only gone viral as of 72 hours ago, and the feedback I have been getting is overwhelming. Right now, translating to other languages seems like something only people with popular content would do, and I am waking up to the reality that I have popular content. Let me do some research on how other bloggers deal with translations and I will get back to you, but thank you again for the offer.

    • Well, over the last few days I’ve had people translate my content to German and Russian, with someone else asking to on Twitter to translate it to Chinese. I would say if you’ve like to localize it to Brazilian Portuguese, go right ahead! If you host it on your site all I ask is attribution and a link back to my website.

  8. Haven’t read them all, but the ones I did read were both amusing and/or informative; any idea if this work will come out in dead tree format, or some other portable (PDF?) format?

    • I’m going to try to find the time to put all of the contents in a eBook format, and it looks like offering a dead tree format isn’t too hard to do. While this should pretty much only be a copy-and-paste exercise, I’ll still need to write an opening and conclusion, so I’m not sure about the time frame. I’ll keep you posted.

Leave a Reply