How do I deal with difficult personalities in my team?
...
There are three characteristics among software developers that lead to them being difficult to work with: Offensiveness, Laziness, and Incompetence. Typically someone who exhibits all of these characteristics is fired. Those with only two get a warning from management and placed on a performance improvement plan. Those with only one, however, typically keep their job and make life difficult for the rest of us.
Offensive colleagues
Offensiveness is a tricky topic, as what will or will not offend people is sometimes remarkably subtle:
Do you wait a few seconds after someone completes a sentence to start responding, or do you respond immediately? People can get offended if they feel like you were not listening and were only waiting for your turn to speak.
Do you say "Good morning," when seeing a coworker first thing in the morning, or do you not make eye contact and go directly to your desk? People can get offended if you don't acknowledge their existence.
Do you speak in absolutes, or do you leave room for feedback? People will be offended that you don't seem open to their opinion.
These are all gray areas of behaviors that some will find offensive, and some will not, but a software developer will rarely get the label of "difficult to work with" for anything subtle. Instead, there are the more obviously offensive behaviors software developers deal with from their peers:
Interrupting people mid-sentence before they have a chance to complete their thought.
Criticizing other developer's code with no suggestions on how to improve it.
Using non-verbal cues like rolling their eyes or sighing when someone is speaking to them.
Failing to show up on time for meetings, or making it obvious they don't want to be in the meeting when they show up.
Yelling at their coworkers when they make a mistake.
Condescending to people who are less knowledgeable or experienced than them.
Software developers who are this offensive, yet are hardworking and highly competent, will tend to be tolerated by management. Unfortunately, that still makes them a difficult person to work with for their peers.
At the root of offensive behavior is a lack of respect, which is not an easy thing to fix. There can be many reasons why someone does not respect their peers, and ironically it can be because they find their peers difficult to work with. Cultures, where people become more difficult to work with as they perceive their peers to be difficult to work with, are often called a "toxic environment." Ultimately, no one has respect for anyone, and the situation is not going to get better until the group is reorganized, which can be as simple as everyone who likes each other gets to work together.
Cultures, where people become more difficult to work with as they perceive their peers to be difficult to work with, are often called a "toxic environment."
As effective as separating offensive people from the rest of the group can be, management will rarely do this. Managers tend to believe that everyone should, in theory, be able to work with anyone and don't accept that social groups are too complex to be managed with a few simple rules. Rather than fight against a hundred thousand years of ingrained tribalistic instincts, pragmatism dictates that when people are showing disrespect to their peers, they have to be isolated to work by themselves or allowed to work with only the people they like. The alternative is to keep torturing their peers, which is in no one's long-term best interest.
Lazy colleagues
While offensive people are easy to identify by management, lazy people can usually only be detected by people who are very close to the work the lazy person is supposed to do. These people can be product owners, business analysts, or testers, but are most often other software developers. The challenge is determining how long something should take to code cannot be accurately predicted, and there is always room for error in estimates. Lazy people will tend to hide behind the excuse of the estimates being wrong, and they can only be caught by people who know the estimates gave more than enough time. Technical managers can detect this type of fraud easily, but non-technical managers will ignore the possibility that a developer is lazy and only call for better estimates. Of the many drawbacks of having a manager who has never coded supervise coders, the inability to detect laziness is one of the most negatively impactful to the success of any software project.
Dealing with laziness is ultimately a problem of motivation. If a developer is lazy, management must figure out what would motivate them to work. One of the more effective techniques is to tie part of their compensation to job performance, combined with rigorous, transparent, and objective performance reviews. A merit-based bonus system such as this, however, must be applied to all software developers well in advance of the discovery of a single lazy developer, so it is a preventative measure and not a cure. Having said that, if a software developer has unambiguous guidelines for what their employer considers an acceptable level of productivity, and they know that they will not get their bonus if they fall below that level, it can be very motivating.
When there is no merit-based bonus system, and a non-technical manager is in charge, there is little their peers can do to motivate them to work hard. All that can be done is to reassign their work to other developers and make it clear they are not needed. Approaching the problem in this way is counter-intuitive, as you are seemingly giving someone who doesn't want to work exactly what they want. However, the effect this can have can be stark: the entire development team has deemed that so little work comes out of a single individual, absorbing their output is no problem. Management is sent the clear message that the lazy developer is not needed, and the lazy developer learns they are not wanted. The responsibility then falls squarely on management to justify the lazy developer continuing to receive a paycheck.
Incompetent developers are often confused for lazy developers because both have little-to-no work output. However, there is a sharp difference between the two:
Lazy developers could be productive if they wanted to, but choose not to work.
Incompetent developers want to work but try as they might, can't positively contribute to their team's productivity.
Incompetent developers fall into two distinct categories:
Those that can cross the minimum threshold of team productivity with training and a reasonable investment of time.
Those that won't ever be able to keep up with their team.
The challenge the entire software development industry faces is: how do we tell the difference between the different types of incompetence? How can we tell if a software developer has a productivity problem that is fixable or not? Who would even pass this judgment, and what would the criteria be? If there were criteria and a fair judge, how would we deal with people on the boundary? To make matters worse, "incompetence" is both contextual and temporary: you may be competent in other teams, and competency in software development declines if no effort is spent learning new tools, technologies, and techniques.
Incompetent colleagues
While the offensive developer can be isolated, and the lazy developer motivated, we don't have a good solution for incompetent developers that don't get better with an investment of training and time. While a rigorous code review process can eliminate the negative impact they have on the codebase, keeping incompetent developers on staff can lower the morale of the other developers. The perceived unfairness of allowing even a single incompetent developer to stay on the team can lead to bitterness and resentment. It is then only a matter of time before the environment becomes toxic, as developers become hostile to the incompetent developer who is desperately trying to do their best. If you have ever had the misfortune to observe this phenomenon first-hand, you know how painful it can be for everyone involved.
If an incompetent developer can get better with training and time, then, by all means, help them get better. As we can't tell the difference between fixable and unfixable developers, the safest bet is to invest in everyone and hope for the best. Sometimes, the results will be extremely satisfying and fulfilling for everyone involved in their growth, but sometimes it won't. At some level, we have to do what we feel is right, and for most of us, when someone needs help, we feel we must help them. Whether that is in the best interest of the project or organization is another matter entirely.
...
Neil writes a lot more about the softer side of software development over at neilonsoftware.com. Check it out!
