The Empty Desk Rule: Shipping Software When the Country Logs Off

Every November, a familiar email lands in my inbox. It is usually from a delivery manager, usually sent at 4:57pm, and usually says something like: 'Just confirming the Christmas deploy freeze starts on the 15th.' No one remembers who started it. No one can point to the incident that justified it. It has simply become part of the furniture, like the broken chair in the meeting room that everyone avoids.

That is not to say freezes are silly. A freeze can be a sensible risk control. But too often it is a habit dressed up as policy, and habits are hard to inspect. The useful question is not 'do we freeze?' It is: what risk are we buying down, and what are we paying for it?

A freeze is a risk decision in a high-vis jacket

Every change you hold back has a cost. It sits in a branch, gathering conflicts. It delays a fix for a customer. It turns January into a big-bang release with more surface area than the small changes you would have shipped in December. A freeze is not free. It is a trade.

Treat the bank-holiday calendar as a risk budget. Some windows are cheap to ship in: the office is staffed, the on-call rota is full, and a rollback is a five-minute job. Others are expensive: half the team is on a ferry, the person who knows the billing service is in Cornwall, and the only alert that matters is routed to a laptop that is closed.

You do not need a formal change advisory board to make this visible. You need a calendar with three colours and an honest conversation about who is actually around.

Map the calendar to the rota, not the rota to the calendar

Start with support capacity, not dates. For each week, write down who is on call by name, not by team. Note who is on annual leave, who is travelling, and who is covering two services at once. A bank holiday Monday is not a quiet Sunday. It is a different support shape: fewer people, more family obligations, and a higher chance that a page goes unanswered for twenty minutes.

Then classify the windows. Green means full rota and normal change appetite. Amber means reduced cover: planned changes are allowed if they are small, reversible, and have a named owner who is awake. Red means skeleton cover: security fixes and genuine outage work only, with an explicit exception process.

This is more work than sending a blanket email. It is also more honest. A blanket freeze hides the fact that some teams will ship anyway, some incidents will still happen, and the only difference is that the change is now unofficial.

Release is not launch

The most useful tool in this conversation is the feature flag. A deploy is a technical event: code goes to production. A launch is a business event: customers see the change. If you can separate the two, the calendar stops being a binary switch.

Ship behind a flag in a green window. Test it, watch it, and leave it off. Launch it in a week when support is present, or when the business is ready. You keep the pipeline warm, you avoid a January pile-up, and you can kill the feature without a rollback if the graphs go sideways.

If your architecture cannot separate deploy from launch, that is worth fixing. A team that can only ship by exposing a change to every customer at once is a team that will always be nervous about the calendar.

Write down what the freeze protects

A freeze without a memo is folklore. Write one page. Name the dates. Name the services. Name the exception process and the person who can approve an exception. Say what counts as an emergency. Say what rollback looks like. Say when the freeze thaws and who owns the thaw.

The memo should also say what the freeze is protecting. Is it customer-facing risk? Support capacity? A regulatory deadline? The risk of a large release landing while the finance team is closing the year? If you cannot name the risk, you are probably protecting a feeling. Feelings are allowed, but they should be labelled.

Keeping watch when the office is empty

A quiet dashboard is not the same as a healthy service. During a freeze, traffic patterns change, and so do the signals. Alert thresholds tuned for a busy Tuesday will either miss a real problem or page someone at 2am for a graph that is simply lower than usual.

Do three things. First, check that alerts route to someone who is actually awake, not just to a rota that looks good on paper. Second, add synthetic checks that exercise the journeys customers still use: login, search, checkout, the payment callback that always breaks when someone touches TLS. Third, agree a dead man's switch: if the monitoring itself stops reporting, someone gets a text.

And be honest about response times. If the rota is one person with a phone and a dog, say so. A freeze does not create support capacity. It only changes what you ask that capacity to do.

A checklist for the week before

• Who is on call, by name, for each day of the window?
• What is the blast radius of each pending change?
• Can it ship dark behind a flag?
• Is the rollback tested, or just written down?
• Are alerts routed to a human who is awake?
• Have we agreed the exception process for security fixes?
• Do customers have a way to report a problem that is not Twitter?
• When exactly does the freeze end, and who presses the button?

The goal is not to deploy everything in December. It is to stop pretending the calendar is a technical constraint. A good freeze is a decision you can defend, not a tradition you inherited. Clean builds are as much about clean decisions as they are about clean code.