Plan December around holiday leave,and ship the last release while the team is still here.

Ask in the last week of October and set a deadline: Friday November 6. Ask for every day someone expects to be out between Thanksgiving and January 4, including half days, travel days and the ones that are only “probably”. The maybes matter more in December than in any other month, because they all cluster around the same dates.

Ask in one place with one format: name, first day out, last day out, and whether it's confirmed. If your team already keeps leave in a sheet, the layout in a team vacation spreadsheet for engineering managers works for this.

Tell people why you're asking. You're not approving anything. You're picking a release date and an on-call rotation, and you'd rather build them on real plans than on guesses.

December 2026 has 23 weekdays. Take out Christmas Day on Friday December 25 and a US team has 22. That number flatters you. The weeks of December 21 and December 28 have four weekdays each, many companies give Christmas Eve (Thursday December 24) and New Year's Eve (Thursday December 31) off or end them early, and that's where the leave piles up. The honest number for shipping work is the 14 weekdays from Tuesday December 1 to Friday December 18.

Look back at November too. Thanksgiving is Thursday November 26 and many US teams treat Friday November 27 as gone, so from Monday November 30 to a mid-December release you have about two weeks. You can check any month on the working days page.

Then do the same for teammates outside the US. Say Marcus Lee works from London: December 26 is a Saturday this year, so the UK moves Boxing Day to Monday December 28. A teammate in Poland has Christmas Eve as a public holiday and January 6 off for Epiphany. Hanukkah runs from the evening of Friday December 4 to Saturday December 12, so ask who's taking time around it rather than assume. The team holiday calendar shows public holidays for any mix of countries.

The last release of the year should land on a Tuesday or a Wednesday in the middle of the month, with at least three working days after it while the whole team is still around. A Thursday or Friday release leaves no weekdays to watch it. In the example, that's Tuesday December 15, with Wednesday December 16 as the backup.

Why not later? Because the fixes after a release need the people who wrote the code, and from Saturday December 19 those people start leaving. Wednesday December 16 to Friday December 18 is the fix window: three days with everyone in, for the bugs that show up once real users touch the release. A release on December 22 would hand its first bugs to whoever is on call on Christmas Eve.

Write down a no-later-than date and agree on it now. If the release isn't out by Wednesday December 16, it waits until January. That sentence saves a lot of arguing later. Before you lock the date, run through the availability checks before choosing a release date: the release owner, the reviewers and whoever knows the riskiest change all need to be in from December 15 to December 18.

A code freeze only works if it has dates on it. In the example it starts at 5:00 PM on Friday December 18 and ends at 10:00 AM on Monday January 4, 2027. Put both times in the announcement, the release channel and the team calendar. “We'll freeze over the holidays” means a different week to every person who hears it.

Then say what's allowed. A short list works: fixes for production incidents, security patches, reverts, and config changes the on-call person needs to stop a fire. Each one still gets a second reviewer and a line in the release channel saying what shipped and why. Everything else waits, including small refactors and “just a copy change”.

Name one person per week who can approve an exception, and say what happens to work that's ready during the freeze: it stays in review or behind a flag and goes out with the first January release, not at 10:01 AM on January 4.

Holiday on-call is the part people remember. Split the break into short shifts so nobody carries both holidays. For a team of six it might look like this: Ben Carter from Saturday December 19 to Wednesday December 23, David Okafor from Thursday December 24 to Sunday December 27, Chloe Nguyen from Monday December 28 to Wednesday December 30, and Frank Delgado from Thursday December 31 to Sunday January 3. Say Ana Martinez and Emma Rossi covered last December; they're off the list this time.

Let people swap, and write the swap into the same schedule the same day. The failure I'd worry about is a swap agreed in a direct message that the schedule never heard about. Be clear about what reachable means: a laptop within reach and an answer within the time your team agreed, like 30 minutes. Name a backup for each shift.

Pay it back in a way people can see: a comp day in January, first pick of dates next December, a lighter slot in the regular rotation, or on-call pay if your company has it. A teammate whose holidays fall at other times may be glad to take December 24 and 25 in exchange for January 7, but that's their offer to make, not your assumption.

Treat the last two weeks of the year as their own small plan. Each has four weekdays, and the code freeze covers both. Say your six engineers have 48 weekdays between them across those two weeks (six people times eight days). If three are out for the week of December 21 and four for the week of December 28, you have 12 plus 8, so 20 person-days, and some of those are Christmas Eve and New Year's Eve.

Fill those days with work that doesn't need an absent reviewer or a release: tests, docs, small tooling, runbook updates, and notes for the January plan. Don't start anything that needs two people to agree on a design when one of them is away until January.

Say out loud that this is fine. A frozen, half-empty team is the wrong place for anything big. It's the same exercise as planning a sprint when three people are away, just with more of them away.

People are back on Monday January 4, 2027. Don't release that day. Lift the freeze at 10:00 AM, spend two days merging what waited and reading the on-call notes, and hold planning on Tuesday January 5 or Wednesday January 6.

Put the first release after the break on Tuesday January 12. A full week with the code that queued up keeps it a normal release instead of a catch-up dump. If something has to go out sooner, ship it alone as a small release.

Check January's calendar while you're at it. Martin Luther King Jr. Day is Monday January 18, a teammate in Poland is off on January 6, and some people take their leave in the first week of January instead of the last week of December. Ask about those dates in the same November message.