A leadership meeting at a 300-person software company, early autumn. The HR director brings exit interview data: regretted attrition in engineering is the highest it has been in three years, and the word that keeps coming up is exhaustion. She also brings a proposal: from January, a four-day work week, Fridays off, same salary. The CEO has read the headlines about the UK pilot. The COO has one question: who answers the phone on Friday when a client’s checkout goes down?
Both sides are right, and both are asking the wrong question. In a technology company, a four-day week is not a perk you announce. It is a change to how work is organised, and it has to be designed. This article is for CEOs and HR directors who are considering shorter hours for technology teams, or who are hearing their people ask for it. We look at what the pilot data really says, what it does not say, which version of a shorter week fits a software team, and what changes when part of that team is contractors or vendor staff.
Our position may be uncomfortable for both camps. The pilots show that a shorter week improves wellbeing and reduces resignations; they do not show that it raises productivity. In IT, success depends less on whether you shorten the week than on how. A shared Friday off looks best in a job advert and is the worst option for most teams that run production systems. And taking a day out of the calendar before taking the waste out of the week ends in one of two places: a quiet return to five days, or a team that catches up on Sunday evenings.
What exactly is a four-day work week, and how is it different from a compressed week?
At least three different arrangements travel under the “four-day week” label, and the business case changes completely depending on which one you mean.
Reduced hours at the same pay. People work fewer hours, say 32 instead of 40, and keep their full salary. The 4 Day Week Global movement describes this as 100-80-100: 100% of pay for 80% of the time, in exchange for keeping 100% of output. This is the model that the high-profile UK and German pilots tested. It does not have to mean Fridays off: the reduction can be delivered as shorter days, extra days off each month or a rotating day off.
A compressed week. The same hours in fewer days, typically four 10-hour days. In the United States this is a common scheduling option for non-exempt staff; in Belgium employees have had the right to request a compressed four-day week since 2022, with the employer allowed to refuse on reasoned grounds. Total hours do not change, only their distribution.
A shorter week at lower pay. In other words, part-time work at 0.8 of a full-time contract. Plenty of senior engineers would take that deal, but it is not what the pilots studied and it does not change the company’s economics.
The distinction matters for the numbers. A compressed week is cost-neutral, but in work that needs long stretches of concentration the ninth and tenth hours of a day are often the least valuable. A reduced week at the same pay raises the cost of each working hour by 25% (because 1 / 0.8 = 1.25). It pays off only if the company recovers that difference through output, lower attrition or cheaper hiring. In the rest of this article, “four-day week” means the reduced-hours model, because that is the one that generates both the excitement and the data.
What did the pilots in the UK, Iceland and Germany actually show?
The most-quoted study is the UK pilot that ran in the second half of 2022, organised by 4 Day Week Global with the think tank Autonomy and university researchers. It involved 61 companies and about 2,900 employees. After six months, 56 companies (92%) chose to continue and 18 described the change as permanent. The report found that staff departures fell by 57% and sick days by 65% compared with the same period a year earlier. Revenue rose by an average of 1.4% over the trial, but that figure is size-weighted and comes from the 23 companies that supplied adequate financial data.
Iceland is older and different in kind. Between 2015 and 2019, Reykjavík City Council and the national government ran trials covering more than 2,500 workers, around 1% of the working population, who moved from 40 to 35 or 36 hours a week with no pay cut. The 2021 report by Autonomy and the Icelandic association Alda found that productivity and service provision stayed the same or improved in most workplaces. The often-repeated 86% figure describes something else: the share of Iceland’s workforce that, through collective agreements negotiated between 2019 and 2021, has moved to shorter hours or won the right to request them. That is the result of union bargaining, not a direct outcome of the trials. It is also worth noting that in Iceland the usual change was a shorter day, not a missing day.
Germany’s 2024 pilot, run with the University of Münster, started with 45 organisations. In its October 2024 release the university reported that more than 70% of participants wanted to continue, either by extending the trial or by adopting a four-day week permanently, and 85% had given staff one fixed or flexible day off per week. Smartwatch data showed participants sleeping on average 38 minutes more per week than a control group and recording significantly fewer minutes of measured stress per day. Turnover and profit rose slightly, but not significantly compared with the previous year, and the small fall in sick days was also not statistically significant. Two large companies dropped out early, citing economic pressure or a lack of internal support.
The strongest scientific paper so far is the July 2025 article in Nature Human Behaviour by Wen Fan and colleagues, including Juliet Schor of Boston College. The authors analysed six-month trials in 141 organisations across several countries, covering nearly 2,900 employees, and compared them with about 290 employees at 12 companies that stayed on five days. Trial participants showed significant improvements in burnout, job satisfaction, and mental and physical health. On average they worked about five hours a week less, and the people whose hours fell by eight or more reported the largest gains.
What do the pilots not prove, and why does that matter for a board decision?
All of the figures above are real, and all of them share one weakness: the participants volunteered. A company that signs up for a 4 Day Week Global programme usually already has a high-trust culture, a leadership team that believes in the idea, and work that can be reorganised. The Nature Human Behaviour authors state plainly that the organisations they studied were not a representative sample. “92% of companies continued” is a statement about companies that expected to succeed before they started.
The second weakness is measurement. Wellbeing, burnout and satisfaction were measured by surveys completed by people who knew the results would influence whether they kept the benefit. Attrition and absence are harder data, but they were measured over short periods and, in the UK case, against the previous year rather than a control group. Productivity in the strict sense, output per hour worked, was not measured in most trials, and the revenue data covers only part of the sample.
The third is reversals. Reporting on the German pilot noted that around one in five participating companies went back to a five-day, 40-hour week after the trial, and several others chose to cut hours within a five-day week instead of removing a day. That is not a failure of the idea. It is information: the “everyone off on Friday” format does not suit every organisation, even one that wanted it to work.
The practical rule for a board is simple. When someone says a four-day week “increases productivity by X%”, ask for the source and check what was measured, and on whom. The honest summary is this: in well-prepared organisations, cutting hours by about 20% did not reduce results enough to make them stop, and it clearly improved wellbeing and reduced resignations. That is still a strong argument, but it is a retention argument, not a productivity argument, and it should be costed as one.
Technology media also like to cite Microsoft Japan, which closed its offices on Fridays in August 2019 as part of its Work-Life Choice Challenge and reported sales per employee almost 40% higher than in the same month a year earlier. That was one month, one metric and one company. Treat it as an anecdote, not evidence.
Where do governments stand on shorter working time in late 2026?
For a company employing people in several countries, the regulatory picture matters, and it is more cautious than the headlines suggest. No major European economy has made a four-day week the statutory standard.
In the EU, the binding framework remains the Working Time Directive (2003/88/EC), which caps average weekly working time, including overtime, at 48 hours. It sets a ceiling, not a norm, so any employer is free to offer fewer hours. Belgium’s 2022 labour reforms gave employees the right to request a compressed four-day week, not a reduction in hours. Spain’s government tried to cut the statutory week from 40 to 37.5 hours, but the Congress of Deputies rejected the bill on 10 September 2025 by 178 votes to 170. In Japan, the Tokyo Metropolitan Government has offered its own employees a four-day week option since April 2025, framed as a family and birth-rate policy.
In the United States, the federal Fair Labor Standards Act still uses 40 hours as the overtime threshold for non-exempt employees, and bills to lower it to 32 hours have been introduced in Congress without becoming law. Many software engineers are classified as exempt, so the practical constraint for a US technology employer is contractual and cultural rather than legal. In the UK, there is no right to a shorter week, but employees have been able to make a flexible working request from their first day of employment since April 2024.
Poland is the most interesting case for anyone who works with Central European engineering teams. Its labour ministry is running a funded government pilot. Applications closed in September 2025; on 15 October 2025 the ministry announced that it had received 1,994 applications and selected 90 employers, with projects covering more than 5,000 employees. Each project had to cover at least half of the employer’s workforce, with grants of up to PLN 1 million per employer. Hours were cut by at least 10% from January to June 2026 and by 20% in the second half of the year, with no reduction in pay. According to the ministry’s 2 November 2026 update, 78 employers (38 private and 40 public) are taking part, covering nearly 5,000 people; most are reducing weekly hours gradually, some have moved to a four-day week, and some give extra days off. The ministry says shorter hours can be reconciled with running an organisation efficiently but require changes to how work is organised, and on 6 November the minister said 80% of participating employers want to continue in some form. The pilot ends in December 2026, final reports are due by 15 May 2027, and for now the ministry is relying on soft recommendations rather than changing the Labour Code. Independent evaluation does not exist yet.
Why does IT look like the ideal candidate, and where does that intuition fail?
At first glance, a software team is the perfect subject for the experiment. The work is cognitive, output depends on concentration rather than hours at a desk, most tasks can be done remotely, and asynchronous tools are standard. Engineering talent markets have been tight for years, so any retention argument has real value.
The data on how knowledge workers spend their week supports that intuition. In Microsoft’s Work Trend Index 2023, based on a survey of 31,000 people in 31 markets, 68% of respondents said they do not have enough uninterrupted focus time during the workday, and inefficient meetings were ranked as the top productivity disruptor. The same report found that the average Microsoft 365 user spends 57% of their time communicating and 43% creating. If a large part of an engineer’s week produces no value, in theory it can be cut without losing output.
The intuition fails in three places. The first is continuity. A team that runs a production system is responsible for incidents regardless of the day of the week, and client contracts often define response times in business days. A shared Friday off does not remove that responsibility; it moves it onto an on-call rota that someone has to staff and someone has to pay for.
The second is dependencies. Software teams rarely work in isolation. They wait for business decisions, security approvals, answers from another vendor’s system and client acceptance testing. If those parties work five days and the team works four, every dependency gets a day longer each week. In work with many hand-offs, that can wipe out the gain from better concentration.
The third is the cost structure. A services firm that bills clients by the hour loses a fifth of its billable capacity at unchanged payroll. A product company does not have that problem directly, but its output is harder to measure, so it is easier to miss that delivery has slowed. Both situations call for a different conversation than “let’s give people Fridays off”.
Shared Friday off or rotating day off: which model fits a software team?
This is where most four-day week discussions go wrong. The debate is about whether; in IT, the outcome depends on how. The table compares five models from the perspective of a technology team.
| Model | How it works | Strengths in IT | Weaknesses in IT | When it makes sense |
|---|---|---|---|---|
| Shared day off (e.g. Friday) | The whole team works Monday to Thursday, 32 hours | Simple to explain, strongest employer-brand effect, a full recovery day | Gap in incident and client coverage, slower dependencies, pressure to cram on Thursday | Product teams with no on-call duties and few external dependencies |
| Rotating day off | Everyone gets one day off, on different weekdays | Team is reachable five days a week, support continuity, fewer client issues | Harder planning, less shared time, the day off “disappears” under pressure | Support and maintenance teams, client-facing delivery |
| Shorter days (e.g. 6.5 hours) | Five days, fewer hours per day | No change to coverage, easy to roll out, suits concentration-heavy work | Weaker brand signal, blurred end of day, “just finishing this” creep | Teams with many dependencies and business meetings |
| Extra days off per month | E.g. two additional days off a month, booked like leave | Flexible, fits existing rotas, easy to cover | Smaller effect on day-to-day fatigue, reads as extra holiday | A cautious first step or firms with volatile workload |
| Compressed week (4 × 10 hours) | Same hours over four days | Cost-neutral, a day off without changing hours | Long days hurt design and debugging work, none of the effects seen in reduced-hours pilots | When individuals ask for it for personal reasons |
Our view: if a team runs production systems or works directly with clients, a shared Friday off is the worst starting point, even though it looks best in a job advert. A rotating day off or shorter days deliver most of what the research found (fewer hours, more recovery) without creating a gap that has to be patched with on-call duty. A shared day off makes sense for a product team that controls its own pace, has no time-bound commitments to clients and can close out its week on Thursday without leaving deployments half-finished.
Remember the dose-response finding from the Nature Human Behaviour paper: larger reductions in hours brought larger improvements. A policy where Friday is officially off but half the team answers messages anyway delivers a reduction only on paper. A real six-hour cut beats a nominal eight-hour one.
What has to leave the week before a day can leave the calendar?
The successful pilots share one ingredient: they changed how work was done before they cut the time available to do it. In the German pilot, more than 60% of employees reduced distractions and streamlined processes, just over half changed their meeting culture, and about a quarter adopted new digital tools. That is not a side effect. It is the mechanism. The missing hours have to come from somewhere.
In a software team there are four main sources of recoverable time. Meetings. Pull the team’s calendars for the last four weeks and count meeting hours per person. Every recurring meeting needs an owner, a purpose and a decision it exists to make; meetings that only pass on information can become written updates. A daily stand-up should last as long as the method intends, not an hour.
Work in progress. A team running twelve items in parallel loses time to context switching and waiting for code review. Limiting work in progress, the core idea of Kanban, shortens the lead time of each change, so that in a shorter week the team finishes more rather than starts more. It is the cheapest change you can make, and it often delivers more than the shorter week itself.
Interruptions. Agree on windows for answering messages and protected time for deep work. Urgent issues should have one channel and one person on duty, not reach everyone at once. Without this, a shorter week means the same number of interruptions packed into fewer hours, leaving even less time for real work.
Manual toil. Deployments with manual steps, test environments that take an hour to spin up, reports assembled from five tools. Each of these is time that automation returns permanently. If the team never has time to automate, the preparation phase before a pilot is a good moment to find it.
The rule is simple: slim the week first, then shorten it. Measure how much time the team actually recovered during preparation, and only then decide how far to cut. Poland’s government pilot followed a similar logic of stages: first 10%, then 20%.
How do you measure whether a shorter week works without pretending to measure developer productivity?
Individual developer productivity is notoriously hard to measure, and attempts to count lines of code or closed tickets end with people optimising the metric instead of the work. You do not need to measure individuals, though, to know whether a team is still delivering. Flow and stability metrics that many teams already collect are enough.
We suggest four groups of measures, with at least three months of baseline before the change and the same measures tracked during the pilot. Flow: lead time from starting a change to deploying it, deployment frequency, items finished per week, waiting time for code review. These are largely the DORA metrics, whose business value we cover separately. Stability: change failure rate, time to restore service, client-reported issues. Client: response times met against contractual commitments, satisfaction scores, delivery dates hit. People: voluntary resignations, sick days, a short burnout survey before and after, and the number of hours actually worked outside the new schedule.
That last measure matters most and is most often skipped. If a team officially works four days but answers messages on Friday and closes tickets on Sunday, every other indicator will look fine while the company builds a burnout problem and, depending on jurisdiction and contracts, an overtime liability. Ask people directly and anonymously how much they worked outside the new hours.
Define success and correction criteria in advance. For example: lead time does not grow by more than 10%, contractual response times are met in at least 95% of cases, voluntary resignations do not increase. Criteria written down before the pilot protect you from judging it by mood, and they give the board a decision based on data rather than corridor anecdotes.
What changes for on-call, production support and client commitments?
For teams that run production systems, this is the heart of the matter. A shorter week does not change the fact that systems run seven days a week and that client contracts specify response times. It does change the arithmetic of coverage.
With a shared Friday off, Friday effectively becomes an on-call day: someone has to be reachable, and if only the on-call engineer is available, any issue that needs someone else’s knowledge waits until Monday. With a rotating day off, the team is available every business day in a slightly smaller configuration, so incident handling works normally, provided knowledge of the system is not concentrated in one person. With shorter days, only the end of the working day moves, which has to be reflected in maintenance windows and published support hours.
Three things are worth doing before launch. First, review client contracts for how they define business days, support hours and response times. If a commitment reads “business days, 9am to 5pm” and the team takes Fridays off, the company must either provide Friday coverage or renegotiate. Second, agree how on-call duty on a day off is compensated, because without that a Friday rota quickly becomes a source of resentment. Third, check knowledge concentration: if only one person understands a critical system, every day that person is off is an operational risk, whatever the length of the week.
That third point is also a hidden benefit of a shorter week. A team that has to function without one member on every weekday spreads knowledge faster, documents decisions and builds real cover. Those are the same practices that protect the company through holidays, illness and resignations.
What does a four-day week mean for vendors, contractors and staff augmentation?
This topic is almost absent from the public debate, yet it affects a large share of engineering capacity. Many technology teams are a mix of employees, independent contractors and vendor staff working through staff augmentation or dedicated teams. Labour law, and therefore the whole reduced-hours conversation, applies only to the first group.
For an hourly contractor, a shorter week is not a benefit; it is a pay cut. An illustrative example: a contractor billing EUR 50 per hour invoices EUR 8,000 for a 160-hour month. Following the client’s 32-hour rhythm, that becomes 128 hours and EUR 6,400. To keep the same income, the contractor would need to raise the rate by 25%, to EUR 62.50. The same arithmetic applies to vendor teams billed on time and materials: the vendor’s revenue from the engagement falls by a fifth unless rates change.
That leads to three practical questions to settle before announcing a four-day week. First: do external specialists follow the new rhythm or stay on five days? Both are legitimate, but the decision has to be explicit. If they stay on five days, they can cover the day employees are off, which solves part of the continuity problem. But a team in which some people have Fridays off and others do not can start to feel unequal, and that needs to be managed openly.
Second: how is the relationship described in the contract? Service agreements where the only unit is hours worked cope badly with a change of rhythm on the client side. Clauses on availability windows (which days and hours the specialist or team is reachable), response times and scope of responsibility work better. We look at how risk is shared across billing models in our article on team subscription, time and materials and fixed price, and at availability and replacement clauses in our piece on replacement guarantees and SLAs in staff augmentation.
Third: who pays for the gap? If a services firm shortens its own employees’ week while its clients pay by the hour, revenue from the same people falls by a fifth. Clients should not discover that from an invoice. Show them in advance how the change affects availability, pace and cost, and propose a solution, such as keeping five-day coverage through rotation. In our work on staff augmentation services, the most important thing is that availability rules are agreed before the engagement starts, not after the first Friday when nobody picked up the phone.
For companies working with nearshore engineering teams, there is one more wrinkle: your shorter week and your vendor’s local norms may not match. A Polish vendor, for instance, operates under a statutory 40-hour norm, while some of its peers are piloting shorter hours with government funding. Ask how your vendor plans to handle that, rather than assuming.
Does a shorter week help with hiring and retaining technology talent?
This is where the evidence is strongest. The 57% drop in departures in the UK pilot, the lower burnout in the Nature Human Behaviour study, and the reduced stress and burnout symptoms reported in the German pilot all point the same way. For a technology company where losing a senior engineer means months of hiring and onboarding a replacement, that is a financial argument, not just an employer-brand one. We work through what losing a specialist really costs in our article on employer branding in IT.
It still has to be weighed against alternatives. Cutting hours by 20% at the same pay raises the cost of each hour by 25%. The same money spent on raises, better tooling or an extra hire who takes load off the team would also improve retention. So the question is not “will a four-day week keep people?” but “will it keep them better than other ways of spending the same money?” In many teams the answer will be yes, because time is something well-paid engineers often value more than another raise. But check that by asking your own people rather than assuming it.
There is also an effect that rarely gets discussed: a shorter week only works as a hiring differentiator while it is rare. If more employers adopt reduced hours, it stops being a reason to choose a particular company and becomes a condition for being considered at all. Companies that build an organisation capable of working in a shorter week now will be ready; those that only put it in the job advert will have to retreat in public. We explain why perks alone do not build retention in our piece on IT talent retention, and look at the root causes of burnout in our article on IT team wellbeing.
For external specialists the logic is different. Their commitment to an engagement depends mainly on the quality of the work, predictability and their relationship with the client’s team, not on the client’s working hours. Our glossary entry on the retention of IT contractors describes what drives it. At ARDURA we maintain 99% specialist retention, and if someone does leave, a two-week replacement guarantee and replacement within five business days protect the client.
How do you run your own shorter-week pilot in a software team?
If you still want to try after reading this far, here is a plan that assumes six months of testing after a preparation phase. It builds on what worked in the documented pilots and on what is specific to technology teams.
Months −3 to 0: preparation. Collect a baseline for every measure in the measurement section. Review client and vendor contracts for business-day definitions and response times. Choose the model together with the team, not on its behalf. Change how work is organised: meeting review, work-in-progress limits, communication windows, documentation of critical knowledge. Agree with employment counsel in each jurisdiction how the new hours are written into contracts or policies and how work beyond them is treated. Write down success and correction criteria.
Months 1 to 3: first reduction. Start with a smaller cut, for example 10%, as the Polish government pilot did. Review flow and stability measures weekly and run a short team survey monthly. Track dependency problems: who waited for whom, and for how long.
Months 4 to 6: full reduction. If the first stage meets its criteria, move to the target, for example 20%. Pay particular attention to on-call, client support and work outside the new hours. Talk to clients and vendors about how they experience the change.
After month 6: decision. Compare the results with the criteria set before launch. There are three legitimate outcomes: keep it, adjust the model (for example from shared Fridays to a rotation), or return to five days. Each is an honest result of an experiment. The worst outcome is no decision at all: a policy that officially exists and practically does not work.
If you pilot in part of the company, say one team, compare it with a team that stays on five days. That is the simplest way to separate the effect of shorter hours from everything else that changes anyway, such as a new project, seasonality or turnover.
What are the key takeaways for CEOs and HR directors?
The four-day work week in IT is neither a fad nor a ready-made fix. The best available evidence says that a well-prepared reduction in hours improves wellbeing and reduces resignations without a clear loss of results, but it does not prove that productivity automatically rises. Governments are watching rather than legislating: Poland’s pilot has so far produced positive declarations, and its full results will arrive in 2027.
Six things to remember. First, distinguish reduced hours, a compressed week and part-time work, because they have different costs and different effects. Second, treat pilot results as a retention argument, not a productivity argument, and cost them as an investment in keeping people. Third, for teams that run systems or work with clients, choose a rotating day off or shorter days rather than a shared Friday off. Fourth, slim the week by cutting meetings, interruptions and work in progress before you shorten it. Fifth, measure flow, stability and out-of-hours work before and during the change, against criteria written down in advance. Sixth, agree availability and billing rules with vendors and contractors before you announce anything to employees.
If you are considering a shorter week and want to keep your delivery running five days a week, look at how ARDURA’s staff augmentation services work: specialists typically join within two weeks and the notice period is 30 days, so you can cover days and roles flexibly without loading your own team with on-call duty. Talk to us about structuring team availability around a new working rhythm.