There are many flavors of technical writing. Mine is software.
One of the constants of any software team is the change that comes with employee churn. People find new opportunities by joining your team. People find new opportunities and leave your team for elsewhere.
Sometimes the “people” winds up being you.
What can you do to leave well? What steps can we writers take to make sure the baton passes well to the next person, whoever that next person may be?
Questions to ask
When it comes time to leave, you can discover things to leave behind or make ready by asking yourself some questions.
- What do you do?
- What did you struggle to learn or to find?
- What do you hope to have waiting for you at your next place?
What do you do?
- your work
- software you use
- websites you access
- usernames and passwords you enter
- people you reach out to
If you work in an office, consider other practicalities:
- where to get lunch
- best places to park
- office oddities to know (that one light bulb that always flickers, where to find extra printer paper)
Think about different kinds of days and leave behind lists that the next person can follow.
What did you struggle to learn or to find?
Think back over you journey in your position. What were the hardest things to learn? How did you learn them? Do you have resources you found particularly helpful that you can recommend?
Leave ideas of websites, books, podcasts, online communities, and co-workers that can be great places to discover new information.
What do you hope to find waiting for you at your next place?
A transition isn’t just a leaving.
It is also an arriving.
You are going somewhere.
somewhere isn’t retirement, then what are the types of things you want to have on hand when you start up there?
An organization chart? A list of steps to publish the docs in case there is a fire on day 1? Projects the previous person never got around to or abandoned in the middle of them? (aka, “gaps”)
Maybe you already have a list of questions you are drafting for your first day at the new job. Consider leaving answers to those questions for whoever follows you.
For my own leaving, I created the following set of files:
Setting up a new PC (assuming a clean slate)
Thinking about getting a brand new PC myself and what it would take to get it usable for my work helps me think through all the software tools that need to be locally installed.
Publishing the docs
A summary of the steps required to generate and publish our HTML5 doc site.
I am responsible for sending out notices about upcoming upgrades customers receive. This summarizes the when and the how.
My primary day to day tasks involve writing release notes, updating existing docs, and announcing release availability to the right audiences.
Subject Matter Experts
A list of who to go to for each area of the software, as well as other experts (the one office mate who has the best lunch recommendations, for example, or the amazing and willing editor from across the office in another part of the organization).
A list of the other (non-locally installed software) items I use in work. In my case, it is mostly websites that I use. But I also included online communities I participate in that are helpful, such as Antora and Write the Docs.
Not many people know where the videos used in our docs are hosted. It took me a bit to find them and get access. This involved recreating a former employee’s email address to get the password reset before I could then update the profile to my user name.
Before I am done, I may think of a few other items to note and add. But this is a good start.
Make the info accessible
Where you leave your helpful list of items is just as important as creating the help to begin with. After all, help won’t be helpful if your successor never sees it.
If the next person is just inheriting your computer with all of its files, maybe a prominent folder not too nested somewhere could work. If they are getting your desk, consider leaving a note in the drawer or on the monitor pointing them to the path or location of whatever you create.
In my case, I created a GitHub repository in the company’s organization. I’ll tell the manager about the repo and make sure they give access to the next person.
In the meantime, my teammates can also use the topics I have added to complete necessary tasks in the lag between my leaving and the onboarding of the next tech writer they hire.