Post-pandemic Remote Work and the Developer Experience

Recently, there has been an outpouring of commentary from CEOs in tech on the need to return to the office — there have been many strong reactions ranging from preposterous to realistic. Here is a sampling:

“[…] Get off the goddamn moral high horse with the work-from-home bullshit because they're asking everyone else to not work from home while they do.” — Elon Musk, CEO at Tesla and TBD at Twitter (source →)

“Engineers who started out at Meta in a fully in-person capacity before transitioning to a remote role, as well as those who have remained in an in-person role, performed better on average than people who joined remotely […] our hypothesis is that it is still easier to build trust in-person and those relationships help us work more effectively.” — Mark Zuckerberg, CEO at Meta (source →)

“New employees (hired during the pandemic in 2021 & 2022) are especially facing much lower productivity. […] Are we not building tribal knowledge with new employees without an office culture?” — Marc Benioff, cofounder and co-CEO of Salesforce (source →)

Remote work doesn’t come without its challenges (which we all know very well, from small issues like technical glitches to bigger issues like burnout).

However, does it really have such a detrimental impact on team productivity?

Although these statements can apply to all remote workers, we have focused specifically on development teams, since we know this audience the best.

What affects developer productivity?

Measuring the productivity of any knowledge worker, such as an engineer, is a hard problem: developers engage in a variety of complex and creative tasks beyond just writing code (mentoring, reviewing code, designing systems and features, managing releases, etc.)

Pounds of coal shoveled per hour will tell you which shovelers are the best shovelers; lines of code per minute will not tell you which software developers are the best software developers. - A Human-Centered Approach to Developer Productivity

One way to evaluate this is through the lens of Developer Experience (DevEx): it focuses on the points of friction devs encounter in their everyday work, using up to 25 sociotechnical factors to assess productivity (e.g. interruptions, unrealistic deadlines, friction with tools, unclear goals, lack of psychological safety, etc.).

These factors can be grouped into 3 critical buckets — feedback loops, cognitive load, and flow state — which together affect “business performance through increased efficiency, product quality, and employee retention” (source →).

Additional perspectives can be gleaned by examining data, as Jellyfish did in their “The State of Engineering Management in 2023” survey. They found that the key difference between underperforming and overachieving teams is being able to align engineering resources to business priorities, especially now that teams are being asked to do more with fewer resources due to headcount reductions and hiring freezes.

Weaving all of these findings together was one persistent theme: the need for a purposeful and consistent effort to build effective communication and implement thoughtful technology best practices.

What is the impact of co-location on developer productivity?

As you may have noticed, working in the same office was not among the most impactful factors listed in the previous paragraph.

In fact, when companies like Etsy, LinkedIn, and Pfizer wanted to improve their developer productivity, they focused on friction points like the ease of release, balancing technical debt, on-call experience, etc.

Likewise, the most critical factors considered for the McKinsey Developer Velocity Index are related to technology, working practices, and organizational enablement (e.g. choosing the right mix of development tools, embedding automated controls throughout the pipeline, participating in open-source communities, etc.).

Are we saying that working in the same office has no significant benefits? Absolutely not.

In fact, working in person has distinct benefits for collaboration, learning, and innovation:

• Remote workers missed opportunities for cross-team collaboration - as seen in a study of Microsoft’s remote workforce in the first half of 2020.
• People who interact through a screen are less likely to generate creative ideas - see this 2022 study.
• New hire onboarding, shadowing, and ramp-up can be longer and more effort-intensive without the in-person presence of experienced colleagues.

However, this is not all bad news. Some of the downsides of not working together in the same place can be mitigated.

Given that factors such as geographic and time zone dispersion do indeed affect how people communicate, remote teams need to be purposeful and thoughtful about how they drive collaboration, cross-pollination, and creative brainstorming. It’s not impossible to create space for serendipitous moments that can lead to innovation and problem-solving - it’s just harder!

Remember, pandemic remote work and purpose-built remote work are not the same things (source →).

Software developers are humans

Happy engineers build better code. Companies that achieve optimal working environments for developers, also achieve revenue growth four to five times faster than their competition, not to mention have more innovation, customer satisfaction, and better brand perception.

However, engineers are also humans, and their job satisfaction is affected by the same things that make being a human harder or easier.

For example, it’s safe to assume that, like most responders in a recent Washington Post survey, “pay” would be an important factor towards job satisfaction, followed by “a good boss or manager”, “your work helps people or society”, and “ability to work from home/remotely”.

Assuming that the top 3 factors are satisfied, there is an increasing amount of data in support of “job flexibility” being a major selling point:

• As found in a 2022 survey by Terminal, 4 out of 5 software engineers would prefer to work remotely.
• 91% of responders in this Miro survey say remote work is a good fit for them and 96% would recommend it to a friend.
• 55% of the remote workers interviewed by the Washington Post would take a lower-paying job to keep working from home.
• Job satisfaction has hit a 36-year high in 2022, due to hybrid work arrangements, and the tight labor market that has allowed people to move to more satisfactory jobs.

And it’s not just the stress of having to commute (which, by the way, is the biggest gripe with workers). It’s the extra costs associated with going into the office, the stress of having to relocate (and deal with the current housing market! 🥲), a potentially more complex childcare scenario, the constant interruptions, etc.

The popularity of working remotely had been rising steadily for several years pre-COVID: if we look back to 5 years ago, a 2018 Buffer survey found that 90% of remote workers planned on working remotely for the rest of their careers, and 60% of the occasional remote workers were interested in increasing the amount of time they work remotely.

An Owl Labs survey from the same year shows that those who work remotely at least once a month are 24% more likely to feel happy and productive in their roles (and a big portion of remote workers were in the software industry).

Ultimately, people are most happy and productive when they are working in whatever framework makes them feel fulfilled. There are many different combinations of in-person and remote work, each best suited to the specific individual and use case. Imposing one framework on a multitude of teams and people will inevitably lead to friction and churn.

Distributed teams for distributed systems

Most modern software systems are distributed systems, and this is reflected in the developer teams that design, develop, and manage them. In other words: if you have a global, highly-available distributed system, chances are that you’ll need a global, distributed team that communicates, collaborates, and brainstorms together.

Even if you decided to centralize all your developers in specific offices around the globe (which is not always feasible or cost-effective), no company can be perfectly split into silos of teams that never interact — nor would you want it that way.

Furthermore, it’s common for developer work to start out decentralized, become centralized, and then move back to being decentralized (source →) and continue cycling through these stages.

Remote collaboration (between teams and individuals) is a must, and fortunately, developers can choose from a plethora of tools to make this easier.

It’s not remote work, it’s everything around it

Leaders today are more focused than ever on optimizing the efficiency and effectiveness of their teams, especially with the trends in slowing revenue growth.

Coupled with the onset of “productivity paranoia” in managers during the pandemic, we wonder if there are broader issues at play in terms of how companies administrate their remote workforce.

For example, could it be that the main difference between highly functional distributed teams and their colocated counterparts is the amount of trust and autonomy leaders give their teams?

Organizations must evolve their approach to workplace culture and change their productivity metrics to be more human-centric if they want their employees to thrive.

The ones that adapt to a “distributed world” are able to rewrite the rules of the workplace and reap the rewards of a diverse and global talent pool. And, once employees are on board, it is incumbent upon them to find an approach that makes employees feel seen, supported, and trusted so they can function effectively in a distributed environment.

---

At Multiplayer, we fully embrace remote work and our mission is to enable distributed teams to design, develop and manage distributed software - if that sounds good to you too, sign up for free now!