The pandemic has forever changed the workplace, causing many in the tech industry to now question the traditional five-day workweek. One proposed solution is a four-day workweek, which some believe promises to redefine workplace productivity and employee happiness. Research shows those working four days per week report higher well-being, less burnout, and improved productivity.
But the four-day workweek is not a one-size-fits-all model, and adopting one could be detrimental to teams that overlook underlying issues in their workplace culture. In cases where teams experience high friction in their development processes, compressing the workweek and removing flexibility may exacerbate burnout.
For instance, when software developers spend significant time in meetings – upwards of ten hours per week on average – a four-day workweek may actually lead to longer, more stressful days as developers struggle to find time to code.
The impact of friction on development teams is measurable. Recent data from more than 250,000 developers reveals developers code about 52 minutes per day – about 4 hours and 21 minutes during the workweek. A four-day workweek may have the unintended consequence of further reducing that average.
[ Related read: Asynchronous remote work: 5 tips for success. ]
3 alternatives to the 4-day workweek to reduce stress
Before adopting this change, teams should first prioritize a better developer experience: promoting schedule flexibility, prioritizing time to code, and investing in DevOps tools and processes that allow developers to do more meaningful work during work hours.
1. Asynchronous communication and continuous documentation
Companies can enhance the developer experience by giving developers flexibility and freedom to set their own schedules for a better work-life balance.
Most teams need only a few hours during the workday when all team members are online and available for meetings and collaboration. In fact, many developers choose to work during early mornings or late evenings, which are often free from distraction and interruption. Teams can promote schedule flexibility by adopting two new cultural practices: asynchronous communication and continuous documentation.
With asynchronous communication, developers spend more time writing and sharing detailed updates about their work, such as project tickets, pull request comments, and emails, which other team members can then read on their own time. Meetings are the last resort, not the default option, for collaboration. Writing ideas down helps solidify those that are more likely to dissolve in meetings or chat conversations.
For example, developers can record demos of their changes when asking for feedback on their open pull requests. Other team members watch these updates when they are online, instead of scheduling meetings or pinging coworkers to review their work.
Documentation becomes stale when it’s updated periodically. All team members should be responsible for continually documenting their code changes as a product is updated. When team knowledge is easily discoverable and up to date, developers can access the information they need at any time rather than waiting for other team members to be online.
Commit messages and pull request comments are one way to document changes. Some teams also link issues and tasks directly to pull requests and commits. By treating documentation like code, teams can ensure that documentation stays relevant.
2. Protect deep work, avoid context switching, and reduce meeting load
Most developers already work overtime in a five-day workweek. According to the 2020 Stack Overflow Survey, more than 75 percent of developers work overtime at least occasionally, while 25 percent work overtime at least once per week. Moreover, about one-third of developers code on the weekend.
Developers juggle meetings, disruptions, and context switches, which often prevents them from doing their most creative work during their most productive work hours. As a result, a standard five-day workweek can bleed beyond its boundaries, making work-life balance fragile for many software developers.
Teams can reclaim time for focused, uninterrupted work by prioritizing time to code. Leaders should encourage their team members to set placeholder events during their most productive times that show them as busy to their coworkers. Teams can block off the global top code time – 3 pm to 5 pm – every day for coding. They can also schedule team focus blocks during the morning or allow individuals to set their own focus blocks. Scheduling time for focused work minimizes context switching and helps developers stay in the flow, especially during busy work hours.
[ Suggested read: Meeting-free days: 11 productivity tips from IT leaders ]
Leaders can also think more strategically about how they schedule team events, with the goal of striking a healthy balance between meetings and asynchronous work. When meetings are spaced out throughout the workday, with short periods of free time between them, developers may defer important work since they will soon be interrupted. After meetings, they need time to regain momentum and get back in the flow. Proactively scheduling meetings to be closer together can help avoid fragmenting team members’ calendars.
3. Invest in DevOps tools and processes
If the ultimate goal of moving to a shorter workweek is to improve team happiness, leaders should also remember that time is only part of the equation. Stress stems from not just long hours, but also the quality of those working hours. Simply reducing hours will not solve developer burnout.
Engineering teams can improve the quality of work by identifying and fixing their key constraints. One way to alleviate these bottlenecks is to invest in self-service tooling that helps developers write and test their code without needing to disrupt other team members.
Environment provisioning and automated test suites, which help developers build and test their changes faster, are areas where DevOps teams can start integrating self-service tools almost immediately. A lack of automated testing results in code quality issues, increasing the likelihood of outages and unplanned work. Test automation can reduce the need for time-consuming manual testing. It also makes bugs easier to find earlier in the development cycle, helping teams minimize rework.
As DevOps teams become more advanced, they can make the entire deployment process self-service. Instead of waiting for specialized deployment teams, developers follow their code through the release process. For example, they can promote the use of feature flags for smoother rollouts, automate and maximize the success rate of deployments, and provide end-to-end visibility and logging for faster debugging.
With better self-service tooling, developers get their work done with less bureaucracy and fewer handoffs between teams.
[ Read next: 5 tips to prevent IT team burnout ]
Moving toward a more flexible and meaningful workplace
Improving the developer experience will likely have a greater impact on team morale and satisfaction than simply reducing the number of days they work. When developers spend less time wrangling workflows and processes, they can spend more time on their most meaningful work.
Teams must be deliberate about setting aside time for continuous improvement. Every development cycle should reserve time to improve code quality, reduce technical debt, and invest in better automation – with the goal of reducing frustration and empowering developers.
If the goal of the four-day workweek is improving workplace engagement, happiness, and work-life balance, then prioritizing the developer experience and putting the right systems in place must come first.
[ Learn how CIOs are speeding toward goals while preventing employee burnout in this report from Harvard Business Review Analytic Services: Maintaining Momentum on Digital Transformation. ]
