Understanding what drives software development productivity is the key to making high-impact investments in engineering productivity, Emerson Murphy-Hill said at QCon San Francisco. He presented the results of their investigation into factors that predict developer productivity and shared what they learned from exploring inequities in software engineering.
From our personal experience, we know that it’s not just one thing that makes us productive or unproductive, Murphy-Hill said. The research backs up that intuition – many factors affect productivity in software engineering, he added.
We didn’t know how to prioritize the factors for both further research and for practical significance, Murphy-Hill explained:
Developers complain about meetings, open offices, and inadequate tools, for instance, but which are the most important to invest in? To invest wisely, we need to determine which ones will yield the biggest payoff.
In their research, they put together a list of 48 factors that impact productivity:
We developed this comprehensive set of factors to ensure we covered all relevant aspects. These factors include those related to individuals, communication between teammates, developer tools, and distractions—anything impacting developer productivity, based on prior research.
As an example, they asked each developer how enthusiastic they are about their work – typically called “employee engagement” – then correlated that rating with developer productivity.
The complete list of factors can be found in Figure 4 in their paper What Predicts Software Developers’ Productivity?
Murphy-Hill mentioned that they also explored inequities in software engineering. They concluded that productivity factors affect developers differently based on their demographic groups in surprising ways.
For example, conflict arises more often during reviews of code authored by engineers from historically marginalized groups, such as female, older, and black engineers, Murphy-Hill said. This highlights that biases are present in engineering environments and can be worsened or mitigated, depending on how we design these environments, as he explained:
We built and tested an “anonymous” code review tool that doesn’t initially name or show a picture of the person who authored the code as a way to mitigate the effect of bias.
To recognize symptoms of problems that impact engineering productivity, Murphy-Hill suggested listening to what your engineers are telling you.
To adopt a more systematic approach, it is essential to run regular large-scale surveys to identify the most common and severe productivity challenges, Murphy-Hill said. Additionally, if your engineering productivity research organization is mature enough, you can examine quantitative metrics for productivity, such as the time taken to submit code or run builds.
Murphy-Hill mentioned that while people often perceive numerical data as more credible than anecdotes or experiences, those personal insights can be incredibly valuable and lead to effective solutions. In contrast, quantitative productivity data frequently leaves you questioning the reasons behind the numbers, he said.
Accountability is crucial; share the data you’ve collected widely, and explain the actions taken based on it, Murphy-Hill said. This builds credibility and encourages future participation in engineering productivity research, he concluded.
InfoQ interviewed Emerson Murphy-Hill about building diverse engineering teams and improving productivity.
InfoQ: What works for building and sustaining highly diverse engineering teams?
Emerson Murphy-Hill: When we spoke with the most diverse engineering teams at Google, they emphasized that their success in building diversity depended on two primary factors: 1) equitable recruiting and hiring practices, and 2) supporting underrepresented engineers through what we call “technical allyship.”
For example, hiring managers reported they were most successful when they both “talked the talk” and “walked the walk.” When a candidate from a historically marginalized group considered joining their team, these managers ensured that they discussed how the individual would be supported and provided growth opportunities.
InfoQ: What doesn’t work?
Murphy-Hill: What doesn’t work is just saying that you care about diversity, without any actions to back it up. The managers who we spoke to offered concrete examples of previous actions taken to support individuals.
InfoQ: What’s your advice for improving productivity?
Murphy-Hill: A simple method is just for leadership to listen to engineers, who can often name their biggest productivity challenges.
To boost productivity in a small company or within a team (say, under 100 engineers), gather open-ended feedback to identify pain points, considering both frequency and severity. In larger organizations, use closed-ended questions about specific experiences, like build speed or collaboration issues.
