Productivity Perceptions in Teams
The fluid notion of teams and how developers gauge their team's productivity.
This week I read An Exploratory Study of Productivity Perceptions in Software Teams, a recent paper by researchers at the University of Zurich. This study looks at the interplay between developers’ perceptions of their own productivity as opposed to their team’s.
My summary of the paper
Engineering organizations face constant pressure to increase their speed and quality. While recent research has made significant strides to advance how our industry measures and improves developer productivity, these prior studies have largely focused on productivity at the individual level. However, individuals do not work alone and team cohesion is a “dominating factor when investigating team performance,” leaving an important gap in research about team productivity.
For this study, researchers collected daily self-reports from software developers over the course of three months. These surveys, collected on a daily and bi-hourly basis, asked participants to report their individual and team productivity and to reflect on a variety of factors which affected their productivity that day. Additionally, researchers held a series of interviews with each developer over the course of the three months to capture any changes in their team or work, and to ask broader questions about their perceptions of productivity and teamwork.
Here’s what their analysis found:
The concept of ‘team’ is fluid
In literature, a team in software development is often treated as a well-defined and fixed concept. This study offers a different perspective: by asking developers to define their team at different times over the course of three months, teams were found to be dynamic, and changing frequently. It is “fuzzy who is on a team or not,” and developers do not share the same definition of team.
Researchers used this definition of ‘team’ for the study: “people that you interact with on a regular basis, and with which you share responsibilities for outcomes,” but emphasize that the fluid notion of teams makes the assessment of team productivity difficult.
How developers gauge the productivity of their team
Gauging team productivity is difficult for developers. This was found to be in large part due to a lack of awareness form developers of what their peers are working on. Instead, they look to engagement with the team (e.g., having productive meetings, collaborating on work) to gauge productivity. Additionally, when automated metrics including "issue trackers, version control systems, and other tools that provide metrics on team performance” exist, they are sparsely used to gauge team productivity.
How developers are assessed in their teams
Researchers were curious whether developers are assessed in their teams in the way they perceive they are. To explore that question, they asked 1) Individual contributors what they would say are the criteria their manager uses to assess their productivity, and 2) managers were asked what criteria they use to assess the productivity of their team. A key finding: expectations from individuals differ from the ones of managers.
Individual contributors expect managers to look at the work completed, however, managers refer to a more holistic notion of productivity when assessing developers, “one which explicitly recognizes that automatic metrics such as velocity do not show the whole picture.”
Predictors of team productivity
By collecting data from 624 daily surveys on team-related factors and activities and then creating a linear mixed regression model, researchers identified which factors are the strongest predictors of team productivity.
The strongest predictor of team productivity was the individual productivity reported that day, with all other factors being significantly less strong as predictors. “One possible explanation for the strong predictive capability of individual productivity is that developers identify closely with the team and assume their team’s productivity as their own. We conjecture that this is more likely to occur in the absence of team awareness.” In essence, developers use their own productivity as a base and assume their team’s productivity is similar.
Final thoughts
I’m looking forward to reading more research that looks at productivity at the team level, and this paper provides a foundation for future work. We may see future studies incorporate the methodology used for this study, as well as the notion that teams are fluid.
For managers and team leads, this study also offers ways to improve team productivity: focus team awareness (developers were found to have a lack of awareness about their team’s work and progress), and recognize the need for engagement within the team (developers gauge their team’s productivity by their own interactions with the group).
That’s it for this week! If you know someone who would enjoy this newsletter, please consider sharing it with them.
That’s it for this week! If you know someone who would enjoy this newsletter, please consider sharing it with them.
As always, reach out with thoughts about this newsletter on LinkedIn, or reply to this email.
-Abi