Unlocking the Potential of Hybrid Work
Inefficient processes, too many meetings, and tools are hindering developer productivity.

Unlocking the Potential of Hybrid Work

This is the latest issue of my newsletter. Each week I cover research, opinion, or practice in the field of developer productivity and experience. 


This week I read The Best of Both Worlds: Unlocking the Potential of Hybrid Work for Software Engineers. In this research study, Microsoft partnered with Vista Equity Partners to investigate the factors that hinder developer productivity, and how companies with hybrid work environments can address these challenges.

This paper is relevant for two groups: it surfaces common problems that leaders can address to improve developer productivity. For internal-facing developer productivity teams, this paper also demonstrates the importance of investing in improving internal tools and inefficient processes. 

My summary of the paper

Hybrid work holds the promise of allowing employees to have work-life balance while also having social connection with colleagues and being productive. However, current research says that we have not yet figured out how to fulfill this promise. Researchers here sought to help fill that gap by identifying the unique challenges of hybrid work in software engineering.

27 companies of various sizes, industries, and locations — all from Vista Equity Partners’ portfolio of companies — participated in this study. Researchers began by interviewing the participating companies about their hybrid work policies. Then they ran a survey for two weeks, and collected 3,400 survey responses from software engineers. 

Here’s what the study found: 

Remote work does not equate to “lower productivity” 

Researchers first explored what model is “most productive”: remote, hybrid, or in-office. To help answer this question, they analyzed responses to the question: "I have experienced high levels of productivity in the last six months," which was answered on a scale of 1 = strongly disagree to 5 = strongly agree.

Developers who work entirely remotely reported the highest level of productivity, followed by those working from a mix of home and office. Those working full onsite reported the lowest level of productivity. The differences in productivity ratings between the three options are statistically significant. 

No alt text provided for this image

The researchers note, “It may be tempting to look at the figure above and jump to the conclusion that remote work is ‘better’. It is more likely an indication of two critical concepts: 1) that remote work does not equate to lower productivity, and 2) that hybrid work is more challenging to optimize.” 

Developers miss social interaction, but do not want more meetings

To identify the key challenges developers face at work, survey respondents were asked the question, “What have been the biggest work challenges that you have experienced over the last 6 months?”. Respondents selected one to three challenges from a predetermined list, based on the interviews before this survey as well as from previous studies.

No alt text provided for this image

Missing social interaction

One of the most frequently cited challenges is “missing social interactions.” Interestingly, this challenge is not limited to fully remote developers: fully onsite developers are 8% more likely to miss social interactions than fully remote developers. To explain this finding, researchers propose these hypotheses: 1) meetings do not fill a need for social interaction as they are inherently transactional, 2) when developers come to the office, the people they want to meet aren’t there. 

While social interaction is an important human need, it does not yet appear to have a business impact. Individuals who report missing social interactions are just as likely to be feeling productive as those who do not report missing social interactions. 

Too many meetings

Shifting to remote work has increased the number of meetings developers have as well as the length of each meeting. The researchers explain: “What used to be a five minute hallway conversation turned into a 30-minute meeting.” In this study, one in three developers reported having too many meetings.

Prior research has found that too many meetings can lead to burnout. Meetings also come at the expense of more fulfilling work. The researchers suggest that teams shift some meetings to asynchronous communication. 

Inefficient work processes

This may be the costliest challenge to developer productivity and satisfaction. Individuals who reported inefficient work processes as a top challenge were more than 2x as likely to say they were feeling unproductive, compared to the average developer. They were also 68.6% more likely to say they were dissatisfied with their jobs. Additionally, they were 66.8% more likely to say they were looking for jobs at other companies.  

“No challenge in our study appears to be a bigger risk to retention than inefficient work processes.”

Developers should choose where to work based on the tasks they’re doing 

