Why I Give Developers 3 to 4 Extra Days Off a Month
When a team delivers months of work in a single month, I give them extra days off, usually three or four. Yes, that's almost a full work week. The employer still comes out way ahead. Part 2 of 3.
Here's what I do with client teams now. When developers push a serious amount of work in a week, they get an extra day off. Sometimes two. Across a month it averages three or four.
Founders react the same way every time. But Oshri, that's a lot of days off. That's almost a whole work week!
Yes. It is.
Do the math on the other side
The months where I hand out those days are months where the team delivered what used to take four to six months. Put the two numbers side by side. The company received somewhere between four and six months of output and paid for one month of salary plus four days of rest. If that's a bad deal, I'd love to see the good one.
The employer benefits the most here, by a distance. Think of the days as maintenance on the one part of the system you can't scale by upgrading a plan.
Why a day off, specifically
Everything in Part 1 points at the same constraint. The agents don't need a break. The human holding six threads in a head built for about four does, and a normal weekend won't clear a week like that. Weekends are where laundry, kids and the rest of life happen.
A random Wednesday off works differently. Nobody expects anything from you, the house is quiet and your head finally gets to empty. People come back on Thursday sharper. In my experience the week after a recovery day is when reviews get careful again, and careful review is exactly what an AI-heavy team runs short of.
Call me crazy
Treating people like, well, people turns out to be good business. It always was. AI just widened the gap between what someone can produce and what they can sustain until you can't pretend it isn't there.
The alternative is a pattern I get hired to clean up. A team sprints for two quarters on AI-assisted output, then loses its two best engineers in the same month. Replacing a senior developer takes months of recruiting and ramp-up, and the knowledge in their head leaves with them either way. Four days a month is cheap insurance against that.
What the days are and aren't
- Not a reward for hours. Long hours are a warning sign in this setup.
- Not banked vacation. Take it the week it's earned or the week after.
- On top of regular PTO, never carved out of it.
- Tied to real load, so a quiet month means fewer of them, and that's fine.
There's a bigger question underneath all of this. If one developer now ships what used to take a small team, should their pay still look like it did in 2019? I think the answer involves a bonus tied to output, and that deserves its own essay. The days off are the part any team can start next month.
Part 3 covers the mechanics: who gets a day, how to stop it becoming the new target, and what managers should watch. If you'd like help setting it up on your team, let's talk →
