scribble

Ben Brostoff

About Posts Book Recos Privacy Email GitHub

15 Sep 2019
The Group Effect

I first read about the Group Effect in Matt Fitzgerald’s book How Badly Do You Want It, a collection of stories about endurance athletes who overcame incredible odds. Fitzgerald summarizes the group effect below:

The tiny of island of Cuba has captured 67 Olympics medals in the sport of boxing since 1968, more than any other country. Germany has finished either first, second or third in 13 of the last 16 World Cups. Nations that dominate a particular sport share one basic characteristic: their people are crazy for that sport. To put it in a formula: national dominance of a sport is a function of the scope and intensity of its citizens’ participation in it. If enormous numbers of a nation’s people participate in a sport, that nation is certain to do quite well in global competition. Sociologist John Bruhn dubbed this phenomenon the group effect. The psychobiological model of endurance performance explains how it works in the context of sports like running.

According to this model, any factor that reduces the amount of effort an athlete perceives at a given level of exercise intensity will enhance performance. When people work together, their brains release greater amounts of mood-lifting, discomfort- suppressing endorphins than they do when the same task is undertaken alone. Consequently, endurance athletes perceive less effort and perform better when training and racing cooperatively than they do alone. The group effect is not something that has to be acquired. It is a coping skill that exists latently in everyone, ready to be activated by the right situation.

I am a believer that the group effect is real. In sports and work settings, I believe my perception of effort has been positively impacted by being in groups. Difficult tasks feel less difficult for me when there is a social element to these tasks. The shared experience of running or pair programming, for instance, makes fatigue and complexity easier to deal with because you have one or more people to share it with.

Realizing the benefits of the group effect requires a group to exist. For various reasons, there may not be a group for the thing you want to improve at. And even if there is, it may not practice the thing together. An example of this group-but-not-group-effect situation would be an engineering culture where the pull request culture is to sight-read and press approve or make some small comments. Software engineer group-effect from my experience only comes from two or more people running code together and experimenting with the effects of small and large changes in an in-person setting. Said another way, just because a group does the same thing doesn’t mean they do it together.

I think it’s possible that when people talk about culture, they’re actually referring to a result of the group effect. My experience has been that a culture is positive for me when 1) everyone feels comfortable, 2) everyone feels they are improving and 3) everyone feels they are adding value. The group effect directly addresses (2) - per the article above, people “perceive less effort and perform better between when training… cooperatively than when they do alone.”

In a way, (3) is an extension of (2), because if everyone is improving, everyone (potentially) feels that just by virtue of showing up and putting in effort, they’re adding to each team member’s success. With regard to (1), I’m not sure what group dynamics need to arise in order for everyone to feel comfortable. I do think that spending more time together generally improves relationships between people, so more group effect may lead to more comfort in being a part of the group.

Knowing the group effect exists is an argument for introducing it when possible. Yes, some activities are probably easier when performed solo. Pair-programming often feels less efficient to me than solo-programming, but I also don’t think efficiency is a proxy for consistency or resistance against quitting. Some of my biggest breakthroughs in projects have come from good pair programming sessions. There’s a place for both, and neither should be ignored or said to be always better than the other.

Some potential ways in software and sports to introduce the group effect:

  • For code reviews - moving code reviews to in-person, interactive Q&A sessions, where the reviewer runs the code and explores all possible code paths alongside the author
  • For any endurance race - finding someone or group of people doing the same race on a similar timeline and training together on at least a weekly cadence
  • For spiking on a new technology or language - meeting weekly or more to pair-program, review useful resources and discuss difficult concepts
  • For improving an athletic weakness - finding someone with the same weakness (ex. backstroke is weakest stroke for an individual medley swimmer, swimmer sees improving backstroke as easiest way to faster time) and crafting group training plan to make weakness strength
  • For changing a major issue in a codebase - devoting one or two days of the week to talk about the issue, brainstorm solutions and prototype solutions (through pair-programming) together. Importantly, the solution here would be group-created versus individual-created, which in my opinion is one reason resistance crops up for good ideas on introducing new patterns into a codebase and deprecating old patterns

At the very least, I think it’s worth exploring whether the group effect will work in domains that have traditionally been one-person activities.


scribble

About Posts Book Recos Privacy Email GitHub