Increasing team sizes: Collective unresponsibility
After a few recent conversations with colleagues as well as my observations of several projects I’m coming to the conclusion that the way that people react in situations often differs significantly depending on whether they’re working in a large or small team.
One of the most obvious ways that this manifests itself is when there comes a need for someone to volunteer to take care of something - be it a particular functional area, communication with the onshore team or something else.
In larger teams there often seems to be a noticeable silence as no-one or one of a very few people offer to do it.
There seem to be two theories about why this happens:
People assume that because the team is so big someone else will almost certainly take care of it so they needn’t bother.
People assume that because the team is so big someone else is probably better placed than them to take care of it.
The problem that arises from people not taking care of things is that they don’t tend to feel as if they’re an important part of the team which invariably means that they don’t contribute as much as they could.
From what I’ve noticed this type of thing doesn’t seem to happen as much on on smaller teams - there are just things to do and they tend to get distributed amongst the people on the team.
The concept/stigma of 'volunteering' to do something isn’t there.
I recently came across Lewin’s Equation which suggests the following:
Lewin’s Equation, B=ƒ(P,E), is [...] a heuristic designed by psychologist Kurt Lewin. It states that Behavior is a function of the Person and his or her Environment.
I think this is reasonably accurate and I’ve noticed people who were fairly anonymous in larger teams become amazingly effective when they were put on a much smaller one.
The 'agile' approach to software delivery tends to encourage smaller team sizes and the idea of creating collective responsibility seems to be a key part of why you’d want to do that.
A typical approach to achieving that would be to split the building of a system into smaller teams where each covered a specific stream of work.
The collective team will still need to work together at some stage to build the entire system but at least within their streams they can feel a sense of ownership.
From my experience it can sometimes be quite difficult to do that because it seems that all the streams of work are tightly coupled.
I think we need to really endeavour to find a way to break them up though because it will lead to a much happier team and most likely a more productive one.
About the author
I'm currently working on real-time user-facing analytics with Apache Pinot at StarTree. I publish short 5 minute videos showing how to solve data problems on YouTube @LearnDataWithMark. I previously worked on graph analytics at Neo4j, where I also I co-authored the O'Reilly Graph Algorithms Book with Amy Hodler.