Does a four-day work week… work?

How does a four-day week impact team productivity?

Reports from companies that have made the move are light on data. There’s sentiment analysis based on surveys, which matters, but which in this case seem only to confirm common sense. People are happier with fewer hours in-office (even if the office is now at home), and feel more engaged when they’re there.

As we considered our own move to a four-day week, we wanted data that would tell a more complete story on the effects of a shortened work week. (Data isn’t much fun if it doesn’t let you poke at longstanding beliefs about how work should be done. True whether you’re looking at Agile, the use of deadlines, or, say, [estimating](https://socraticworks.com/methods/post/Stop-estimating.-Start-shipping.).)

In our case, we wanted to see how a four-day week would impact the three measures that say the most about engineering health: throughput, speed, and efficiency.

Our method

We began our experiment in October 2021. Starting that month, we implemented a four-day week.

The most important variable in this experiment is obviously the team itself. In our case, the actual names and total team size remained consistent through the periods in question. We’re a virtual team, and remained so. We didn’t go on a hiring spree, or change our working hours, or swap junior resources for senior ones (nor vice versa).

A second key variable is the type of work performed. As a startup, we have an advantage as a control group: all of our team remained focused on the same, single offering.

Obviously, we also need a common unit of measure for work. In engineering, there are two candidates: tasks, and code. We use tasks. There are a couple of reasons for this. First, tasks, unlike code, are a unit of measure non-engineers can understand. Second, quantity—getting more done—is inarguably good where tasks are concerned. The more tasks completed, the better. (The same isn't always true of code. ”More code” may or may not be a good thing.)

What interested us was seeing how our productivity changed across:

• Throughput: that is, number of tasks delivered.

• Speed (or cycle time): average days to complete a task. As a component of this, we also measure average time to

  merge pull requests.

• Efficiency: how much of our work remained in a good flowing state, versus exception states like rework, deprioritized, idle, blocked.

With Socratic, we get all this data out of the box.

What we learned

The following shows changes in our own engineering productivity over two periods: a six-month period of five-day weeks, versus a six-month period of four-day weeks. (These periods are sub-divided into quarters, for the sake of trend granularity.)

Throughput

In aggregate, the amount of work we delivered decreased by about 14 percent period over period. But the quarterly trend tells a more nuanced story. Our throughput in the first two quarters of four-day weeks actually met or exceeded throughput from the final quarter of five-day weeks.

Speed

A word on how we determine speed. Socratic automatically measures the elapsed calendar days from the time work starts on a task, to the time it’s completed. So, if work begins on a Monday and finishes the following Monday, the total elapsed time for that task is 7 days.

In moving to a 4-day week, we saw no change in the average number of days (5) it took us to complete a task.

This fact may be the most surprising, since we were working one fewer day per week. With a day less day per week to do the work, we assumed an average speed of 5 days would increase to something like 7 days—you start on a Monday, but now finish the following Monday because you didn’t work Friday. Instead, our average speed remained constant.

Just as encouraging was the change in average time to merge a pull request. In the period of five-day weeks, this was just under a day. In the four-day week period, merge time decreased by roughly a third.

Efficiency

In brief, we measure efficiency by comparing the amount of time that work spends in a good, flowing state—that is, moving from start to finish as smoothly as possible—relative to time spent in these common exception states: deprioritized, rework, blocked, or idle.

For example, if a task takes 5 days to move from start to finish, but along the way is blocked for one day, its flow efficiency is 80 percent. Four of its five days (80%) were in a normal, flowing state, with one day (20%) in a blocked state. (Our method is described in more detail here.)

Here again we saw improvement, albeit small, in moving from a five-day week to four.

The immeasurables

With the exception of our throughput (caveated above), moving to a four-day week had either no negative impact on productivity, or coincided with improvement. This is to say nothing of the qualitative benefits we’ve experienced: a better work/life balance for our team, and a competitive edge in recruiting and retention.

In the words of one team member: “The extra day off helps me keep a better work life balance and take better care of my personal life. I'm much more focused while I'm at work than at previous jobs.” Another says, “I'm less likely to feel burnt out after the end of a work week. I get to enjoy new hobbies and activities. It was a deciding factor in choosing to work here.”

The quantitative and qualitative together made our decision an easy one. The ‘experiment’ of a 4-day work week is now permanent.