The following list of 48 archetypes attempts to describe the most common types of difficult people found on software projects. This problem-solution guide is primarily meant for people in managerial or leadership roles to improve their organization but also can be used as a tool for self-identification, self-reflection, and self-improvement. If it is used for any other purpose, it is being misused. While self-identification can and will be distressing, it creates a growth opportunity if someone is willing to change their behavior.
To be included on this list, each archetype had to be observed at least 3 times at 3 different companies. As such, this is not a work of fiction, theory, or speculation, but documentation of real-world archetypes that have been encountered throughout a two decade career in professional software development spanning several companies and hundreds of people. Therefore, attempting to invalidate the archetypes is an attempt to invalidate real-life experiences. Since its release, hundreds of people have reported seeing these archetypes in software projects around the world, so while anecdotal encounters do not guarantee the description of a general phenomenon, it would seem that there is an element of accuracy worth considering.
Each archetype should be read in full, as a quick scan of the text will inevitably lead to misunderstanding the archetype. In other words, do not assume how an archetype will be described based on its name or description – the full problem and solution must also be understood. In order for someone to be identified as one of the archetypes, they must exactly match what is described in the “Problem” section. If they do not match exactly, they are another phenomenon not covered in this guide.
This is not a work of sarcasm, humor, or spite, as this guide documents the types of people that make software development projects toxic. Toxicity increases the occurrence of anxiety and depression, which in turn increases the likelihood of suicide. Colors and animal icons are only used to add whimsy to an otherwise dark and fairly depressing subject. The common yet counter-productive sentiment of “I hate working with this person,” is unpacked into, “Why do we hate working with this type of person, and what are we going to do about it?” In this way, this guide can be used to both identify and repair toxic environments.
This is also not a list of every type of person you will encounter on a software project, only the difficult archetypes. This is in contrast to personality categorization systems such as Myers-Briggs, which attempts to lump every human into 16 types, or astrology that lumps every human into their birth month. Humans are extremely difficult to classify, but difficult humans on software projects are a limited subset that tends to exhibit a finite set of characteristics, allowing them to be described in terms of archetypes.
Many roles are collapsed for the sake of brevity and simplicity. For example, Business Analysts and Technical Writers are lumped into Product Managers; Graphic Designers and Interaction Designers are lumped into Designers; Scrum Masters are lumped into Project Managers and Development Managers; Architects and DevOps are lumped into Developers; Automation Engineers are lumped into QA/Testers. To fully expand all archetypes into separate roles would simply lead to dilution due to the role similarities and the inevitable overlap and redundancy in the descriptions of problems and solutions.
Finally, note that not all types are equally difficult, with some being harmless in practice, while others have the potential to single-handedly cause a project to fail. Most archetypes are created by flaws in management, leadership, environment, company culture, or situation, and do not represent a personal failing beyond being unable to rise above challenging circumstances.
As the following list is fairly long and dry, you can also explore these difficult archetypes with the interactive infographic.
Difficult 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.
- 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.
Difficult 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.
Difficult 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.
- 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.
- The Firehose – A Tester 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 Tester who accuses the developers of not testing their work whenever they find a bug.
- The Alarmist – A Tester who has declared that the entire product is of an unacceptable level of quality based only on their first impressions.
- The Scientist – A Tester who spends the majority of time documenting bugs, rather than finding new bugs.
- The Misleader – A Tester who often reports bugs inaccurately, leading the developer down the wrong path as they attempt to reproduce and fix the problem.
- The Downtrodden – A Tester 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 Tester who looks for bugs by simply clicking on whatever they feel like.
- The Flippant – A Tester whose bug reports are so passive aggressive that developers interpret them as being rude.
38 thoughts on “How to Deal with Difficult People on Software Projects”
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.
I’ve decided to post the books content here, as it seems I will never have time to formally publish a book. Let me know what you think!
Neil, you can consider Leanpub to publish on the fly.
Awesome! Thanks Neil.
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.
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.
@Neil nice insights and funny collection 👍
…. But what now: book or noch book?!?
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.
as usual, the poor guys lumped with supporting the catastrophe is forgotten
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.
been a developer for 15 years, now on high level support for just over 2 and actually enjoying not being on the hampster wheel anymore
also, thanks for taking the time to reply
The only rockstar that appears is a developer! Hmmm… I wonder what your background is 🙂
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.
What about non-problematic traits? I have seen enough fire-fighters in software that become burned themselves…
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’
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.”
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.
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.
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.
I remember a meme where everybody viewed different roles of themselves and others differently, but the sys admin.. everybody saw him as a creepy guy holding up his middle finger 😂
Yet another reason for me to create a community submission process so that Sysadmin and Operations archetypes can be added.
Very nice piece and I would totally buy the book (pulped tree or PDF).
Really good and funny collection, but any good QA character?
I like the QA characters and most of them are up to ground reality…
Where are a Business Analysts?
ahahaha, good one!
I pass this (brilliant) site round the workplace with caution; sometimes it’s simply too close to the bone. Also, some people have more than one trait listed! I think of this a multi-class build: e.g. Bull in a china shop/Diva
I’m very glad you like it! Fun fact: The majority of links that come to “How to Deal with Difficult People on Software Project” are direct links or from Facebook. My theory is that it gets passed around in work 1-on-1 chats or is shared only with Friends and Family. When I do see someone sharing it publicly on sites like Twitter and LinkedIn I often worry that they may not be aware of the message they are sending to their coworkers. For example, it’s really weird when I see people in leadership positions sharing it on LinkedIn. Are they sending a warning to their subordinates to shape up?
Over the last year, I’ve added more “positive” content on my site: I revamped the blog, added “12 Types of Developers You Need on Your Team” and “How to Learn the Top 20 Soft Skills in 2020.” Now, people can share content that is positive at work, and then let their coworkers stumble on “How to Deal.”
You forgot the Seagull development manager. The one who leaves the developers alone for long periods of time, then comes in, asks to be brought up to speed, proceeds to tell development that they are doing it all wrong, its not the way he wanted it, and they need to redo it, then leaves. The cycle usually repeats itself.