How To Use Technology to Measure 4-Day Workweek Success
Does the four-day workweek work? To find out, a Seattle-based startup leveraged software tools to track and analyze data around pull requests, Deep Work, meetings, interruptions, and always-on behavior. In this article, Joe Levy, CEO, Uplevel, discusses the experiment’s results.
Is the four-day workweek radical or obvious? That’s what we wanted to find out. Could we get the same amount of work done in fewer days? And what impact would it have on our team?
With these questions in mind, we began our four-day workweek experiment in January this year, testing a condensed Monday to Thursday schedule for three months. We were among a very small wave of companies daring to challenge the norm, yet it’s hard to believe it’s taken this long. The world has changed drastically since FDR effectively formalized the 40-hour workweek into law with The Fair Labor Standards Act of 1938. Logic would suggest that the workweek should change, too.
We believed the experiment would work, but we needed to collect both qualitative and quantitative data to understand the impact of cutting down from five days to four. We leveraged technology solutions to make sense of the data and reveal indicators of work, focus, collaboration, and process.
Before starting our experiment, we held an internal hackathon for our teams to engage in cross-functional brainstorming. Together, we developed our definition of success, with each team establishing its own metrics and protocols. We shared these criteria with an organizational research scientist to develop survey questions to measure success throughout the experiment.
Did we hit our roadmap goals? Was it easier to get work done? What was the impact on our effectiveness metrics: pull request (PR) activity, Deep Work, time spent in meetings, interruptions, and always-on behavior. These were just some questions we asked to determine four-day workweek success.
How We Measured the Qualitative Impact
It was relatively easy to collect employee feedback through pulse surveys as well as 1:1s, all-hands, and informal conversations. And we used this qualitative data to measure team happiness and productivity before, during, and after the experiment. Our pre-implementation survey gave us a baseline to measure against, and we continued to collect monthly feedback with short mid-month pulse surveys in Slack to check in quickly. Ultimately, a post-experiment survey provided our final look into how our employees felt about the four-day workweek.
Unsurprisingly, the results were extremely positive. Employees reported feeling more productive and satisfied with work. They had more time to exercise, focus on professional development, and tackle personal responsibilities. And many still worked on a Friday at some point, though typically no more than a few hours.
For the most part, we expected these results — who doesn’t want a shorter workweek? But we didn’t want to rely solely on qualitative data. Employee feedback alone wasn’t enough to truly discover if the experiment was a success. Instead, we wanted to determine the quantitative impact of the four-day workweek on productivity, which is much more difficult to measure.
See More: 8 Strategies To Help Employees Adapt to New Technology in the Workplace
How We Measured the Quantitative Impact
We relied on hard data to measure the quantitative impact, using our own software technology to track PR activity, Deep Work, time spent in meetings, interruptions, and always-on behavior. With this quantitative data in hand following our three-month experiment, we were able to better assess the impact of a shorter week on dev team productivity. These insights, paired with the qualitative feedback from our employees, gave us the confidence we needed to make a final decision on whether to continue the four-day workweek.
So what did the quantitative data tell us? Despite having fewer days to complete our work, product delivery volume actually increased. Our dev team used digital analytics tools to track sprint progress and PR workflows, looking at the overall number of tickets completed and their estimated complexity. Both went up during the experiment, meaning we got more done and worked on more high-impact projects. We also onboarded more customers than any other quarter to date.
These results aren’t all that surprising when you look at our other findings from the experiment. We pulled from the tools our people use most — Jira, Slack, calendars, and more — to establish effectiveness metrics for our teams. Each data point told us something, and only by weaving it all together through a single insights solution were we able to tell the entire story.
The first of these metrics was Deep Work, which we defined as two or more hours of uninterrupted work time. We used machine learning to analyze working patterns, calendar trends, and activity time, helping us quantify available focus time throughout the experiment. Overall, Deep Work either increased or stayed the same across our teams, the result of our efforts to actively protect that time.
One way we protected Deep Work was by rethinking our meeting culture. We established guidelines to help our teams shorten and consolidate meetings, removing those that weren’t providing real value. We then used the insights solution to analyze high-level details around meeting duration, titles, and the number of participants, helping identify meeting distribution among individuals and teams. The data showed that our meeting hours and average length either decreased or stayed the same throughout the experiment.
We also measured data around Slack interruptions, which cut into Deep Work time. We quantified the impact of each interruption based on the speed and brevity of the response. The results showed an increase in interruptions for our dev team, likely due to this increase in Deep Work time, as there were more opportunities to be interrupted.
Finally, we looked at how often our people worked overtime or on weekends. These “always-on” metrics helped us determine if our developers had to work beyond their normal eight-hour workdays to make up for the shortened week. Even without Friday work, we did not see a statistically significant change in always-on scores, suggesting our people got the same amount of work done in fewer days.
In the end, we had collected enough metrics to make a data-based decision on if we would continue with the four-day workweek.
Did the Four-day Workweek Work?
We not only met and even exceeded our product delivery goals but also took significant steps in preventing team burnout. Based on these results, 100% of our employees wanted to continue the condensed workweek, and we decided to extend the experiment through the end of the year.
If at any point, the four-day workweek stops supporting our business goals or we can no longer be responsive to customers, we will pivot fast. I don’t see that happening, but we must be mindful of the possibility and prepared to change course. We must constantly push ourselves to think about how we can work more effectively, especially with fewer days to do so.
For now, the four-day workweek is working for our team, but that doesn’t mean it will work for everyone. You must have a culture of trust — of outcomes, not hours. When you trust your people to bring their full selves to work and get things done, they will. And they’ll do it in four days.
Have you implemented a four-day workweek? What are your findings from the experiment? Let us know on Facebook, Twitter, and LinkedIn.
