Characterizing Software Developers by Perceptions of Productivity
The six types of developers, categorized by their ideal workday.
This is the latest issue of my newsletter. Each week I cover the latest research and perspectives on developer productivity.
This week I read Characterizing Software Developers by Perceptions of Productivity by André N. Meyer, Thomas Zimmerman, and Thomas Fritz. While previous work found that developers have varying definitions of what it means to be productive, this study aimed to help leaders find a path forward by categorizing developers based on their ideal workday.
This paper may be helpful for better understanding the wide range of definitions of productivity, as well as how managers can better support their teams.
My summary of the paper
Previous research has provided valuable insights for better understanding and improving engineering productivity. However, these studies often neglect to take into account the varying perceptions amongst developers of what it means to be productive, which may make it challenging for leaders to confidently put findings from some prior studies into practice.
Developers are different in what they consider as a productive or unproductive workday; this study aimed to help leaders make sense of these differences, so they can better support their teams. Researchers conducted this study through a survey with 413 developers at Microsoft. The survey asked questions about developers’ definitions of productive and unproductive workdays, the factors influencing their productivity, and the usefulness of different productivity measures for them. Then, the researchers normalized responses and clustered participants into groups.
Here’s what the cluster analysis identified:
Six types of developers
The researchers’ analysis surfaced six clusters, each representing a group of developers with similar perceptions of productivity. They named these clusters: social, lone, focused, balanced, leading, and goal-oriented developers.
The table below describes the characteristics of the six clusters in more detail. In particular it shares the name of the cluster, the statements for which half or more participants in the cluster gave HIGHER scores (second column), and the statements for which half or more participants in the cluster gave LOWER scores (third column). Prefixed with 🔨, the table also lists the productivity measures which developers found potentially helpful for reflecting about work (second column), or not helpful (third column) to the majority of developers within that cluster.
Social developers (C1) feel productive when helping coworkers, collaborating and doing code reviews.
Lone developers (C2) avoid disruptions such as noise, email, meetings, and code reviews. They feel most productive when they have little to no social interactions and when they can work on solving problems, fixing bugs or coding features in quiet and without interruptions.
Focused developers (C3) feel most productive when they are working efficiently and concentrated on a single task at a time.
Balanced developers (C4) are less affected by disruptions. They are also less likely to come to work early or stay at work late.
Leading developers (C5) are more comfortable with meetings and emails. They feel more productive in the afternoon and when they can write and design things.
Goal-oriented developers (C6) feel productive when they complete or make progress on tasks. They feel less productive when they multi-task, are goal-less or are stuck.
Possibly the most prominent difference between clusters is between social and lone developers, where the former embrace social interactions while the latter feel productive when working alone. Also notable, focused developers and goal-oriented developers are related: one group feels productive when focused on a single task at a time, while the other feels productive when completing or making progress on tasks.
The table also shows which measures developers reported as interesting for self-reflection about their work. For example, developers in most clusters found “time spent coding” and the “longest period focused on a task without an interruption” as being interesting for reflecting about their own work. Not surprisingly, lone developers are particularly interested in using measures about the number and duration of interruptions, and focused developers are interested in the number of tasks they worked on.
“The differences between software developers’ preferred collaboration and work styles show that not all developers are alike, and that the cluster an individual or team belongs to could be a basis for tailoring actions for improving their work and productivity.”
The authors conclude with some recommendations for applying these findings:
Teams may benefit from increased awareness about each members’ communication preferences.
Leaders may opt for synchronous communication with social developers, and asynchronous communication with lone developers.
An exploration task for a new product that is rather open without clear goals, and that requires a lot of discussion, might be less suitable for a goal-oriented (C6), a lone (C2) or a balanced developer (C4).
Final thoughts
This paper may prompt leaders to consider the preferences on their teams when choosing communication format or when assigning certain tasks to developers. By better understanding how team members perceive productivity, they may be able to better support them.
Part of this paper is also related to other work on the benefits of self-reflection: in another study, developers were asked to set goals to improve their work habits, and then regularly reflected on their progress towards those goals—this led to productive behavior changes that increased productivity. This study suggests that developers’ individual productivity and satisfaction may benefit from reflecting on specific topics, such as the number of tasks they worked on, the number of interruptions, and uninterrupted time.
That’s it for this week! If you know someone who might like this issue, consider sharing it with them:
P.S. If you’re interested in more research, send me a connection request with the note “research” and I’ll share a downloadable bundle of my top 10 favorite papers of this year.
Thanks for the apt summary, as always.
This tracks well with the issues of assessing developer productivity on an individual level rather than the team level.
For example, even if social type had a productive day in their book they wouldn't have much code or Jira movement to show for. However, on a team level they might have prevented task blockers or ensured knowledge transfer to more inexperienced team members.
I like this model. Somewhat reminiscent of the Julia Evans cartoon - https://wizardzines.com/comics/some-people-who-make-programming-easier/