Toxic developers considered harmful

At some point in your management or development career, you’ll encounter a certain kind of developer that stands unique from all other developers, but not in a good way.

Others will find working with this individual draining and demotivating. They’ll find themselves going to great lengths to avoid interacting with them, even if it means negatively impacting their own ability to complete tasks. Communication will shut down throughout your organization. If it becomes bad, your team will start looking for opportunities elsewhere. While you deal with the fallout of the exodus of talent and failing projects, this particular kind of developer will happily continue working as if nothing was wrong.

Sometimes this developer is an incredibly skilled developer who knows the ins-and-outs of the technology and environment. Often, this developer is an expert beginner, unable to become better due to their inability or refusal to recognize their lack of skill. Either way, you’ve had your first run-in with what’s known in the industry as a toxic developer.

How does toxic developer impact the organization?

Toxic developers are an organizational threat and shouldn’t be taken lightly.

Toxic developers suppress innovation and ideas.

Toxic developers tend to have large egos, and their egos often get in the way of fostering learning and openness. As a result, toxic developers tend to consistently shut down any form of opposition to their ideas, no matter how valid, often without addressing the underlying issues. If another developer proposes a good idea, the toxic developer will do everything in their power to shoot the idea down or, if not possible, take credit for the idea.

Toxic developers promote a culture of non-communication.

Toxic developers are hard to communicate with because they use communication as an opportunity not to learn and understand, but to assert superiority. If you ask a toxic developer a question, they’ll respond in ways that belittle or make the other person feel inadequate for even asking. Phrases like “You don’t know that already?” and “Fine, let me explain it to you again” are indicative of this attitude. This leaves other developers feeling like failures and discourages them from speaking up or communicating in the presence of the toxic developer.

A culture of non-communication is death to a project.

Toxic developers tend to decrease the bus factor.

Toxic developers are often ego-driven, and they tend to hoard significant amounts of authority and power, especially in organizations where management is not knowledgeable about their behaviors. They don’t like giving up their authority, so they tend to be highly controlling and authoritative: everything has to go through the toxic developer. Soon, the toxic developer becomes the only one who knows, has access to, or understands a core part of the technology.

Congratulations, your bus factor is now 1 and you’re in a very, very bad situation.

Toxic developers create cultures that cause other developers to leave.

As a developer, dealing with toxic developers on a daily basis is demotivating. They belittle your ideas, take credit for everything, and are generally not pleasant to work with. Often their technical talent doesn’t match their egos, so you spend significant amounts of time having to fix the problems they create. It’s also severely demotivating to see these problem behaviors rewarded by management who aren’t paying close enough attention.

Good developers don’t have to put up with this. They know they are in high demand and they will look for opportunities elsewhere. If you have a team with severe retention problems, see if there’s a toxic developer that might be contributing to a demotivating environment.

Toxic developers lead to worse teams.

Toxic developers won’t hire anyone who they feel might be a threat to their position. If they are on your hiring committee, chances are they will look for reasons not to hire talented or skilled individuals. If A players attract and hire A players, toxic developers do their best to hire D players.

Good developers often won’t join an organization they know is toxic.

Signs you have a toxic developer on your team

Sometimes it can be hard to distinguish between behaviors of a toxic developer and a developer who might simply have disagreements with certain members of your team. The latter isn’t necessarily a toxic developer — people are allowed to have bad days, disagreements, or simply not get along with certain teammates. They should be allowed to disagree (respectfully) from the common opinion — that’s how innovation occurs. Some people just don’t get along, and your job as a manager is to make sure the environment allows both to succeed. Toxic developers, on the other hand, take their behavior to a whole different level. You can tell who a toxic developer is by looking at their behaviors.

Everyone goes quiet

If a team suddenly goes quiet when an individual enters the room, pay attention — it might be an indicator that they feel highly uncomfortable around this individual. Healthy development environments promote communication, whereas toxic developers shut it down.

They amass power

