Does a Four-Day Week Work for a Growing Company?

Turn this article into takeaways for your work.

Each assistant summarizes the article only for you and suggests best practices for your work.

Every few months a founder or board member asks the same thing: should we move to a four-day week? The pitch is attractive. Keep pay the same, cut the hours, and watch people stay longer and work with more focus. The trial headlines say that's roughly what happened.

Our view is more conditional. A four-day week works where output is measurable and coverage can be designed, and it gets harder wherever work is reactive or one person's absence stalls a queue. For a growing company, that means the right unit of decision is the team, not the whole company. Pilot by team, set measures before you start, and let the results decide where it spreads.

This piece covers what the largest trials actually show, who was in them, a way to sort your teams, and what to do in the next 90 days.

Key Facts

What the trials actually show

Start with the evidence, because it's better than the skeptics admit and weaker than the advocates imply.

The UK pilot is the one most executives have heard of. Between June and December 2022, 61 organizations moved to a shorter week with no pay cut. The report, published by Autonomy with researchers from Boston College and the University of Cambridge, found that companies mostly held their ground on the business side and that employees reported real improvements. On the employee side, 39% reported being less stressed and 71% reported reduced burnout by the end of the trial, comparing survey answers at the start and the end.

On the company side, resignations per 100 employees fell from 2 to 0.8 between the comparison period and the trial, and sick and personal days per employee per month fell from 2.0 to 0.7. Those are large moves. But the report itself says it can't call them statistically significant, in part because of small numbers and in part because of labour market conditions. The 1.4% revenue figure covers only 23 firms. It tells you revenue didn't collapse. It doesn't tell you a four-day week raises revenue.

The 2025 study in Nature Human Behaviour is the stronger piece of evidence. Its authors analyzed pre- and post-trial survey data from 2,896 employees in 141 organizations in Australia, Canada, Ireland, New Zealand, the UK, and the USA, and found improvements in burnout, job satisfaction, mental health, and physical health that the 12 control companies didn't show. One detail matters for operators: the organizations first reorganized work to improve efficiency and collaboration, and only then ran the six-month trial. The shorter week wasn't dropped on top of an unchanged workflow.

Both studies measure well-being much better than they measure output. In the UK pilot, the common metrics the companies reported were revenue, absenteeism, resignations, and new hires. The researchers explained that productivity and performance metrics were left out because the participating organizations track such different things. That's a reasonable design choice. It also means "productivity was maintained" rests mostly on managers' ratings, which averaged 7.5 out of 10 for both company performance and productivity.

