The vacation nobody mentioned until the release meeting.It wasn't a secret. Everyone just forgot.
The checkout team's release meeting was going beautifully. The new checkout had been in QA for a week, the payment provider migration was nearly done, and the slide on the screen said, in a large and confident font: “Checkout v2: Thursday, October 22.” Marketing had already put the date in Tuesday's newsletter. Someone had made a countdown GIF.
Then Mark, the one engineer who understood the payment provider migration, looked up from his laptop and said, in the tone people use for “we're out of oat milk”: “Oh, that's the week I'm in Cabo.”
Nobody said anything for about four seconds, which in a meeting is roughly a geological age. The cast of this story is made up. The meeting isn't. If you have ever run a release, you have sat in it, and this article is about why it keeps happening and the three habits that make it stop.
What happened next
Everyone turned to look at Mark the way you look at someone who has just booked a flight during the meeting. He had not. He had booked it in June. His cousin was getting married on Thursday, October 22, on a beach, and Mark was a groomsman, which is not a role you call in sick to.
Ana, who sat closest to the facts, scrolled back through the team channel and found it. August 11, 9:14 a.m.: “Heads up, I'm out Oct 21 to 23 for my cousin's wedding 🌴.” Three thumbs-up reactions. One of them was from Dana, the engineering manager, who was at that moment standing next to the slide with the countdown GIF.
To Dana's credit, nobody asked Mark to skip the wedding. They looked at what only Mark could do, which was finish the payment migration and be around when it met real customers. Ana paired with him on it for the rest of that week and the next, so there would be two people who understood it. The launch moved to Tuesday, October 27, when Mark was back, tanned and slightly hoarse from the reception.
Marketing sent a second newsletter saying the new checkout was “coming next week, and it's worth the wait,” which is what marketing always says and was, for once, true. The launch went fine. The countdown GIF was quietly retired.
Why the vacation wasn't really a surprise
Here is the uncomfortable part. The vacation was not a secret. Mark said it at standup in August, and he wrote it in the team channel, and three people acknowledged it with an emoji. The information existed. It just lived in people's memories and in a chat scroll, and memory is not where anybody plans.
That is how it goes on most teams. Someone mentions time off in passing weeks ahead, everyone nods, and nobody writes it anywhere the release planning will ever look. When the date gets set, the person who is out often assumes everyone remembers, and everyone else has simply forgotten. Nobody did anything wrong. A thumbs-up is an acknowledgement, not a plan.
That gap, between when someone mentions a vacation and when the date gets picked, is the whole problem. It is also why the product is called Forgot.
Habit one: ask for dates before you plan, not during
The release meeting is the worst place to find out who is away, because by then the date already has momentum. Someone has a deadline in mind, maybe a customer has been told “end of the month,” and the person who is out ends up feeling like the problem for saying so.
So ask before. A few days ahead of any planning or release meeting, send one short message to the team: “We're picking a release date for the next milestone on Thursday. Please send me any days you're out, or might be out, between now and the end of November.” Ask for tentative plans too. “I might visit my parents that week” is exactly the kind of thing that turns into a real trip later.
The same habit works for sprints. If you want the arithmetic for planning around people who are away, it's in how to plan a sprint when three people are away.
Habit two: write it down where you plan
Asking only helps if the answer lands somewhere you will look when it matters. A message with three thumbs-up does not count. Neither does an out-of-office event on one person's own calendar that nobody else has open during the release meeting.
Pick one place for the whole team's time off and put every vacation there the moment you hear about it, even in passing, even if it is tentative. A shared calendar works. A spreadsheet works, and if that is your style there is a layout in a team vacation spreadsheet for engineering managers. What matters is that it is the same place you open when you plan, and that it is on screen in the meeting.
The simplest rule for any team lead: when someone tells you about time off, write it down before the conversation ends. It takes twenty seconds, and it is the only part of this that depends on anyone remembering anything.
Habit three: check the release date against it, every time it moves
Once the dates are written down, check the release date against them before you say it out loud. Not only the release day itself, but the days around it: the code freeze, the week of final testing, and the day or two after launch when someone needs to watch the dashboards and fix what breaks.
Then do it again every time the date moves. A release that slips by one week can land right on top of a vacation that was nowhere near the original date. The second date is the one nobody checks.
There's a fuller list of what to check in availability checks before choosing a release date. The short version: who is out, who is the only person who knows a system that is changing, and whether a holiday quietly takes a day out of the week.
What the checkout team changed
The week after the launch, Dana made a spreadsheet. One row per person, one column per day, and a rule that any time off mentioned anywhere went into it the same day. It was a good spreadsheet. It had conditional formatting.
It lasted until mid-November, when Thanksgiving, two long weekends and somebody's tentative ski trip arrived in the same week, and the sheet was three days behind the team channel again. Dana was still the one checking every release date against it by hand, usually ten minutes before the meeting.
This is the meeting Forgot is built for. Every vacation goes on one timeline the day someone mentions it, the launch date sits on the same timeline, and if anyone is away that day, the board says so before the date goes into a newsletter. In the recording below, that's the whole story in thirty seconds: the launch lands on Thursday, Mark's wedding lights up, and the date moves to Tuesday before anyone makes a GIF.
The meeting you want instead
The goal isn't a team that never takes time off near a release. People should go to their cousins' weddings, and the best releases are the ones where nobody has to cancel a trip to make them happen.
The goal is a release meeting where nobody says “oh, that's the week I'm in Cabo,” because everyone already knows. The date gets picked with the vacations on screen, the person who is away gets a backup, and the promise you make to the business is one you can keep. Save the four seconds of silence for something that deserves it.
Four habits that keep the date honest
Ask about tentative plans too
“Maybe” is useful information. Write it down as tentative, and ask again two weeks before the release instead of finding out in the meeting.
Name a backup for every release-critical role
For release duty, on-call and the one person who knows the payment service, pick a second name before the date is set. A vacation then becomes a handoff, not a crisis.
Put holidays on the same page
Thanksgiving, Christmas and the days around them empty a team the same way vacations do. In December it is worth reading planning December releases around holiday leave before you pick a date.
Never make the person who's out the problem
If someone says “I mentioned it,” believe them, and check the channel. The fix is a better place to write it down, not a rule that people must speak up louder in meetings.
Memory, standups and DMs hold the dates.None of them is where you plan.
If your team is four people who sit together, a quick “anyone out?” at the start of the meeting may be all you need. Past that, the usual places vacation dates live break down in three ways, and that is how a known trip turns into a surprise.
Mentioned once, in passing
A vacation said out loud in standup or written in a DM is gone a week later. Nobody is careless; there is simply nowhere it was meant to go.
The calendar nobody opens in planning
Out-of-office events sit on personal calendars, and the release date sits in a slide or a ticket. Nobody has both open at the same time, so nobody sees the clash.
The date gets checked once, if at all
Even a good spreadsheet is checked by hand. When the release slips a week, nobody goes back to compare the new date against everyone's time off.
Write it down when you hear it. Let the release date check itself.
In Forgot, every vacation goes on one timeline the day someone mentions it, and the release date sits on the same timeline. If anyone is away that day, the board names them before you promise the date.
- Release dates as milestones, with a warning naming who's away
- Code freeze and release week periods that list who's out
- Tentative bars for the “I might be out that week” plans
- A request link so the team sends dates without signing up
Sign in with Google, no card. After the trial it's a one-time payment, not a subscription.
Questions
What do you do when a key engineer is on vacation during a release?
First, don't ask them to cancel the trip. Look at what only they can do, move that work earlier or pair someone on it now, and name a backup for release day. If the work can't move, move the date or cut the scope, and tell whoever was promised the date as early as you can.
How do you avoid scheduling a release when people are on vacation?
Collect everyone's time off before the planning meeting, keep it in one place the whole team can see, and check the release date against it before you announce it. Check the days around the release too, like the code freeze and the day after launch, and check again whenever the date moves.
How far in advance should engineers tell their manager about vacation?
As early as they know, even if it's only tentative. A vague “probably out that week” two months ahead is more useful than a firm date one week before the release. Whatever your company's policy says, make it easy to share dates early, and write them down when you hear them.
Should you ask about vacations before sprint or release planning?
Yes. Send a short message a few days before the meeting asking for any days off between now and the end of the period you're planning, including tentative ones. Finding out in the meeting puts the person who is away on the spot after the date already has momentum.
Is it OK to ask someone to move their vacation for a release?
Almost never. If the vacation was mentioned before the date was set, the date is what's wrong, not the trip. Move the work, add a backup, or move the date, and fix the process that let the clash happen.