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