Building an impactful software project is an effort that relies on a team of developers; its delivery is mainly reliant on the team dynamics and overall effectiveness. 

While it is a huge advantage to have brilliant and knowledgeable developers on your team, it doesn’t guarantee successful delivery. Some developers’ behaviors affect the team’s effectiveness and output. 

This article will cover some of these toxic developer behaviors, how they affect team effectiveness, and the ways an engineering manager can handle toxic developer behavior.

We will cover:

• Always playing the victim
• Know-it-all
• Lack of motivation
• No sense of urgency
• Developers that can’t be fixed

Always playing the victim

One widespread yet toxic behavior you can see that affects a team is when a developer always plays the victim. Developers with this type of behavior don’t take accountability for their work and whatever issues they introduce to the team; instead, they always point fingers and blame others.

This behavior will bring about:

• Conflict within the team as other developers will find it offensive to be blamed for issues whether or not they are actually at fault.

• Waste of time which the team would have better used to find solutions to those issues.

Tip for dealing with an always playing the victim developer

Firstly as the engineering manager, avoid blaming that developer even though it is clear that they are the cause. Instead, work with your team to quickly resolve whatever issue comes about and not focus on who is at fault.

Depending on how frequently it occurs, you, as the engineering manager, can use 1-on-1’s or performance reviews to have a conversation with the developer. Asking “What they want to get out of their career?” explaining to them that the behavior is causing impacts that will get in their way of achieving their career goals. 

You can let them know that the difficult feedback is because you want them to succeed within the team and anywhere else. 

Know-It-all

Having a brilliant and experienced developer in a software project is always a huge plus for any team. Still, no developer can know it all and has nothing to learn from other developers.

When a developer doesn’t accept feedback, claims to know everything about a technology, or tries to prove they are better than other team members, that’s when a developer becomes a threat to the team.

Such a developer, with this type of behavior, creates a false sense of security to the rest of the team. It appears that they’re in the company of an expert and everything’s under control, even when it isn’t. When an issue arises, that developer will find it hard to ask for help, wasting valuable time and resources. 

Top tip for dealing with a developer that’s a know-it-all

Managing a know-it-all developer can be tricky; no engineering manager wants to lose a brilliant developer. Neither do they want a developer that threatens teamwork and team output.

To handle such a developer as an engineering manager, emphasize that the goal is to deliver the project. What is required is finding solutions to problems on the project and not stock knowledge. Making it clear to the developer that they are in a team and teamwork is more important than individual contribution because no one can know-it-all.

Lack of Motivation

A developer who loses the motivation to work almost always impacts the team negatively. When a developer lacks motivation, they:

• Lose focus on achieving the team’s goal.
• No longer strive to deliver quality work and instead perform the barest minimum for them to get by.
• Often distracted and don’t double-check their work.
• They don’t finish their work, or worse, they are often absent because they no longer feel motivated to work.

Tip: How to deal with developers who have lost their motivation?

As an engineering manager, the first thing you need to do is find out the root cause of the lack of motivation. Some of the common motivational killers are:

• Team conflict: Sometimes, they may have problems working with other team members. If this is the case, talk to the involved parties and try to resolve their conflicts.

• Meaningful work: Sometimes, they might feel like their work is not meaningful enough and unfulfilling. In this case, try to set up more meaningful work.

• Personal problems: Sometimes, it may also be due to personal issues. In this case, try to ask how you can help or any assistance the team or company can extend.

No sense of urgency

“Speed to market.”

“Ship fast.”

These terms are common in software projects, and they revolve around deadlines. Meeting deadlines is one of the most challenging things to achieve in a software project. Still, it’s also one of the most critical criteria for success when working on a project with tight deadlines, sharing a sense of urgency, and working with the deadlines in mind.

When deadlines are approaching, and a developer constantly gives in fewer hours than expected, delays finishing assigned tasks for some trivial reasons, or doesn’t show up to work at all and fails to reassure that they would meet those deadlines, then there is a problem. This will quickly become a burden for the rest of the team as they strive to meet the deadlines.

Tip for dealing with developers without a sense of urgency

With this kind of developer in your team, the chances are that the team will be prone to miss the deadlines. 

An effective method to deal with such a developer is to assign individual deadlines on top of the team ones. You can also pay extra attention to this developer during the standups, sprints, and other team meetings. 

Be sure to use the 1:1 meeting time to speak about the deadlines, as well as consider setting up another meeting or catching up with the developer before and after the sprint or standup meetings for status updates. The goal is to ensure that they are aware of the importance of these deadlines.

When you can’t fix a toxic developer

It’s common for developers who have some behavioral issues, to not be aware of their flaws. t might be an instinct for them, a personality flaw, or a reflex. 

If the issues seem non-fixable, it will be your job as an engineering manager to make a decision of what to do with the developer, if they should change teams, what sort of team they’d fit best, or if they should be fired.

It’s a case of balancing what’s best for the team, the developer, and the company.