Not on a Friday

It’s early afternoon on a Friday, and a change request comes up for approval. Someone asks when it’s scheduled. Someone says today. The answer comes back before anyone has opened the implementation plan: not on a Friday. Nobody argues. Nobody asks what the change does, what it touches, or how it comes back out. The room has heard everything it needs to hear.

The rule holds without being written down. It holds without anyone needing to know a single thing about the change.

---

A rule that never asks what changed

The argument about Friday changes has two familiar sides. One calls the freeze risk management: don’t introduce change when the people who could fix it are about to leave for two days. The other calls it a symptom. If deployment is safe, it’s safe on Friday. If it isn’t, the freeze is covering for a pipeline that needs work. Charity Majors, arguing the second side, put it plainly: “Deploy freezes are a hack, not a virtue.” She still grants the hack its place. For a team without “the ability to move swiftly with confidence,” freezes before a holiday, a big event, “or hell, even weekends, are probably the sensible thing to do.”

Both sides are arguing about the change: whether it’s safe, and whether the process that delivers it can be trusted. The freeze itself never looks at the change. It doesn’t care whether the change is a firewall rule or a font. It asks one question, what day it is, and a calendar can answer that.

That’s where its authority comes from. A rule that takes no judgment to apply never loses an argument about judgment.

---

What the Sunday window actually buys

The same organization that won’t touch production on Friday afternoon schedules its largest changes for the weekend. The major-change window opens around midnight or 1 a.m. Sunday and closes at 5, now and then stretching to 6. Fear of the weekend can’t explain the freeze. The riskiest work the organization does is deliberately put there.

What makes Sunday different is what’s arranged around it. The implementers are booked for the window. The vendor is on standby. There’s a bridge line, a checkpoint where the change either proceeds or comes back out, and a full day of daylight before Monday’s start of business to fix whatever didn’t go to plan. The organization knows exactly how to make a weekend change survivable. It does it by putting people on the calendar.

It doesn’t do that every weekend, and it shouldn’t. Staffed recovery is expensive, and rationing the major-change weekends is the closest thing the change calendar has to a work-life balance policy, however imperfect. But the rationing has a consequence. Every weekend not chosen for a window is a weekend with no one scheduled to recover anything, and the Friday freeze is how the organization copes with those.

The day of the week was never the variable. Staffed recovery was.

---

Approved because it was in the window

Across years in major incident management and managing engineering teams, I sat through my share of major changes that failed. One of them makes the point better than the rest.

It was a network change. It went in during a sanctioned overnight window. It had been through the Change Advisory Board (CAB). It was on the calendar. When it didn’t behave, it couldn’t be backed out. The backout hadn’t been planned to the measure of the change, and once the change was in, it was in to stay.

So the recovery became somebody else’s work. By 4 a.m., other teams were being called: server teams and software teams who now had to rework their own environments to accommodate a change that was permanent. Not all of them answered. Some had no one available until later that morning. They were reshaping production around a change they had never reviewed, on a night they had never been scheduled for.

The review that followed found poor planning and coordination, and it was right. Had every department the change touched examined it, someone would have seen what it meant for the other operations teams. Its owner hadn’t planned a backout that could actually reverse it. The policy that came out of it required closer review, sign-off from every department head, and a solid backout plan.

The signatures weren’t the fix. The change had already been approved. What it hadn’t received was attention: someone reading what was actually going through CAB and asking who, outside the implementing team, would be living with it by morning. The window was staffed for the people making the change. Nobody staffed it for the people the change would reach, because nobody had identified them.

Being on the calendar had been taken as having been examined.

---

The change that touches everyone differently

It isn’t incidental that it was a network change. The server teams and the software teams working at 4 a.m. were each meeting the same change from a different side. The network is the dependency everyone shares, and it doesn’t reach everyone the same way or to the same degree. That makes impact analysis hardest where it matters most. In my experience, network changes were also the ones that got the quickest look.

Part of the reason is fatigue. A CAB that has approved a long line of one team’s changes without incident starts reading the next one as another entry in the line. Risk fatigue doesn’t announce itself. It shows up as a meeting that confirms the date and moves on.

The fix isn’t another gate. It’s the harder work the review skipped: tracing what a change depends on and what depends on it, bringing the teams it will reach into the review before it goes in, and establishing that it can actually be reversed. That’s slow, specific work, and nothing on a calendar can do it.

---

Built around Monday morning

Put the Friday freeze and the Sunday window side by side and they share a design principle. Both are arranged around the same moment: start of business on Monday, when users arrive and find out whether anything is broken. The window is placed so that whatever breaks is fixed before then. The freeze exists so that a change doesn’t break something while no one is watching and get found then instead.

That’s what the change calendar protects: the people it knows about—the implementers it booked, the vendor it put on standby—and the moment a failure becomes visible to the business.

The teams called at 4 a.m. were never on that calendar. They hadn’t approved the change, weren’t scheduled for the window, and were never asked what it would do to them. The calendar is built so that the business is never the first to find out.

Somebody still is.