Offboarding documentation 101

I switched teams at my current company a month ago, and one of the best suggestions I got during this process was to write an offboarding document for the team I was leaving.

What's an offboarding document and why is it important?

Regardless of the size of team or company you work for, there is always going to be something you'll have the most domain knowledge on. An offboarding document is a good way to transfer over that information to your team before you move onto your next role or team. It doesn't have to specifically be in a word document. It can be in any shape or form that makes it easy to transfer and understand the information you are presenting.

Yes, it can be tedious and time-consuming, but you're really doing this for yourself. The tech industry is smaller than you think, and you'll be remembered for the time you took to do this. Plus, it should reduce the number of questions you'll get once you move on.

What should I include in my documentation?

Depending on your level and role on the team, you might not have a lot to document. That's okay. As the most junior developer on my last team, I really had to dig deep for ideas, but I realized there were a lot of project quirks I remembered, and I had tackled some solo tickets like a Protractor to Cypress e2e test migration.

1. Is there anything from projects you've worked on that could be important? This could include rationale for certain decisions which have not been documented elsewhere. If the decision has been previously documented, it is still worth adding a link in your documentation so all the links and information are centralized.

2. Did you work on anything solo? In my case, my company is currently migrating all of our Protractor e2e specs to Cypress. My team only had to convert one spec, and because I worked on it myself, none of the other front-end developers on my team had the opportunity to write Cypress. I shared the dos and don'ts I learned from my experience, any links I found useful, and discussed the structuring of the spec.

3. Did you leave anything unfinished? This would be a good place to record what you've done so far, and what is required for the task or project to proceed and be completed. Document any decisions that have been made, including the ones that have not yet been implemented. Don't forget to mention any other stakeholders involved in case changes to the task or project need to be made.

4. Are there any folks that you normally rely on to provide specific knowledge? Is Jane your go-to person for all things data-related? If you think this information would be helpful in any shape or form, it most likely is.

Handing off the documentation

If possible, try not to leave your offboarding document until the last minute. Present it to your team earlier, and have them review it. Do they have any questions or suggestions for your document? Is there anything they're unclear on?

Does your team use cloud storage like Google Drive? Make sure you also share your documentation in a space where it can be accessed later. Also, if possible, transfer the ownership of the document or folder to your team once it's ready to go as your team may lose access to it when your user account gets deleted by IT.

If you found this helpful, and wrote an offboarding document, I'd love to hear about what else you've included in it!

If you have any questions or notice an error in this post, drop me a line at [email protected].