Research Synthesis Brief

Should we move the team to a 4-day week? Synthesis of Sources A, B and C

Research question: Should our team move to a 4-day work week?
Sources: A, the pilot report (2025, 61 companies). B, a SaaS CEO's blog post (2024, one company). C, the HR leader survey (2025, 1,000 respondents). The sources are about a year apart, so none is stale.

Themes

1. Output holds up for internal "build" work, but it's measured loosely.
Revenue was "broadly unchanged" across the pilot [A], and engineering output was "about the same" [B]. Two independent sources point the same way. Both measures are weak, though. A's figure covers only the 23 of 61 companies (38%) that shared financials. B's figure comes from the company's own sprint metrics. C says this is the general problem: 41% of HR leaders cite measuring productivity as a top concern.

2. Customer coverage is the main operational risk, and staggered days off fixed it in the one case we have.
Support response times got worse for two months, then recovered once days off were staggered [B, single-source on the fix]. C independently ranks customer coverage as the #1 concern (63%). A doesn't break results down by role, so it can't confirm or rule out this risk.

3. Results depend on the role, and the obvious fix creates a fairness problem.
B reverted to 5 days for sales after two quarters because pipeline dropped [B, single-source]. That leaves a two-tier workforce, which is exactly C's #2 concern: 48% worry about fairness across roles. The sources fit together here. B's answer to the sales problem is the fairness problem C describes.

4. The wellbeing gain rests on one source.
Burnout fell for 71% of employees [A, single-source, self-reported]. B doesn't report wellbeing, and C reports no outcomes at all. This may be the strongest argument for the change, and it has the least corroboration.

5. Few companies have adopted it, and the success data comes from volunteers.
Only 4% of companies have implemented a 4-day week and 22% are considering one [C]. A's companies chose to join the trial [A]. A's success rates therefore describe companies already inclined to make it work, not companies in general.

Consensus

• Output for non-customer-facing work doesn't collapse over 6–12 months [A, B]. The two sources are independent, but both use soft measures.
• Customer coverage and role differences are the real implementation problems [B saw them happen, C reports them as concerns]. These are independent, but C's evidence is opinion, not outcomes.

Contradictions

Gaps

Our own team's role mix. This is the biggest gap. None of the sources can tell us what share of our team is customer-facing or sells, and that is the variable most likely to decide the outcome.
2.

What the model is. B cut hours to 32 (4×8). A doesn't say whether its companies cut hours or compressed them (4×10). These are different policies.
3.

Outcomes for companies that didn't volunteer. There are none: A is self-selected, B is one company, and C reports no outcomes.
4. Results past one year. Only B reaches one year, and that's a single company.
5. Objective productivity, attrition, hiring and cost data. No source has it.
6. Revenue for the 38 pilot companies that didn't share financials [A].

Bottom line

The sources don't show that a 4-day week is the right move for teams in general. They support a narrower conclusion. For internal build work, output seems to hold for 6–12 months, though the measurement is weak and the companies were mostly volunteers. Customer coverage and sales are the specific places it breaks. Coverage looks fixable by staggering days off, but that rests on a single company. Sales may not be fixable, and making an exception for sales creates the fairness problem HR leaders already worry about. The answer depends on how much of our team is customer-facing or selling. If the evidence supports any step, it's a time-boxed pilot: staggered coverage from day one, an explicit decision about sales roles, and productivity and pipeline metrics fixed before it starts. An outright switch isn't supported.

---

Appendix: source inventory

If you tell me roughly how the team splits across support, sales and build work, I can turn this into a go/no-go recommendation with a pilot design.