Published in Business -

The bystander effect: when having heroes can be problematic.

According to the good folks at Oxford Dictionaries, a hero is ‘a person admired for courage, outstanding achievements, or noble qualities’. Sounds like someone you want in your team, right? Usually, yes. But there are some instances where the ‘bystander effect’—a social psychological phenomenon—means heroes can be a hindrance.

First though, some history. You need an appreciation of different team dynamics to truly understand the concept of the bystander effect, and the strategies you can adopt to mitigate it.

Several years ago, we delivered projects using a traditional ‘waterfall’ methodology. It was a completely linear and relatively rigid process. We would do all the research first; then begin design and copywriting, followed by development; then testing, launch, post-launch, maintenance, reporting, and ongoing improvements and iterations.

During those waterfall days, ‘management teams’ had control and took responsibility for each project’s overall outcome. Using a top-down approach, a small team of senior people would determine what should be done, when, and by whom.

In theory, the waterfall process sounds water tight. Unfortunately,
it simply wasn’t working.

The waterfall approach is not as straightforward as it seems. Problems would arise far too late in the piece, we had misalignments between different disciplines, and a not-too-insignificant number of projects would either miss their deadline or run over budget. Or both.

Something had to change. So, we embarked on a journey to move from ‘waterfall’ to ‘Agile’ delivery.

Making the move to Agile.

Since adopting Agile methodologies, the transformation has been mind-blowing.

Teams are now in control of the solution—rather than managers or accounts people—with different disciplines working side-by-side in two-week sprints (called ‘cycles’) to get work done.

There is a clear sense of empowerment in the team.

We’re getting work done faster, with a closer eye on budgets, and ultimately, the overall output is higher quality.

However, there’s one phenomenon that can come about in the wake of transitioning to Agile methodologies, and it’s an issue we believe many teams face. It’s called the bystander effect, and it creates an environment where ‘heroes’—despite their glowing dictionary definition—can actually be an unwanted phenomenon.

Understanding the bystander effect.

‘The bystander effect, or bystander apathy, is a social psychological phenomenon in which individuals are less likely to offer help to a victim when other people are present. The greater the number of bystanders, the less likely it is that any one of them will help’Wikipedia.

The bystander effect was first proposed as a psychological phenomenon in 1968, following extensive studies by John Darley and Bibb Latané. In clinical terms, the phenomenon is defined by three impulses in any group setting:

  1. The perceived diffusion of responsibility.
  2. The perceived diffusion of blame.
  3. A collective assumption that another person is already providing help.

More recently, psychologists have studied the bystander effect and its relevance to social issues. It has even been observed and applied in the digital world, with studies on the bystander effect in online chat settings, ‘slacktivism’, and as a common response in the context of cyberbullying.

In short, the bystander effect is a common and persistent phenomenon.

So how does it play out in a practical sense?

Let’s say someone faints in the street and you are the only other person in the vicinity. You likely feel a responsibility to go and help that person.

If, however, you’re standing in the middle of a busy town square with one hundred other people, and one of them faints, do you act? You may still feel concerned, but you may be less inclined to do anything about it. The common assumption is that someone else will go and help first. This is the bystander effect in action.

The problem with the bystander effect is that nobody acts because we collectively assume another person will.

This is the exact scenario where you expect a hero to swoop in. One courageous person acts decisively to save the day, and all problems are resolved. Everyone is happy.

However, that’s exactly the sort of outcome we hope to avoid in an Agile setting.

Teams are supposed to contribute through collaboration and a shared exploration of challenges and opportunities, rather than stand by and wait for someone else’s assertive action.

To truly understand the bystander effect and the concept of the hero as a hindrance, firstly we need to explore some basic elements of Agile methodologies.

How does the bystander effect apply in Agile teams?

While I’m not going to offer a comprehensive overview of Agile—you can find many resources that already exist—it does help to understand two key principles of the methodology:

  1. Self-organising teams
  2. Continuous learning and improvement

At August, our teams are self-organising. Team members decide what needs to be done, how it should be done, and by whom.

