When I walk into the grocery store, I have a list. Though I’ve already meal-planned, considered my ingredients, and generally know what to buy, if I don’t have a grocery list I’m definitely forgetting something. It won’t be until I’m in the middle of cooking dinner after a long day that I realize—and I’ll have to decide whether to go back out and buy it or make a disconcerting substitute with what I have. Both options can end poorly: either I’m hangry and eating dinner at 9pm or worse, I’ve cooked something inedible.
If I don’t have a written grocery plan, I’m more likely to have a hectic week. But if I take the time to write out a list, organize it by area of the store, and double check to ensure I didn’t miss anything, my week is smooth and I feel on top of things. That’s a great feeling and worth an extra thirty minutes per week.
Simplify recurring tasks
According to Asana’s research, employees spend 60% of their time on “work about work,” leaving much less time for “thoughtful, deep work.” There are a lot of documentation tasks that fall under “work about work,” such as getting approvals, waiting on reviews, writing emails, and attending meetings. While some recurring tasks are worth it to keep everything moving forward, some take extra mental load that just isn’t necessary.
When you consider how many things we all have to remember on a daily basis, it’s clear that remembering every small task related to a release is a fallible strategy. By creating a checklist, you’ve simplified the part of your job where you consider everything that needs to happen before a doc release. No need to repeat that mental effort every release cycle.
Customize your list
Generic release lists are a great place to start, but the real value comes from customizing the list so it fits your product, your toolchain, your style guide. Think about what comes up every release cycle—what tasks are always on the board, what doc sets are always needed, what questions do stakeholders repeatedly ask?
For example, at a former company we had a specific setup that required sending doc URLs to certain stakeholders ahead of the publication date. This was an important task that was easy to forget. In the days leading up to the release, we’d get frantic messages asking about it, which seemed to degrade our rapport with that team. To switch from being reactive to being proactive, I added this task to our “1-Week Before Go-Live” list. After that, we completed that task every time and restored some trust.
Iterate on your list
It may take a few releases to know if your checklists are effective. I recommend holding documentation retrospectives, even if you’re a team of one. You can use that time to evaluate your checklists.
Questions to consider:
- Are there any tasks that didn’t get checked off?
- What items can be broken down into smaller tasks?
- What tasks weren’t on the list?
- Are there any “levels” missing, e.g. you proofread the content but missed checking the typesetting?
The more you use your lists, the more effective they’ll become.
Bonus: Add internal release communication
Your internal communication strategy during go-live can be just as important as what you publish externally. Who do you need to inform the docs are live? Do you need to send out reminders a few weeks in advance to be sure reviewers know what you need from them? How can you prevent last-minute changes that could have been included from the start? What can you do to ensure docs are top-of-mind for key stakeholders?
Ideas on tasks to include:
- Market to other teams when documentation will be published. What expectations or questions can you get ahead of? Do stakeholders generally know your publishing process?
- Post in the appropriate channels announcing the docs release. Do you know what those channels are? Do you have permissions/approval to post?
- Ensure the docs are included in internal release announcements. Who or what teams are responsible for these announcements? Does your company have an internal newsletter or announcements segment during company updates?
- Tell others how to submit a request if there’s a last-minute change or issue. Should they Slack a specific channel so others see the request has been made? Should they call so you can immediately address it? I’ve found that people are more invested in giving feedback if they know explicitly how to give it.
The bottom-line
Streamlining your doc release process with checklists will help you and your team focus on publishing usable, professional documentation. Don’t let the overwhelm of tasks bog you down—finish the release strong by knowing you have a plan.