Pixel?tag=viewcontent&noscript=1

Impact of working from home on software engineering throughput

By Bill Harding at 8:35am on April 23, 2018

What's the productivity cost of allowing engineers to work remotely? With recent remote work defections from the likes of IBM, Yahoo, and Github, there seems to be a crisis of confidence among managers that their employees won't function optimally unless they're on the premises. However, among workers at large, Google Trends suggests that interest in the theme has only increased over the last five years:


Google Trend result for "work from home" interest over time

If we set aside emotions and anecdotes, I suspect most companies are genuinely uncertain what they're giving up when they allow employees the option to work without physical supervision. It's squishy-yet-vital questions like these that get us up in the morning to work on Static Object. The true cost of remote working isn't known because it depends. Specifically, it depends on circumstances like: composition of staff, nature of work being done, and the particulars of how the remote work policy is implemented.

Below, we provide a case study of how we evaluated our remote work policy at Bonanza.com. I would speculate that many software-based organizations would see similar results to what we observed, but that hypothesis lacks sufficient data to be proven (yet). The value we hope to deliver our reader: to show how collecting the right metrics allows a business to separate end result from means of getting result. Without measurable results, it's easy to get caught up focusing on the means of work, when managers would be better served to isolate and analyze their end result.

Crack open the data

At Bonanza, our policy is that employees are welcome to work remotely every Wednesday, we refer to this benefit as "WFHW" (aka "Work from Home Wednesday"). This, combined with our relative paucity of meetings (developers average under 5 hours/month in meetings) allows us to analyze a developer's throughput on Wednesday to get a relative sense for how effective the average developer is at home vs on site.

And so without further ado, let's hear it for big dots!

This visualization comes from the main "Stats" page -- any Static Object user can check their own project's Punch Card as the third tab presented when viewing a repo, organization, or entity (collection of organizations). The size of each dot corresponds to how much Line Impact was accumulated during that day over the course of the past year. Here are the numbers underlying that visualization:

  • Tuesday: 192k (100%)
  • Wednesday: 171k (89%)
  • Thursday: 164k (85%)
  • Monday: 150k (78%)
  • Friday: 125k (65%)

There's a lot to unpack here.

For starters, the difference between our most and least productive day is 35%, more profound than I would've predicted. But it's not the WFHW policy underlying the outlier. Rather, it's a different company policy: at 3:30pm on Fridays, we stop working to get everyone together and present what we got done over the past week. We implemented this policy based on the belief that there is an unmeasurable, qualitative increase in cohesiveness brought about by putting everyone in the same room to discuss what's new. When we instituted this practice, it wasn't obvious to me that we were effectively truncating 25% of our team's Friday GSD-potential. The numbers make abundantly clear the cost we're willing to pay for cohesiveness.

We have no plans to change our Friday routine, but it helps shape our future policies to note that our two most event-filled days (Friday and Monday) are the least productive days of the week when it comes to getting code written.

Meanwhile, the recipe that has allowed Tuesdays to stake their claim to "Greatest Day of the Week" is pretty simple: there are virtually no meetings, events or other distractions at Bonanza on Tuesdays. It probably also benefits incrementally from weekly planning time that is invested on Monday.

As for WFHW, a second place finish is encouraging at face value. Scratch under the surface and it becomes more impressive still, since almost all doctor/dentist/therapist appointments at Bonanza get scheduled for Wednesdays. Giving our employees flexibility with their Wednesday working hours has led these appointments to be subsumed with no apparent penalty to engineer throughput.

Decision-making with emotion

The internet's arguments for and against allowing remote work have often involved emotion, speculation, and story telling. In this regard, it's not much different than the discussion surrounding the perceived productivity effects of "pair programming," "stand up meetings" or "stand up desks." Each has its share of advocates and detractors making passionate arguments in favor of their pre-existing worldview. The onus is on management to set aside biases and choose the policy best aligned with their circumstances, then explain their qualitative explanation in a way that minimizes the antipathy among detractors.

Decision-making with data

Given the time & emotional energy required to render judgment on a subjective issue like remote work, managers could be forgiven for optimizing their policies to maximize conventionality. To implement an unorthodox policy requires confidence in our ability to accurately, dispassionately -- and hopefully quickly -- interpret how end results are impacted by a policy experiment. In the case of WFHW, Static Object provided us incontrovertible evidence that, for our present circumstances, this type of remote working is an unambiguous win for both morale and productivity.

We find similar nuggets of insight when we look at how other events correspond with changes to engineering throughput:


Mapping company events to throughput aberrations improves decision-making over the long term

Absent this data, management might instead focus on how our WFH day begets absenteeism via appointments and errands. In this alternate, emotion-driven world, we might try to count up the hours of absenteeism and extrapolate how much work was being squandered by our WFH policy. Armed with data, we find that WFHW absenteeism reflects only how productive our team can be in spite of absenteeism.

One of our foremost goals in building Static Object has been to empower management to create their own custom-tailored workplace policies that make life better for employees. We understand that it's scary for managers to increase team freedom when they don't know the cost. You wouldn't let a friend borrow your car without knowing their driving record and sobriety. Without reliable metrics, decision-makers will err on the side of caution & routine. With reliable metrics, you find that one of the most routine aspects of running a business -- meetings -- is one of the most costly.

This is one of several examples we've found where capturing reliable metrics is an ace in our back pocket, allowing us to create a workplace that purposefully defies conventions. Possessing data, we become rebels with good cause.