Who was in the trials (and who wasn't)

This is the part that should change how you read the headlines.

These were volunteers. The UK trial was run by the 4 Day Week Campaign, 4 Day Week Global, and Autonomy, who recruited the companies, and participants were asked to make a small donation toward the cost of running it. Seventy companies signed up and nine never started, citing reasons such as not being prepared, difficulty measuring performance in some departments, and two who decided shorter hours weren't right for them. The 61 who ran the trial had already self-selected twice: once by joining, and once by getting far enough through preparation to begin.

They were also small and concentrated in office-style work. Two thirds had 25 or fewer staff, and the largest groups were marketing and advertising, professional services, and non-profits. The 2025 study's organizations were likewise enlisted by an advocacy group that campaigns for the shorter week.

None of this makes the results wrong. It makes them results from participating firms: organizations motivated to make it work, with leaders who wanted it to succeed, supported by coaching and peer groups. That's close to the best case. A growing company with a 40-person sales team, a support queue, and three open roles isn't the same experiment.

Where it fits, and where it strains

The useful question isn't "does it work?" but "which of our teams look like the teams that did well?" Two properties decide most of it.

Is the output measurable? If you can say what a team ships or closes in a week, you can hold that constant while hours fall. If the work is mostly responding to whatever arrives, hours and output are tightly linked and you'll just be paying for the same coverage with the same people on fewer days.

Can coverage be designed? The UK pilot found companies using different models. Some shut down entirely on a fifth day, which suited teams where collaboration mattered more than five-day coverage. Others staggered days off, such as a marketing agency that paired colleagues with similar skills so one of them was always in. Those are design choices, and they only work if someone makes them deliberately.

Here's how that sorts a typical growing company:

Team type Output measurable? Coverage need Fit for a four-day pilot Likely design
Product and engineering Yes (shipped work, cycle time) Low, with on-call as an exception Strong Company-wide day off or staggered, with a rota for incidents
Marketing and content Yes (published assets, campaign milestones) Low Strong Shared fifth day off
Finance and operations Partly (close timelines, error rates) Medium, with fixed deadlines Moderate Staggered, with month-end exceptions
Sales (outbound, quota-carrying) Yes (pipeline, closed deals) Medium, buyers don't keep your calendar Test carefully Staggered, with response rules for inbound
Customer support and success Partly (resolution time, backlog) High, queue-driven Hard Staggered rota, only if volume can be forecast
Field, shift or on-site roles Varies High, tied to place and hours Weak Usually a different model, such as compressed shifts

Read the table as a starting hypothesis, not a verdict. A support team with predictable volume and a documented triage process can do better than a poorly organized engineering team. What matters is whether the work has been made legible enough that you can see what happens to it when hours drop.

Why company-wide mandates go wrong

A company-wide switch bundles together teams with very different conditions and gives you one blended result you can't interpret. If support struggles and engineering thrives, the average hides both facts. Worse, a mandate makes reversal expensive. Once you've announced it to everyone, pulling it back from one team reads as a failure of the whole policy.

There's also a coordination issue. A growing company already pays a rising price for work about work and coordination. Shorter weeks compress the overlap in which people can meet, hand off, and decide. If your decisions still depend on assembling people in real time, a fifth day off removes a fifth of the slots you use to do it. Teams that already run on writing, clear ownership, and fast, delegated decisions lose very little. Teams that don't will feel it quickly.

That's why the groundwork matters more than the policy. The same changes that make a four-day week survivable, fewer standing meetings, written context, defined decision rights, are what make an async-first operating model work, and they pay off even if you never shorten the week. A meeting-heavy calendar is the first thing to fix, because meetings are the hours that get squeezed hardest.

And watch the downside the trials were designed to ease. A compressed week can slide into the same overload in four days if scope doesn't shrink. If that happens, you've reproduced the pattern described in burnout culture with less time to recover from it.

A pilot design that gives you a real answer

Treat it like any other change you'd manage deliberately: one hypothesis, a defined scope, and a decision date.

  1. Pick one or two teams that score well on the table above. Volunteer teams with a manager who wants it are fine for a first run, as long as you remember that's the same selection effect the trials have.
  2. Write down the output measures before you start. Two or three per team: shipped work, pipeline created, tickets resolved within target, error rate. Capture six months of baseline if you can.
  3. Add a quality guardrail. Customer response time, escalations, or defect rates. Output that rises while quality drops isn't a win.
  4. Design coverage in writing. Who is reachable on which day, who handles urgent issues, and what counts as urgent. Keep the rules short.
  5. Run it for at least a quarter, ideally two. The novelty effect is real, and the trials themselves ran for six months.
  6. Set the review in advance. Decide now what result means expand, adjust, or stop. Include retention and engagement alongside output, since well-being is where the evidence is strongest.

What to do next

  • This week: List your teams and mark each one against the two tests: measurable output and designable coverage. Be honest about which ones fail.
  • Within 30 days: Choose one pilot team and agree on its three output measures and one quality guardrail. Cut recurring meetings on that team first, using the approach in deep work as a business strategy as a guide.
  • Within 60 days: Launch the pilot with a written coverage plan and a named owner. Don't announce it company-wide as a policy.
  • At 90 days: Review early signals, but don't decide yet. Check whether the output measures held and whether the team's coordination habits actually changed.
  • At the end of the pilot: Decide per team. Expand where output held, adjust coverage where it strained, and stop where the work can't be made legible. Then pick the next team.

The honest summary is that the evidence supports trying a four-day week, not adopting one. The firms in these trials were willing participants who prepared carefully, and that preparation is as much a part of the result as the shorter week. If you borrow the design, borrow the preparation too.

Frequently Asked Questions about the Four-Day Week

Does a four-day week cut productivity?

The trials suggest output can hold when hours fall, but they measure it loosely. The UK pilot didn't include productivity metrics in its common company data, so its productivity findings lean on managers' ratings and on revenue from 23 firms. Set your own output measures before you pilot.

Is a four-day week the same as compressed hours?

No. In the trials discussed here, the week was shorter with pay unchanged, so total hours fell. Compressing 40 hours into four longer days keeps hours the same and has different effects on fatigue and coverage.

Will a four-day week help us retain people?

The evidence points that way but isn't conclusive on retention specifically. The UK pilot saw resignations per 100 employees fall from 2 to 0.8, but its authors said the trend wasn't statistically significant. The stronger evidence is on burnout and job satisfaction, which are common drivers of leaving.

Which teams should go first?

Start where output is measurable and coverage is flexible, typically product, engineering, and marketing. Leave queue-driven teams such as support, and place-bound roles, for later or for a different scheduling model.

How long should a pilot run?

At least a quarter, and six months is better. The major trials ran for six months, and shorter tests can mostly capture novelty. Fix the review date and decision rules before launch.

Should a growing company mandate it company-wide?

Usually not at first. A mandate blends teams with very different conditions into one result you can't read, and it's hard to reverse. Pilot by team, then expand where the measures hold.

About the author

Victor Hoang

Victor Hoang

Co-Founder, Rework.com

Victor Hoang is Co-Founder and CMO of Rework. He spent 12+ years scaling B2B SaaS growth, building a lead engine that generated over 1 million leads and $10M+ in annual recurring revenue. Today he builds AI agents and MCP servers into Rework's products to empower customers across growth and operations. He writes about what actually works.