The traditional, ‘top-down’ management approach doesn’t exist. ‘Management’ teams don’t dictate; they assist and facilitate the delivery of work by providing context, identifying potential boundaries, and ensuring teams aren’t blocked from doing what they need to do.

We also continually learn and improve through team discussion sessions called retrospectives. In a retro, the team gets together at the end of each cycle to review how we feel the preceding two weeks went. We celebrate the good points and discuss what could be improved; we don’t assign responsibility for any corrective actions though. Our approach is self-organising, so it’s up to the team to learn from the retrospectives, decide what’s important, and then act accordingly.

It’s not up to any one individual to spark collective actions or improvement. That person would be acting as the hero.

And this is where you’ll probably see the link.

I’m sure we’ve all sat in large team meetings at some stage, where everyone agrees on a necessary action, but two weeks later nothing has happened. The bystander effect is in play. Everyone assumes someone else is going to act, so nobody does. Unfortunately, the retrospective is only half complete if we talk, but don’t improve. And if only one person commits to improvement? That’s problematic too.

When heroes emerge.

Let’s go back to our town square example, where someone has fainted in a crowd.

Sometimes, when a person faints, someone does act immediately. If you had to guess the profession of this heroic figure, what would you choose? Doctor? Nurse? Policeman? Armed services?

It could realistically be any of the above. But it’s not solely because these people have medical skills. These people are trained to act on problems quickly, with little to no hesitation, regardless of what everyone else is doing.

Similarly, in Agile teams, a ‘hero’ can sometimes emerge: someone who picks up the responsibility to improve things and take the initiative, regardless of what the group is doing.

Here’s the problem: we don’t want heroes in Agile teams.

In most situations, heroes are excellent. They take charge, they’re courageous, and they’re dependable. Batman is never late because he slept in. Wonder Woman doesn’t forget or flake out on her responsibilities. Superman is never sloppy.

Heroes are so dependable—in fact—that we grow completely dependent upon them.

If we have heroes in our teams, the team starts to expect heroic things of those people all the time. ‘Sally always handles it, so I don’t need to bother.’ Gradually, the team can become lazy and complacent. And worse still, our hero may start to build resentment. Why should they constantly pick up the slack?

How to reduce the bystander effect.

So how can Agile teams overcome the bystander effect and avoid an overreliance on hero figures? Here are 5 ideas to consider:

  1. Make people aware of the situation. Simply understanding that the bystander effect exists is a great first step towards reducing it. With a little situational awareness, people will catch themselves behaving like a bystander, meaning they’re more likely to do the opposite and step up collectively when something needs to be done.
  2. Reduce team size. There is an inverse relationship between the probability of someone acting on a problem and the size of the team. In other words, when you make a team smaller, the bystander effect is less likely to occur. If you have a team of twelve people, why not try splitting them into two teams of six?
  3. Discuss key actions regularly. We use daily check-in meetings so that everyone can stay across the progress of the cycle’s work. This is a great place to check in on key actions from the retrospective, too. Make sure those actions are always visible: perhaps attached to your Scrum/Kanban board, or on a wall wherever you hold regular meetings.
  4. Be transparent with important metrics. Ensure your key actions are measurable so there is some sense of progress, and eventually, ‘doneness’. Additionally, make the progress towards those goals visible for the whole team. Keep your goals compelling and ensure they are fully understood by everyone, and identify and discuss potential strategies to achieve them. Always be careful about the information you choose to show through: transparency can backfire if you don’t get it right.
  5. Encourage heroes to facilitate and mentor, not continually volunteer to take the reins. Encourage your heroes to facilitate group discussions instead of instinctively tackling the grunt work. By doing so, they will gradually become mentors for other team members, encouraging them to speak up and offer their opinion (and hopefully more of their time, too).

There you have it. When you go by the dictionary definition, a hero is invaluable. However, I’m sure we’d be better off with self-regulating teams of wonder women and supermen, rather than singular heroic figures and a whole bunch of bystanders.

Over to you. Have you noticed this phenomenon in your team? And what have you done to overcome it? Let me know in the comments below.