This is the tenth post in the Advent of Technical Writing series, wherein I will share something I have learned from my experience as a technical writer. My experience is primarily in software technical writing, but what you read may apply to different fields, too. View all posts in the series.
As a technical writer, you should stay close to the teams whose work you are documenting. Listen out for any code, SDK, or product changes that may require action. When you hear that a tool may be deprecated, start communicating.
It just assumes that nobody will ever proactively reach out to the technical writer about deprecations, which is entirely true in practice, but just feels so sad to acknowledge. Please keep your content and document management team(s) in the loop!
I think engineers and UX should write the documentation first and then start working on the project. That way you have a clear idea of what should be in the software and how it should look. When things change you update the documentation. Then it’s already done and complete when you release.
Re: this section:
It just assumes that nobody will ever proactively reach out to the technical writer about deprecations, which is entirely true in practice, but just feels so sad to acknowledge. Please keep your content and document management team(s) in the loop!
I think engineers and UX should write the documentation first and then start working on the project. That way you have a clear idea of what should be in the software and how it should look. When things change you update the documentation. Then it’s already done and complete when you release.