“We” instead of “I” - The team as the smallest unit of delivery
Collaboration and new research on productivity
One of the important basic principles in Team Topologies is the “Team First” approach. Teams - and not individuals - are the smallest unit of value delivery. The reasons for this are manyfold.
The first one is based on the fact that we as humans are social beings.
Meaningful conversations with other people usually are improving our sense of belonging, we generally like to share our accomplishments and concerns with others. Different levels of experience and a variety of skills offer a lot of opportunities to learn from each other and grow.
I understand that the level of interaction that is required to feel comfortable is quite individual and also a deeply personal issue but given an environment that supports mutual respect and trust a team is the preferred working environment for most people. Creating this environment obviously is not trivial but worth all the effort that is needed.
From a more technical perspective, complex problems typically require non-trivial solutions - having a diversity of opinions and viewpoints is beneficial in most of the cases. Solutions that are based on joint discussions tend to be more robust than individual decisions and a higher degree of ownership typically is achieved.
Ownership around a product or an individual part of the product includes autonomy about what is delivered and how but this freedom to decide include responsibility for the quality and value of the functionality delivered, a responsibility that requires effort and a wide range of skills. In most non-trivial cases a team is needed to cover all the needs.
These are all quite convincing reasons but I recall multiple discussion around the concept of “super developers”, heroes who by themselves achieve the greatest things with incredible speed. I have experienced people like this some time in my career, gifted individuals that were able to deliver super fast. But what I also learned is that relying on persons like these is not a sustainable solution. They tend to accumulate tasks (because they are so good!) and eventually end up being a bottleneck. A perfect example is the almost proverbial Brent from the DevOps classic “The Phoenix Project” who is skilful, knowledgable and helpful but tends to attract responsibilities that are way beyond his capacity and thus ends up reducing flow instead of increasing it.
“Heroes” tend to attract responsibilities way beyond their capacity and thus end up reducing flow instead of increasing it.
There is no doubt that skills and experience are incredibly valuable and organizations should support all their employees to get better in what they do but I think it is also clear that this must be done with the well being of the team in mind - there is no single person able to handle the complexity at hand.
But there is an important concern and that is the cost of coordination. In simple terms - if teams get bigger, the effort it takes to coordinate the work will grow faster than the working capacity so that at the end less work can be done although more people are involved. The number of possible interactions between team members and thus the coordination effort is growing exponentially, while the available working hours only grow linearly which leads to a net negative effect on output.
This relationship is also the reason for Brooks’ Law, the famous statement that adding more people to a late software development project will only delay it further. Fred Brooks formulated this famous law in his all-time classic “The Mythical Man-Month”, released in 1975 and still a very valuable book.
Brooks’ Law obviously limits the possible size of a team but below the crossing point where adding additional people becomes ineffective something else is happening to the team capacity that can’t be explained by just adding up working hours of the team.
Just recently I stumbled over an incredibly interesting paper called “Collaboration Drives Individual Productivity”, you can find it here .
The authors investigated the impact of collaboration on the productivity of individual contributors by studying contributions to two of the biggest collaborative systems: GitHub and Wikipedia.
From the abstract:
By analyzing the activity of over 2 million users on these platforms, we discover that the interplay between group size and productivity exhibits complex, previously-unobserved dynamics: the productivity of smaller groups scales super-linearly with group size, but saturates at larger sizes. This effect is not an artifact of the heterogeneity of productivity: the relation between group size and productivity holds at the individual level. People tend to do more when collaborating with more people.
It seems that there is another very strong reason for working in teams: we tend to be more productive! I am sure there is a strong correlation to the psychological aspects I mentioned above but it is quite reassuring that there also are hard numbers showing this impact.
The authors also show that the individual productivity improvements stagnate with increasing group size - in other words, above a specific team size (and it is rather small, approx. 10-15 people) almost no additional productivity gains can be observed. This may also reflect the impact of the cost of coordination.
It is important to note that the results have been corrected to exclude biases as good as possible and the authors also duly note that result can’t be generalized across domains. But GitHub and Wikipedia are relatively distinct collaborative system, GitHub way more structured and with a significantly higher contribution barrier. Still, it seems that results hold well for both systems.
What should be our take from this?
The paper is another strong hint that the social aspects of collaborative work not only impact our well being but do have a significant and measurable impact on our productivity. Team work is not just about adding work capacity - the collaborative aspects make us work better and more effective.
“We” is in most cases more productive than “I” - “Team First” is a valid principle even if we just look at it from a purely pragmatic business perspective.