Removing disruptive team member[s] will vastly improve productivity and morale

Ariel Zach

SVP, Engineering at Inkling



"In one of my previous roles, had a scrum team working on a high-risk project - lots of technology unknowns, shifts in requirements and pressure to deliver within tight time constraints. However, despite having a highly motivated and technically strong team things weren't moving along smoothly. Initially it wasn't obvious that something was wrong, because I was expecting some wrong turns in the initial selection of technical components. The Product Owner was the one that alerted me the team dynamics weren't working well and there was significant 'wastage'. Planning meetings were endless, team hesitated to make commitments and in the review meetings couldn't agree on story acceptance."

Actions taken

Once alerted, I started attending the key Agile meetings (as second level manager, I hadn't been attending all the meetings before). I also prioritized the 1:1s with all the team members to get a better sense of what was going on (I meet quarterly with everybody so this wasn't out of the ordinary). By attending the Scrum meetings and from discussions with team members, a clear pattern emerged. John, one of the senior engineers on the team, was challenging almost any proposal or decision, either technical or procedural. This didn't appear to be malicious, it was his natural tendency to not take anything for granted, question every statement and insisting to perform research / over-analyze everything. The other team members had a good amount of respect for his broad technical knowledge (developed through a lot of reading and investigations, not so much via execution), so they hesitated from blaming him. It became clear to me that by "humoring" him, the entire team suffered, decisions took three times longer than needed, hurting the execution tempo, reducing morale and annoying everybody. Neither the team lead, nor the scrum master and other team members directly suggested to remove him from the team because of his perceived technical value. After confirming that John was not a single point of failure in the project (he was too busy researching to actually execute), my decision was to remove John from the team. It is never easy to let somebody go, but in these circumstances it was the right thing to do. Following John's termination, after an initial surprise, the team reacted positively. Individuals that hesitated to share their thoughts in the past opened up about their levels of frustration and expressed relief of not having to deal with that attitude any longer. The key takeaway was proving the paradox of productivity in Agile teams - the remaining team of 4 became a lot more productive than the prior team of 5 shortly after the change!

Lessons learned

"Taught me that as a manager you should not be afraid to make these changes by thinking 'we're under time pressure, need to deliver a lot of stuff, I can't afford to lose 20% of my capacity' - the negative impact of one toxic team member on the entire team is exponential and should not be under-estimated. This situation also reinforced the importance of staying close to a team's dynamics and identifying early obstacles to achieving smooth collaboration and an agile tempo. Even in self-organizing teams it is often difficult for team members to speak ill of one of their buddies and see the big picture, and it's one of the key roles of the manager to identify and resolve these situations."

Be notified about next articles from Ariel Zach

Ariel Zach

SVP, Engineering at Inkling

Leadership & StrategyTeam & Project ManagementAgile, Scrum & KanbanPerformance MetricsFeedback & ReviewsDiversity & InclusionTechnical ExpertiseCareer GrowthOvercoming BiasRoles & Titles

Connect and Learn with the Best Eng Leaders

We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.


HomeCircles1-on-1 MentorshipBounties

© 2024 Plato. All rights reserved

LoginSign up