RDEL #3: The top productivity factors for engineers

What do engineers rate as their highest productivity factors, and how do they compare across three culturally different companies?

Happy Research Monday! Each week, we pose an interesting topic in engineering leadership, and apply the latest research in the field to drive to an answer. Hope you’re staying cool wherever you are - unless you’re in SF, where it’s still only 65 degrees. ⛅

This week, we think about engineering productivity - a hot topic in engineering leadership. Our analysis this week takes a unique approach at looking at what factors improve productivity for engineers.

The context:

With a push to get leaner in this challenging market environment, companies have been evaluating their internal processes and looking for opportunities to improve. Central to this effort is developer productivity, a field that focuses on finding on improving the ratio of software outcomes to the cost spent for it.

There are a number of frameworks to help managers understand a team’s level of productivity (and we’ll cover our favorite, the SPACE framework, in another newsletter). Most often, however, developer productivity can be significantly improved by just talking to developers.

While managers often turn to developer tooling as a starting point for productivity, this paper provides evidence for the fact that the biggest improvements can often come from non-technical factors.

The research:

Researchers studied the top productivity factors using a sample of engineers from Google, ABB, and National Instruments. They first asked engineers how often they feel productive at work, and modeled the responses against two “objective” productivity measures (lines of code written and changelists). Though the number of changelists performed slightly better than lines of code, both models had low % of variance explained - reflecting that lines of code and changelists are only a small part of a developers estimate of productivity.

Next, they drew from a wide set of literature and reviews from engineers to narrow a list of 48 productivity factors for software engineers, and asked ~600 engineers across Google, ABB, and NI. They compared responses to a group of 88 analysts at Google to eliminate common factors, leading to factors only specific to software engineers.

Interesting results include:

• The top ten productivity factors were non-technical.

• The top three productivity factors were -

  1. Job enthusiasm

  2. Peer support for new ideas

  3. Useful feedback about job performance

• Across different companies, researchers saw different levels of variance in certain categories of responses. The lowest variance in factors were all social and environmental (use of remote work to concentrate, useful feedback about job performance, peer support for new ideas). This indicates that developers across all companies are equally affected by these three factors.

• Use of best tools and practices was the factor with the highest variance - at Google this was strongly related to self-productivity, but at National Instruments this was weakly related. The researchers theorize that Google may have a more complex codebase than National Instruments.

The application:

This paper provides evidence for the idea that developer productivity is not just about tools and systems - in fact, the most important factors often come from non-technical improvements (ie job enthusiasm).

For managers looking to improve developer productivity, this paper adds to the body of literature that suggests the best way to start improving productivity is to talk to your developers. A great way to get a high-level signal of where developers want to see improvement so by conducting a broad, anonymous survey asking developers to select the top technical and non-technical factors they’d like to see improved. To get more specific feedback, consider an open conversation with the team in a high-trust environment.

Developers, not code, are the key to improving developer productivity. You can get some great information from system data, but the best data comes from the developers themselves. It’s their day-to-day work, after all.

—

Thanks for reading, and see you next week 🎉

Lizzie

From the Quotient team