How to write a great extended leave document

I recently came back from an extended leave to find several of my colleagues asking to copy my “leave doc” for their own planned leaves. Having transitioned roles within GitHub now a number of times over the years, I’m no stranger to temporarily or permanently handing off work, and have evolved a preferred format I use to ensure business continuity during the transition. In service of “everything should have a URL”, I’m sharing my leave template here in case it’s helpful for planning your own leave.

Sections to include#

⏳ TL;DR#

“Too long, didn’t read”. This is for the folks who have a question or request, but don’t have time to read the whole document. Put it up front and make it visually distinct. The TL;DR can be as simple as:

If your question or request isn’t answered below, open an issue in X or post in Y and someone will point you in the right direction. Wondering the status of an in-flight project? Check out Z.

📅 Dates#

When is your last day in the office? When do you anticipate being back? If the exact date of your leave is unknown, you can provide an estimated range, or describe the leave in relative terms (for example, event + 2 weeks). Keep this section up to date as your plans change. Here’s an example of what that might look like:

☎️ Contact preferences#

How do you want to be contacted while on leave, if at all? What do you want to be contacted about? What’s considered urgent? Set expectations as to how often you will be checking email, Slack, your phone, and so on if you are going to check them at all, so that colleagues know how to get in touch with you, and when to expect a response.

✍️ Points of contact#

Enumerate all your ongoing responsibilities, along with a point of contact that will be responsible while you are on leave. Be sure to include “points of escalation” for anything not accounted for within your doc, and be sure to check with each named individual to ensure they are comfortable with the responsibility and have the bandwidth to take it on. Consider a dedicated “responsibilities to handoff” section for any key milestones, deadlines, or events expected to occur while you are out. Example:

📹 Regular meetings#

List any recurring meetings you normally run or attend, their frequency, and who if anyone will be taking your place at those meetings. Be explicit with any host or presenter responsibilities, and include links to standing agendas or other supporting documents.

👥 Rolodex#

For everything you touch regularly, list your primary point of contact. This will allow others to unblock themselves if they have a question or request of another department or team. Example:

👉 Stuff you touched recently or hope can be picked up while you’re out#

List any projects, initiatives, or other work you’ve been involved in recently, and any that you hope to be able to hand off to others while you are out. I linked out to our team project board, which captured the in-flight work, and created a “@benbalter’s GitHub Fan Fiction” document, with the backlog of ships that I had hoped would be GitHub cinematic universe cannon before going on leave. My fan fiction looked something like this, framed in terms of problems and solutions:

Problem: I’m going on leave and want to ensure that the work I’ve been involved with recently is not lost or forgotten while I’m out.

Ben’s solution: Write a great leave doc.

Ideal DRI: @benbalter

📁 Important links#

This is your long-tail appendix of anything you think your colleague might need while you’re out. This could include links to team documentation, commonly referenced spreadsheets or reports, planning materials, or anything else you think might be useful.

Share early and often#

You could have the best leave or transition document in the world, but if nobody knows about it, it’s not much use. Socialize the document with key stakeholders well before your leave to ensure accuracy and completeness¹, and make your document readily discoverable while you are out by linking to it from your chat status,² the out of office on your calendar, and any other “APIs” you have for communicating with colleagues.

Putting it all together#

If you’re preparing to go on leave (or transition to a new role), feel free to use the template below as a starting point.³ Of course, if you have any suggestions or proposed improvements, pull requests are always welcome.

# @your leave document

##