The four-day work week studies are not really about scheduling. They are about making the invisible visible.
In 2025, Nature Human Behaviour published the largest controlled trial of compressed work schedules to date: 2,896 employees across 141 companies in six countries, tracked over six months with no pay reduction. Revenue stayed flat. Burnout dropped 71%. Staff turnover fell 57%. And the finding that keeps getting cited: workers could get as much done in roughly 33 hours as they had in 38.
Those missing five hours did not evaporate. They were meetings nobody needed to attend, message threads nobody needed to handle in real time, low-stakes tasks that expanded to fill the time available. Before the schedule change, each company was given eight weeks to identify and remove the inefficiencies their five-day calendar had been quietly subsidizing. The trial did not gift workers a free day. It forced an honest accounting of how the existing days were actually spent.
What the Developer Numbers Reveal
For software developers, the compression was sharper than the aggregate data suggests. Three IT companies that ran their own 4-day experiments reported 40% productivity boosts — not 20%, and not marginal. A 40% gain on a 32-hour week implies the starting point was not 40 hours of high-value work. It was closer to 20 to 25 hours of deep coding time, surrounded by meetings, reactive communication, and context switching that consumed the rest.
Microsoft Japan found a similar 40% figure. Buffer reported 22%. The companies that saw the biggest gains were not those with the loosest workers — they were typically the ones where high-interrupt, meeting-heavy cultures had already been eroding focus time for years.
The 4-day constraint forced a reckoning with what the padding actually consisted of. Status meetings that could have been a written update. Standups that nobody left with different information than they arrived with. The two-hour afternoon window that felt like coding but contained 15 separate app switches and produced three dozen lines of code.
None of this was surprising to anyone in retrospect. The surprise was how much of it existed unexamined, week after week, because the five-day schedule always provided enough slack to absorb it.
The Five Hours Are Not in a Block
The reason most developers do not notice their low-value 20% is that it does not arrive as a block. It does not show up on a calendar as "3–5 PM: waste time." It is distributed across the day in fragments that individually feel reasonable.
A Slack message before the morning standup. A quick email check before the first coding session actually starts. Three minutes of news when a test is running. The thread that opens at 2 PM and closes at 2:22 PM. The re-opening of Slack immediately after a meeting ends, because meetings generate follow-ups.
Each of those is easy to justify in isolation. The aggregate cost only becomes visible when you see the data. When app-level tracking surfaces the full picture — which applications you used, in what order, for how long — the coding-to-everything-else ratio is rarely what developers estimate going in.
The typical expectation is around 70-30 in favor of development work. What the data more commonly shows is closer to 50-50, and on high-meeting days it inverts. That gap between expectation and reality is the same five hours the 4-day trials removed. It was there all along; the trial's structure was just the first time anyone looked at it honestly.
What the Switches Tell You
One signal stands out in the data as a reliable indicator of where the hidden waste is concentrated: context switches per hour.
The average developer switches apps roughly 300 times per day. When developers are asked to estimate this cold, most guess somewhere between 30 and 50. The gap between the guess and the measured number is not carelessness — it is that individual switches are fast enough to be invisible. A two-second move from VS Code to Slack and back does not feel like a context switch. The 20 minutes it takes to rebuild the mental model you had before the switch is just what the rest of the session feels like.
The spikes in switching cluster in predictable places: the hour after a standup, the window between 3 and 5 PM when messages from earlier in the day generate replies, and the minutes immediately before and after any meeting. The low points are usually early mornings before the first synchronous touchpoint, and late evenings when communication volume drops.
Developers who have seen their own switching patterns typically identify two or three blocks per week where the data dips below 10 switches per hour. Those blocks almost always coincide with lower meeting load, not with unusual willpower or discipline. The problem is rarely attention. It is the structure of the day.
The Audit Without the Contract Change
The four-day week companies had a forcing function: they had to find and cut something. For most developers that forcing function does not exist. Nobody is requiring you to audit your week.
But the question the trial was asking — where does your low-value 20% actually live? — is answerable without a schedule change. It requires the same visibility that those companies built in their eight weeks of pre-transition preparation.
That means looking at the actual split between coding time and everything else. Not what your calendar shows. Not what your task manager logged. What your computer's app-level activity log recorded while you were working.
For most developers, the first clear look at that data produces two reactions. The first is disbelief that the coding fraction is as low as it is. The second is immediate recognition: the meetings, the communication overhead, and the reactive context switching that filled the rest of the day were all fully visible in retrospect. None of it was hidden. It just had not been measured.
The Pattern Parkinson's Law Predicts
The broader principle underneath the 4-day week results is something Parkinson described in 1955: work expands to fill the time available. The five-day week does not cause low-value work to exist. It provides enough slack that low-value work never has to justify itself. It fills in, meeting by meeting and notification by notification, and because the day always ends eventually and enough code always shipped, nobody checks whether the 38 hours were the efficient version or the padded one.
The four-day constraint removed the slack. The low-value work could not expand to fill time that was not there, so teams cut it. Revenue stayed flat. Output stayed flat. The waste just stopped being hidden.
Your week has the same structure. The five hours are distributed differently — they follow your meeting culture, your Slack norms, your notification habits — but they are there. Tracking makes them visible. That is the entire point.
The 4-day week companies did not find discipline they did not have before. They found data they had never looked at. You can do the same thing without changing your contract. The audit is the first step, and it starts with turning on automatic tracking and waiting a week before looking at anything.
The data will show you something the calendar never would.