Getting Started with Documentation: Hiring Your First Writer
(This is, basically, a continuation of my first article on Startups and Documentation. You don’t need to read that one first, but I think it’s a great place to start.)
So you’re going to hire your first writer! Congratulations, you’re on your way to happier and more successful customers and developers.
But where to start?
First things first, are you going to hire someone to write the docs, or someone to own the Technical Writing function? There’s a difference there. If you feel you have the bigger picture under control and just need someone to do the writing, you maybe don’t need as senior a writer.
Next, are you going to hire a contractor or go full time? If you hire a contractor, you may save some money, but make sure you understand what you need, can communicate that up front, and know that you’re dealing with a time-limited production. So you may very well end up doing some of the upkeep/maintenance yourself after the contract is finished.
Basically: be prepared to do some hand holding if you aren’t hiring a Senior Technical Writer to come in and own the function. Be prepared to do more of the work yourself (planning, maintenance) if you’re hiring a contractor.
And either way may be perfectly fine, depending on your situation!
Write vs Own
Based on the amount and technical complexity of the documentation you need written, you may not need a Senior Technical Writer.
If you’re the one on the hook to make sure the writing gets done, here are a few tips for working with contractors or less senior writers.
1] Be clear. Set clear expectations and deliverables up front. If you know you need a user guide and maybe some release notes, list those documents up front.
2] Provide resources. Yes, a writer will do the writing, but some of the information they need will come from other people or from other systems (like an installation of your software, etc.). Making sure those resources are readily available will not only speed up the time to completion, but improve the quality of the resulting documentation. This is doubly important when working with contractors. You want them up and running asap.
3] Understand that a contract (typically) has an end date. Contractors, by their very nature, have to have an eye on the next gig. The best ones are good at hiding it, but still, they have to be prepared to move to the next assignment. And, because of that, there tends to be a lack of true ownership for the documentation. Again, the writer is not at fault here. They have a limited time to get the work done, so they cannot always plan for long term maintenance or future enhancements. As long as you keep these things in mind, you can find ways to work around them (pad the contract with extra time if you can afford it, do as much as possible of the grunt work ahead of time, ask for a maintenance/what-to-do-next plan, etc.).
4] Plan to iterate. No matter how great your first set of documentation turns out, you will need to update the documentation at some point. Now, in the case of using contract writers, you may opt to do said updates yourself. Just know that it’ll be necessary and plan for it. Do not expect the documentation to stay current for long. The shorter your dev cycle (hello Agile!), the sooner and more often you’ll need to update documentation. The more complex your product, the heavier those updates will be. Having out of date documentation can be just as bad as not having documentation at all.
Own vs Write
Now, if you’ve decided that you don’t want to have to own documentation yourself — if you’re not an expert and don’t know exactly what you need, etc. — you’ll probably want to hire someone to come in and own it outright.
If that’s the case, here are a few tips to help you find the right person.
1] Ask questions. A Senior Writer will want to talk, a lot, about documentation. Asking questions is expected. It’s okay to admit you don’t know everything — that’s why you’re hiring a professional. A lack of questions is probably a red flag.
2] Hire someone with a plan. If your writer has a toolset in mind, or a favorite, proven approach they use for authoring and publishing, that’s a good sign. Setting up a toolset for documentation authoring and publishing is not a trivial task, and if your writer hasn’t done that before, be prepared for some chaos. Again, that may be fine!
Some things to consider when setting up a documentation function: Will you or your dev team want (or need) to be part of the process? You may need to use a toolset that works with Git and Markdown — perhaps a static site generator. Or, if part of the deliverables include API documentation, you may want to work with development to implement some kind of automatic API reference documentation tools, like OpenAPI/Swagger. A good writer will be able to adapt to the job regardless.
3] Be patient. Setting up the whole system can take time and even require some resources from other departments (Where are you going to host the finished documentation? How will you track/measure/analyze traffic and feedback? etc.). Know that this is all leading toward happier and more successful customers. This isn’t to say that you should not have milestones and deliverables planned out together with the writer. Just know things may take longer than you expect.
4] Trust. Trust your writer to do the job you hired them to do. Period.
5] Get buy in. If the only person making Documentation a priority is your writer, you (well, the writer) will run into problems. Luckily, most writers can make a convincing case for the necessity of documentation, but you want to be right there with them, championing the effort, the teamwork, and the results.
Of course, no two situations will be identical, but this should be enough to get you started.
