Tech Companies with a 4-Day Work Week

The four-day week stopped being a stunt around 2022. That year's UK pilot ran 61 companies and just under 2,900 workers, and 56 of those companies kept the schedule when the trial ended. Revenue held up. Resignations dropped. The productivity collapse sceptics expected didn't show up in the data. Three years on, a small but real cohort of tech companies runs the 32-hour week as a permanent contract, not a perk.

This page collects 20 of them. Most are software, fintech, gaming, or digital health, which makes them directly relevant to anyone running a tech team. The directory below is filterable by industry, region, size, and remote policy. After it: a short brief on the model, what the studies actually say, and the objections you'll hear first when you propose this to a CEO or board.

The 100-80-100 model

Most of the companies above run the model that 4 Day Week Global formalised: 100% of pay, 80% of hours, in exchange for a commitment to maintain 100% of output. In practice that means 32 hours a week, full salary, and an explicit productivity contract pegged to whatever the company already runs on. Revenue per employee. Customer outcomes. Engineering throughput. Pick one and own it.

This is not a compressed week. A 4×10 schedule keeps total hours at 40 and pushes the exhaustion into the working days instead of removing it. The 100-80-100 model is a real cut. The bet is that the cut forces enough of a productivity gain to pay for itself.

A handful of companies in the directory offer a softer variant: 32 hours at 80% pay (Form3, Smartest Energy, Friendly Captcha). That sits closer to a part-time contract than a productivity contract, and the burden lands on the employee. The cohort whose data the studies actually measured is the 100-80-100 group, so that's the one to point at when you make the case internally.

Where the evidence comes from

Three studies dominate the citation pile. They are not all equally rigorous, and a CTO making this case internally should know which is which.

UK 2022 pilot: the largest controlled study

Run by 4 Day Week Global with academics from Cambridge and Boston College (Oxford was also on the team). 61 companies, around 2,900 employees, six months, sectors from finance to construction. 56 of the 61 stayed on the schedule when it ended; 18 made it permanent immediately. Self-reported revenue rose 1.4% on a size-weighted, like-for-like comparison with the same period a year earlier. Resignations fell about 57%. Stress and burnout scores dropped sharply. Sample size and pre-registration of hypotheses are what make this the strongest piece of evidence on the table.

Iceland 2015-2019: the public-sector precedent

Reykjavík city council and the Icelandic government ran two trials covering about 2,500 workers, roughly 1% of the country's workforce. Hours dropped from 40 to 35-36 a week with no cut in pay or service levels. Researchers called the result an "overwhelming success," and Icelandic unions subsequently won the right to negotiate shorter hours for around 86% of the workforce. One thing to flag for skeptical CTOs: the Iceland schedule was 35-36 hours, not 32, so it isn't a clean read-across to the UK pilot.

Microsoft Japan 2019: the famous, small one

A month-long internal experiment at Microsoft Japan in August 2019 reported a 40% productivity boost. The number gets quoted everywhere and is almost certainly cherry-picked. Single site. Five weeks. No control group. Useful as a vibes-check, not as evidence. If the UK pilot is the one your board will accept, this is the one your skeptics will dismiss, so pick accordingly.

Beyond these, smaller reduced-hours pilots in Spain (2023) and Portugal (2023) produced compatible results, and 4 Day Week Global continues to run rolling cohorts with results published per cohort. Skip Belgium 2022 if you see it cited: that law allows a compressed 4-day week at 38-40 hours, which is a different scheme and not evidence for the 100-80-100 model.

The objections you will hear first

Most of these are reasonable on the surface and bend under specific evidence. Walk in with the model, the UK pilot numbers, and a six-month commitment to measure, and you skip most of the resistance.

"Engineering output will drop."

The pilot data doesn't support this. What protects throughput is cutting low-value meetings and pushing async-default communication so that the deep work that was already happening keeps happening. If your team genuinely can't lose 20% of its calendar, the schedule will fail. That's a meeting-culture problem, not a 4-day-week problem.

"Customers expect us five days a week."

The companies in the directory mostly stagger days off, so the team itself is reachable Monday to Friday even though no individual is. Where the team is too small to stagger, they publish four-day support hours and the customers adjust. Beacon, Close, and Luscii are all running this with paying customers in 2026.

"On-call coverage breaks."

A 4-day schedule doesn't change on-call rotations. It forces you to make sure they were structured properly to begin with. If your rota currently relies on one senior person being reachable every weekday, that's already a fragility, and the schedule exposes it. The fix is the same one you should already be making: written runbooks, clear ownership, an incident process that doesn't fall apart over Slack.

"Junior engineers will lose mentorship time."

This is the strongest objection on the list. Apprenticeship and tacit knowledge transfer benefit from synchronous time. The honest answer is that you build it back in deliberately. Block a day a week for pair programming and code review. Set up named mentorship pairs. Treat juniors' growth as a thing on your roadmap, not something that happens by accident because everyone is in the same room.

"If we do this we can never go back."

True. That should make you cautious about the rollout, not the destination. Almost every company that has tried to revert has lost staff at the announcement. So frame the pilot honestly: six months of measurement, continue only if the metrics hold, and tell the team that's the deal before the trial starts. The minority of pilot teams that don't continue tell people upfront.

FAQ

Is the 4-day work week the same as a compressed schedule?

No. A compressed schedule keeps the same total hours (e.g., 4×10), so workers still put in 40. The 100-80-100 model that most companies on this page run cuts to 32 hours a week with no pay cut. That is a real reduction in working time, not a reshuffle.

Where is the evidence that productivity holds up?

The largest study to date is the 2022 UK pilot run by 4 Day Week Global with researchers from Cambridge and Boston College. 61 companies and roughly 2,900 employees took part for six months. After the pilot, 56 of 61 companies continued, citing maintained or improved revenue and a sharp drop in burnout and resignations. Iceland's 2015-2019 trials drew similar conclusions across 2,500 public-sector workers, leading to most Icelandic unions winning the right to shorter hours.

Does it work for engineering teams that need pager coverage?

Yes, but it forces a question your on-call rotation should already have answered. Companies on a 4-day schedule stagger which day people take off so the team is covered Monday to Friday. They invest in written runbooks and async-friendly incident process. A 5-day team can paper over gaps with overtime; this schedule exposes them.

How do customer-facing teams handle Fridays?

Three common patterns. Split the team so half are off Friday and half off Monday and you keep five-day coverage. Or run a small Friday rota and bank the extra day in the next pay period. Or scope down support hours to match the schedule and publish them clearly. Close, Beacon, and Luscii all run variants of these.

Why are most of the listed companies in the UK and Europe?

European labour law and a stronger pilot ecosystem (4 Day Week Global runs cohorts mostly out of the UK and Ireland) mean adoption has clustered there. US adopters tend to be bootstrapped, founder-led, or remote-first. Close and Smalls fit this pattern.

Will my engineers fall behind their peers on output?

The 2022 UK pilot data does not support that. Self-reported productivity stayed flat or rose. The mechanism is fewer interruptions and harder choices about what does not get done. The trade-off is real: low-priority work gets cut. If your roadmap is already lean, that is a feature, not a bug.

How do I propose this to my CEO or board?

Frame it as a six-month pilot with measurable hypotheses (retention, revenue, lead-time, eNPS) rather than a permanent change. Cite the UK pilot results. Pick a low-risk team or a quiet quarter. Pre-commit to either continuing or rolling back based on the metrics, not feel.

Related resources