POV
Never Deploy on Friday
Somebody learned it the hard way. They shipped at 5 p.m. on a Friday, something broke at 7, half the team was already at dinner, and by the time anyone noticed, the weekend had eaten the response wind
Somebody learned it the hard way. They shipped at 5 p.m. on a Friday, something broke at 7, half the team was already at dinner, and by the time anyone noticed, the weekend had eaten the response window. So a rule was born and passed down: never deploy on Friday.
We tell it like it's about caution. It isn't. It's about who's around.
Look at what the rule actually encodes. A deploy is a reversible move that occasionally goes wrong. When it goes wrong, you want the people who can catch it to be awake, online, and reachable. Friday afternoon is the moment that's least true — the on-call is thin, the reviewer logged off, the person who wrote the tricky migration is mentally on the train home. The rule isn't "deploys are dangerous." It's "this deploy, at this hour, with these people unavailable, is dangerous." That's not a safety rule. It's a coordination decision wearing a safety rule's clothes.
And once you see it as coordination, the folk wisdom looks crude. "Friday" is a blunt stand-in for a real question: is the context to catch a problem present right now? Sometimes Friday is fine — full team, quiet release, easy rollback. Sometimes Tuesday at 4 is worse than any Friday, because the one person who understands the payment path is on a plane. The day of the week was never the variable. The availability of the right humans was. We just didn't have a way to ask the precise question, so we rounded it to a weekday.
THE POINT
"Never on Friday" is a coordination call rounded down to a calendar rule.
The real question is whether the people who can catch the problem are around — and a system can know that better than a saying.
Here's the deeper thing. The rule survives because a human has to remember it. It lives in a person's head, gets invoked in a standup, gets overridden by a deadline, and gets forgotten by the new hire who ships on their second Friday because nobody told them. A piece of judgment that depends on someone remembering it at the right moment is a piece of judgment that will eventually be missed. That's not a discipline problem. It's a design problem.
So flip it. The timing of a risky move shouldn't depend on a human recalling a maxim. It should depend on the system holding the context the maxim was a proxy for — who's available, what's reversible, what's at stake — and surfacing the call before the move, not after the incident. Not a faster brake. A system that already knows the weekend is thin and the one person who'd catch this is offline, and says so, out loud, while there's still time to choose.
That's the shape of what we build at WorkElate. A risky, irreversible move doesn't slide through on a hope; it routes through the strongest reasoning, it carries the context of who and what's affected, and it pauses for a human to confirm before it commits. The system holds the rule so a person doesn't have to remember it — and confirms with you before it acts, rather than apologizing after.
▶ Watch on WorkElate See a risky move get held for confirmation — with the context attached youtube.com/@WorkElate · videoId: TODO — swap when publishedThe next time someone says "not on a Friday," don't argue the day. Ask the real question underneath it: if this breaks, is the right person around to catch it — and should we really be trusting that answer to whoever happened to remember the rule?
Related reading: The real cost of a task is coordination · Decisions over alignment · Why AI should execute, not assist.
Keep reading