As part of this study, researchers explored what causes developers in hybrid environments to choose to work in the office. As seen in the table below, the most frequently cited cause for deciding whether to work in the office was personal reasons. The researchers note that this may explain why developers are missing social interactions: “When choosing where to work for personal reasons, it’s essentially random if you’ll overlap with other colleagues.”

No alt text provided for this image

Not all spaces are equally tailored to every kind of task: home offices are likely more tailored for focused work, while office spaces are more tailored for collaboration. This study found that developers who choose where to work based on the focused tasks they were doing that day were 12% more likely to feel productive than developers who choose where to work based on personal reasons. Similarly, developers who chose where to work based on the meetings they had were 11% more likely to feel productive. Since not all spaces are created equal, developers should choose where to work based on the task they will be doing that day. 

Developer tools are a top barrier to productivity 

Participants were asked the question, “When thinking about your development tools and processes, what is the biggest barrier to your productivity?” The most frequently mentioned barrier was developer tools, followed by too many meetings. 

No alt text provided for this image


Insufficient software tools were a challenge for new hire developers in particular. New hire developers are 40% more likely to say that “Insufficient software tools” was a top workplace challenge, and the impact to their productivity is 37% greater than it is for more seasoned developers. While tooling is also a challenge for senior developers, it is likely that they have developed workarounds. 

Final thoughts

For leaders considering how they can improve developer productivity, this paper provides insights into common areas of friction and how costly they are. It also provides recommendations for companies where developers are missing social interactions or have too many meetings: the authors suggest replacing meetings with asynchronous communication, carefully planning in-office days (if they exist), and encouraging developers to make decisions about whether to come in the office based on their tasks that day.   


Thanks for reading. As of today, my Substack also includes podcast episodes from the Engineering Enablement podcast. To further simplify things, this newsletter has also been renamed to Engineering Enablement so that everything is under the same brand.

Since the release of my paper last week, many people have asked me for advice on how to get started with DevEx surveys. My latest podcast episode is a great resource to get acquainted with this, so here it is:

If you’re finding this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already.

Jared Spataro

Chief Marketing Officer, AI at Work @ Microsoft | Predicting, shaping and innovating for the future of work | Tech optimist

1y

Great article, Abi. We know employees enjoy a lot of benefits from flexible work, and it’s clear there are benefits to employers too. The key is having the tools and tech, cultural norms and practices that enable the best of both worlds for everyone. That’s something we’re continuing to focus on here at Microsoft. I think you’re right that trust and communication is critical. Thanks for sharing.

Jen C.

Software Developer ⚙️⚔️🧙🏻♀️ Tech Lead

1y

I'd be curious about a thinkpiece on what it's like to work at Microsoft, vs being at a company that really likes to use Microsoft, Adobe, or any vendor wholesale.

Like
Reply
Jen C.

Software Developer ⚙️⚔️🧙🏻♀️ Tech Lead

1y

Hmmmmmm

Kyle W. Ludwig

Mobile Developer Support Engineer

1y

To add to the idea of the meetings, one solution I've liked a lot is just regularly scheduling 1-on-1 meetings every ~2 weeks to catch up with my immediate co-workers (e.g. other iOS developers on my team) when working remotely. Since group meetings can be necessary to understand the problem/solution domain, I feel like this practice can mitigate the risk of group meetings becoming personal discussions and let us "nerd out" on implementation details separately if we want. 🤓

Alex Herweyer

Advocating effective software delivery

1y

As usual, an interesting summary of what is likely a rather dry research paper. I’ve found these themes called out in the paper to be true in my experience. Meetings don’t fill the ‘human connection’ gap when it comes to high trust work. When you take that fact with ‘Speed of Trust’ thinking, it can really impact software delivery performance. Side note, the question phrasing about developer tooling appears to prime the respondent to say ‘developer tooling’, which is the top answer. That makes me wonder if it would have been better to phrase the question more vaguely.

To view or add a comment, sign in

Insights from the community

Others also viewed

Explore topics