Toxic team members

Problem:

This issue I've seen multiple times. In a given team, there is a team member with high seniority, very good technical skills, and great output in terms of productivity. He is the guy that everyone calls when "shit hits the fan." But this guy is an asshole. I'm sure you know the type. Other people call them "brilliant jerks." Due to the fact that he is so good technically, people blow smoke up his ass, and he now has the impression that he is a master in any domain. He is more than eager to explain to anyone about politics, art, and medicine, although his political views are skewed, his taste in art is his own, and he googled all the medical information he knows with no relation to reality whatsoever.

In his team, he acts like a guru. He is all-knowing in technical topics, and due to that, he thinks of himself as being better than anyone else. He expects that all other team members bow their heads in awe when speaking to him. If they need help from the guru, they have to show humbleness and ask him multiple times with the "proper respect." When he is doing code reviews, the purpose of that code review is not to improve the codebase and ensure proper coding guidelines, but instead, it is so that he can teach you, give you a lesson, and more often than not, the findings of his review are more related to his personal preferences than the industry standard coding guidelines. That's because his way of writing code is better than anyone else's.

The Product Owner and the Scrum Master of that team usually also approach him with humbleness and blow smoke up his ass because they have learned a long time ago that this is the only way to get him to take tasks and get an output from him. Of course, those tasks need to be interesting; otherwise, he is not happy with the work he needs to do and bitches about it. Even more, for those tasks that he does actually take upon himself, he will not write unit tests and has an intern/junior member in the team that writes unit tests for him with the purpose of "learning from the great master."

That being said, I'm sure you know the type. I may have exaggerated some traits, but I'm sure that over the course of your career, you have stumbled at least once upon someone that was manifesting at least some of these traits.

The "bullshit" solution:

Unfortunately, most managers of this kind of people consider that the value they bring to the company is more than the damage they inflict. This is also due to the fact that the output in terms of productivity of these people is undeniable and quantifiable. He's the guy they call when the servers are down, he's the guy they call when they have that production issue that the customers are yelling about. On the other hand, the damage inflicted is mostly inside the team and is not easily quantifiable. You see this damage in time: the team members are afraid to speak out their opinions, the technical solutions are coming only from one direction, teammates are demotivated and leave after a certain amount of time, thus adding to the churn of employees in the company. Everyone knows he is difficult to work with, but they tolerate him and avoid working with him. He slowly becomes a one-man show, and at some point in time, the management appoints him as an architect, thinking that this way he will work by himself. And this change leads to a whole new set of problems because as an architect, he needs to explain complex topics to multiple stakeholders, possibly customers. This way, his communication issues become more obvious, not only inside his team but at the company level.

The "no bullshit" solution:

The actual solution depends mostly on you, the manager of the toxic employee. There is always the "one more chance" approach, but for this approach to work, you need to set a limit on the number of "strikes" he gets. Have an honest chat with him where you clearly explain your expectations in terms of communication and team dynamics. Then tell him the number of strikes he gets. Be very firm and transparent when he gets a strike. Once the number of strikes is reached, you need to let him go.

Now, this guy is the most knowledgeable person you have, and it will be hard to replace him. Most probably, the skills he has might not be found in a new hire. That's why, while the strike system is in effect, it would be wise to ask 1-2 team members to get the sensitive knowledge from the toxic guy so that you have some redundancy and are not left open on key areas of your project. It will cost you. Anytime you need to ensure that knowledge is shared inside the team, it will come at a cost, but try to remember that the cost of replacing the other team members is higher in the long run. Anytime you replace another team member that leaves the company because of the toxic guy, it widens the moat of toxicity even more because you need to train a new member from scratch, thus diminishing the chances that anyone in that team will ever become as good as him.

If you cannot take the decision of letting him go by yourself, then you will need the numbers. This means some time spent on your side to gather the data. You will need to get the pros and cons. The pros will always be related to the knowledge he has and the productivity on your product. The cons will come in the form of historical data. You will need the exit interviews of the previous team members that point to the toxic guy as a reason for quitting. Then you'll need the average cost of replacing a team member in terms of hiring cost (from HR) and training cost (from the impact in story point output of the team anytime a team member changes). And bring these numbers to his direct manager and hope that they will be enough to get rid of him. If they are not your only change is to negotiate with a change of team for this guy and make him someone else's problem. If more Product Managers/Product Owners in the company complain about him it is bound at some point that someone will make the right choice and let him go.