How to deal with the one difficult team member in your scrum team?
How one person breaks a team and what can fix it.
In 2006, Will Felps, a researcher at the University of New South Wales, conducted an experiment.
He planted a bad actor in small working groups, sometimes a slacker, sometimes a jerk and measured the group's performance.
It turned out that one person can reduce a group's performance by 30 to 40 percent.
The bad apple didn’t do any direct sabotage.
Instead, just their mere presence was enough to indirectly change the team's emotional and behavioural equilibrium. The other members began mirroring that negativity. For example, they too started bickering, disengaging, and checking out.
The dysfunction spread through the team, affecting everyone.
However, a few groups were able to resist this.
The groups that resisted the effect were the ones with a member who actively managed the dynamic, who redirected conversations, defused tension, and reestablished norms in real time.
In other words, the presence of the bad apple was a constant. Whether it destroyed the team… depended on the system around it.
Today, I want to talk about dealing with this bad apple step by step.
Let’s get started.
Got an urgent question?
Get a quick answer by joining the subscriber chat below.
The Coordination Problem
The thing about Scrum teams… or any small, cross-functional team trying to ship work in short cycles is that…
They're COOPERATION machines.
This kind of model depends on a set of unspoken agreements:
For example:
I'll do my part, you'll do yours,
We'll be transparent about progress,
We'll hold a shared quality bar, and
When something goes wrong, we'll adapt together rather than pointing fingers
But…
If you look closely at it, you will find that it is ACTUALLY an Iterated Prisoner's Dilemma.
Note: The Iterated Prisoner’s Dilemma is a very interesting concept. Check it out at the link provided.
Every Sprint is a new round of the game. Every Sprint commitment is a signal of cooperation. And the whole thing works beautifully... right up until one player starts defecting in one of the following ways:
they over-commit and under-deliver
they bypass the Definition of Done
they let work sit in progress for days without raising a flag and then dump the risk on the team at the end of the Sprint
or maybe they just refuse to engage with the process at all
It doesn't matter which defection it is. What matters is the second-order effect.
Here’s what it means:
When one person consistently defects in an iterated game (like Sprints), one of two things happens. Either the other players start defecting too, i.e. they stop going the extra mile, they protect their own work, they quietly disengage, OR they start over-cooperating to compensate, absorbing the defector's risk, Sprint after Sprint, until THEY BURN OUT AND LEAVE.
Both outcomes eventually destroy the team.
So what should you do?
Should you have a 1:1 meeting with them?
Why "talking to them 1:1" is necessary but not sufficient
Every article on dealing with difficult team members eventually comes to the same advice: have an honest conversation… 1:1.
And look, that’s correct.
You absolutely need to have the 1:1 conversation. It is “necessary.”
But…
It is not sufficient.
Just like building a great product is “necessary” for building a great company, but it is not “sufficient.” (You also need distribution, timing, capital, talent, and about forty other things.)
Now…
Here’s how it generally goes:
you notice the problem…
… you agonize about it for three weeks,
… you finally have The 1:1 Conversation,
… it goes reasonably well,
… you both agree to do better, and then...
… absolutely nothing changes
Two Sprints later, you're back where you started, except now you're also annoyed that The 1:1 Conversation didn't work.
The conversation didn't work because “conversations” ARE NOT systems.
A conversation is a point-in-time event. And a system is a persistent structure that shapes behavior continuously. You need both, but if you only have the conversation without changing the system, you're basically hoping that a single input will permanently alter someone's behavior.
That's not how people work. That's not how anything works.
So here's what I want to do.
I want to walk you through the full stack of interventions, from diagnosis to system design to escalation, and show you how each layer builds on the previous one.
We will build a “team level” infrastructure of accountability.
This will be followed by the Weekly Recipe on the coming Sunday, which you can apply directly to your team.