“Oh no! I just realized we haven’t updated the help file for next week’s release, and Sandra’s still in Maui.”
When it comes to your product’s development and release planning, you should factor in vacation schedules just as you do budgets, sales training, marketing campaigns, and any other important contributor to a successful product release.
That means you need to know, as early in the planning process as possible, when to expect your cross-functional team members to be making progress on the product, and when to expect them to be on a beach in Maui.
Here are some ideas for getting a better handle on your team’s vacation schedules—so you never have to face an “Oh-no-Sandra’s-gone-and-can’t-finish-the-documentation-in-time” moment.
5 Tips for Building Team Vacations into the Release Plan
1. Prepare for vacations as part of your team’s product planning.
As soon as you have the broad outlines of a new release plan sketched out, ask your team to provide date ranges for any vacation time they have planned during that window.
Even if they’re not sure yet because they haven’t officially requested the time off, some of your team members should be able to give you rough estimates of when they might be away.
As you populate your team’s shared calendar with these anticipated vacation schedules, you’ll start to get an idea of when your team will be light (or completely without) certain resources and skill sets during the product development process. This will help make your planning and prioritizing much more effective.
Bonus benefit: Talking about vacations is fun, and it can make for some nice team bonding moments.
2. Ask your team to view the shared calendar often and add their vacation times.
When one of your developers or product designers goes on vacation, it’s not enough for that person to tell one coworker about it. The temporary absence of one person on a product team could affect everyone, so everyone should know when and for how long that person will be gone—ideally well before they go.
So it’s important to maintain a shared team calendar that tracks all important dates and events related to your product’s release plan, including vacation schedules. And each person on your team should add their own away dates as soon as their plans are firmed up.
One of the benefits of maintaining a team calendar, and encouraging your team to check it regularly, is that it helps foster a team culture built on sharing information. Looking up from your own work to see how you might be affecting your teammates is a habit worth adopting.
When Darryn notices on the calendar that Sandra will be leaving for Maui in three weeks and won’t be back before the product release, he’ll know it’s now a higher priority to quickly deliver her the details she needs to write the help file.
3. Define your “team” broadly.
Think of all of the people whose contributions you’ll need in order to carry out your release plan successfully. That list probably includes not only your developers, but also your QA team and product designers, and maybe your marketing team, sales reps, and sales engineers.
After all, if you release a new product and there’s no one around to market or sell it, did the launch really happen?
When you’re building out your team’s vacation schedule on a shared calendar, make sure to include everyone whose absence could affect the success of your product’s release.
Your rule of thumb should be: If their absence for a week during our release planning timeframe could affect any part of the product’s progress, then we all need to know about that absence in advance.
Tweet This:
“When you’re building out your team’s vacation schedule on a shared calendar, make sure to include everyone whose absence could affect the success of your product’s release.”
4. Don’t plan major releases around seasonal holiday times.
Product releases vary—by complexity, by lead time, and by newsworthiness to your users and the broader market.
Releases containing new features and functionality are obviously more complex and require long development cycles and contributions from many teams across the organization, including marketing and probably sales. Other releases might just include four or five bug fixes—still important, but not nearly as complex or worthy of an all-company campaign to get the word out and evangelize.
As a rule, if you are going to push out any releases around big seasonal holiday times—summer or end-of-year, for example—you want those to be the lighter, bug-fix types of releases.
If you try to launch new functionality anywhere near December 25, for example, you’re obviously going face lots of challenges. Not only can you expect that a lot of your own team members will be away for the weeks leading up to that release date, but you should also assume many of your customers will be focused on other things, too.
(This all assumes you are managing B2B products, by the way. If your team develops consumer goods that make great gift ideas, you might be entirely focused on a holiday-season release date, and that’s fine.)
5. Encourage time off for fun and rejuvenation.
Finally, it’s always worth stopping to remind yourself now and then that your cross-functional product team is made up of human beings, not machines. They need time away to decompress from the stress of work and recharge their mental batteries.
Look at that release plan calendar again, and remind yourself that by the 12th straight week of non-stop intensity (and some nights) at the keyboard, your developer Richard probably isn’t going to be as sharp, enthusiastic, or productive as he was on day one of your new development cycle.
So encourage your team to take some occasional time off. The great thing about building vacation planning into your product planning is that you can be a lot more strategic and proactive about it; this can even help nudge your team toward a few days off now and then for their own mental and emotional well-being.
That way Richard won’t show up to your office one day and tell you that if he doesn’t get to Maui ASAP, he’s going to snap!
