<!-- https://docs.google.com/document/d/15YrQkuPrcrz41yK7VjIpQt4sSj_hzbwakR91EwPBSKE/edit# -->
- How to decide which internal processes and procedures you need to write down about how you do your job. This is useful so that you can take a vacation day, take time off to go to the dentist, etc and have info in place in case someone else needs to do something in your absence.
If you’re the only writer at your company, there isn’t anyone who is going to perform the fundamental aspects of your job while you’re away for only a week. There isn’t going to be a person generating new content that follows the traditional process that you do. So unless someone is going to need to write, edit, and publish a complete piece of documentation in your absence, you probably don’t need to start with documenting the style guide you have floating around in your head.
While you’re away, developers will continue to produce new features and new design documents that will need to be incorporated into the overall documentation that you are producing, so a good place to start is with identifying the common sources of content and input you normally get for your documentation. If the development team that you work with is used to you catching all of the documentation issues in your morning meeting, someone is going to have to track those while you’re gone. What defines an issue or piece of content that needs to be documented? If you write down the criteria, you can distribute it to the development teams so that they can act as your proxy while you’re away. If you use an issue tracking tool like Jira, you can document the process you use for creating new tickets/issues, so that it can be referenced in your absence, and you don’t have a pile of emails that you need to input into Jira when you return.
If you’re further along in the process at your company, and you’re regularly generating draft documents, it would be helpful to document the tools and processes you use to generate your documentation and where that generated documentation can be found. Even if your review documentation is a bunch of Word files sitting in a shared directory, you can still document where it is and what to do with it. Speaking of… You should document how you want your documentation to be reviewed! Make sure that all of your reviewers are aware of the review process and where it is documented. Make sure to look through your review process, and if any part of that process involves you or any of your tools, you might want to evaluate if any of those tasks can be done by someone else. Maybe it’s generating a new html copy of the documentation. Maybe it’s sending out an email to stakeholders reminding them of the documentation review and where to find the docs. These are some simple things document so that reviews can continue in your absence.