It’s hard to not give more responsibility and authority to someone who seems to be responsible for every success, who comes up with all the great ideas, and who knows the solution for everything. Take care to make sure that the people you entrust with authority aren’t the ones abusing it.

They’re quick to criticize others and toot their own horn

Everybody has a bit of ego, but toxic developers tend to have a significantly overinflated one. They go to great lengths to protect their ego, often pointing fingers if a failure occurs and taking credit away from others for things they had little or no contribution towards.They will be quick to point out flaws of others and will point out their own virtues. It’s never the toxic developer’s fault if something goes wrong, and any success is always because of their contributions.

You’ll see this behavior during code reviews. The toxic developer is quick to point out how bad their teammate is, citing any defect or mistake, no matter how minor, as evidence. If their own code gets reviewed, the toxic developer will argue they are correct even if they aren’t. Often, their code is wrong and inconsistent with the rest of the project because they don’t like to follow existing standards or practices that they didn’t think of themselves.

If there is a spotlight, they want to be in it, and they’ll throw anyone under the bus to get it.

They are jerks

If a developer insults other developers for merely disagreeing with them, it’s a fairly obvious sign that something is wrong. Putting others down or treating others disrespectfully are also very clear signs. However, a less visible sign is one of passive-aggression. Toxic developers might make snide, offhand comments about others to boost their own ego and make themselves look better. Taken by itself, it might be passable, but if it happens consistently it might be an indicator that something is wrong on a deeper level.

How do you deal with a toxic developer?

As a manager, you’ll have the opportunity to promote positive outcomes for your team and organization.

Stop them

The first step to dealing with a toxic developer is to never have them enter your organization. Ensure your hiring process filters not only for technical ability, but for personal traits as well. See how your candidates deal with disagreements, ask them about a time they ever changed their mind about something, put them in a situation where their work is being respectfully but critically analyzed. How a person reacts in these situations is telling and indicative of how they’ll react when they work with the team.

Identify them

Sometimes toxic developers slip through the cracks and manage to get on your team. Your recourse at this point is to keep your ear to the ground and look for symptoms that your team is suffering from the effects of a toxic developer. Ask your team during 1:1’s about any issues they might be having with the team, or if there’s anything they want to change. You might receive plenty of hesitation, but be open and gently communicate — you’ll see fairly consistent answers across the board if you have a toxic developer in your midst.

Talk to them

If the individual is highly skilled (and you’ve verified this by talking to their peers and reviewing their work), they can still be an asset to the team. Meet with the developer and see if they are aware of their behaviors. Sometimes people just don’t realize it, and if given an opportunity will attempt to adjust their behavior. This is more of a long-term journey than a quick fix — you’ll likely have to have the discussion repeatedly and consistently, and it often won’t work.

Redirect them

If you’re not seeing any significant improvements in behavior, you’ll want to focus on redirecting their negative impact away from the rest of the team. Try to minimize the amount of interaction the toxic developer has with the rest of the team. Ensure that the toxic developer does not have authority over other developers. If they previously had authority, try to place them in a non-authoritative advisory position. Isolate the toxic developer as much as possible — your team shouldn’t have to suffer from their behavior. Call out any negative behaviors publicly — ensure that the entire team understands that the toxic behavior is not accepted in the organization.

Fire them

Most of the time, retraining or redirecting won’t be possible. In these cases, bite the bullet: end your business relationship with the developer. This may be hard, especially since the toxic developer may have made themselves a singular point of failure. Try to increase the bus factor as much as possible to ensure that projects and organizational success aren’t in jeopardy. Keep in mind that toxic developer are like ticking time-bombs for your organization — don’t keep them around any longer than you need to.

It’s rarely worth keeping a toxic developer on your team — the long and short-term negative effects on your organization often far outweigh the positive contributions they make. Identify and deal with them as quickly as possible, or else they may bring your organization to its knees.

Did you find this story helpful? Please Clap to show your support!
If you didn’t find it helpful, please let me know why with a Comment!