Toxic Team MembersAdded to People
One toxic team member, left unchecked, can lead to low morale, low productivity, or can even destroy an Agile team.
Imagine this was your Agile team: Your Product Owner has expert domain knowledge but is more focused on career progression than on developing a great product. The Business Analyst is thorough but is a poor time manager and often misses deadlines. And your lead Developer is a highly talented and creative coder but is also a real pain to work with; he belittles others, keeps everything to himself, and believes he is too important to attend Daily Stand-ups.
The team described above was a real team I coached years ago. Over time the Product Owner grew into a supportive, trustworthy person who worked well with the team. The Business Analyst eventually learned to say “no” to unimportant effort and was better able to balance quality and speed in deliverables. The Lead Developer, however, was a different story.
As Agile coaches, we do our best to determine root issues that may be causing team dysfunction and we try to resolve them by building trust with individuals and teams, guiding them to find answers that work for them, and helping to instill a positive culture. But sometimes an individual just may not be a good fit for a particular team, or, they may not be a good fit for an Agile team. Team dynamics are never perfect and most teams need time to grow and develop good working relationships. But there is a difference between people who need time and nurturing and those who refuse to change and who continue to be a leading cause of team dysfunction.
I have a swimming pool at home and I keep a large airtight bucket of chlorine tablets in an outdoor closet. Chlorine is nasty stuff – it is corrosive and toxic. Two winters ago, I put some chlorine tablets in the device that feeds chlorine into the pool water, put the lid on the chlorine bucket, and closed the closet door. A month later when it was time to add more chlorine to the feeder, I opened the closet door and my eyes felt a burning sensation, the smell knocked me back, and I saw that all the metal yard tools in the closet were severely corroded. I had not put the chlorine lid on tightly enough. The small gap in the seal had exposed the closet to a very small level of chlorine and, unchecked for several weeks, the chlorine gas had all but destroyed everything in the closet.
Agile teams are made up of people. Agile puts a high focus on people and the interactions between them. One toxic team member, left unchecked, can lead to low morale, low productivity, or can even destroy an Agile team. The Lead Developer I described above was a toxic team member. Several months of relationship building, one-on-one conversations, empathizing, and coaching were yielding no positive results. He continued to negatively influence team culture and morale, and he displayed no desire to change. I finally made a judgement call and asked that he be removed from the team. The team immediately improved in productivity, team members were more talkative, they opened up to each other more, and I could sense that they were having fun once again. Sometimes a person is just on the wrong team – in the wrong environment. They may thrive somewhere else – in other circumstances.
Perhaps I waited too long to initiate the change in the team member or, maybe, given more time he would have become a valuable contributor to the team. We all have core values that are important to us. One of those core values I hold is respect for people, and when that value is not evident somewhere I try to influence positive change. If those efforts don’t succeed, there comes a time for drastic action.
We all make judgement calls and do our best to positively influence our teams, our companies, and our outcomes. Don’t allow a toxic team member to harm your environment for too long. No one person’s expertise is worth keeping around if they destroy the rest of the team.
About the Author
This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.