The Many Hats of a Technical Writer

In this blog, Technical Writer, Ceiswyn Blake, shares what she finds most rewarding about her role.

Getting Users What They Need

I’ve been a technical writer for many years now (certainly more than I like to admit to). It is a job title that acts as an umbrella term for a lot of different roles and specialisations, from transcribing developers’ notes into reference information, all the way to creating video tutorials and infographics. The main thread that links all of the disparate responsibilities together is making sure the product’s users have the information they need, in the best location and format for them to use. Therefore, it is fundamentally underpinned by accurate information.

This means that – despite the name – technical writers typically spend more time researching and planning than they do actually writing. We ask a lot of questions: who is trying to use this product and what are they trying to use it for? What can we assume they already know and what do we need to explain from scratch? When would someone use this feature and how do they get the best out of it? Ultimately, we need to be able to explain not just what the product does, but how and why it does it.

The Rewards of Technical Writing

The constant variety and the need to solve problems on a regular basis are two reasons why I love the job. It’s also why I’ve made a speciality of working for startups and scaleups. I love the energy, the freedom to just see what needs to be done and to do it. I also love the challenge of, sometimes, having to do these things without extensive resources.

One of the really rewarding things about being a technical writer lies in our position at the end of the development process. We have a particular focus on the viewpoint of those installing and using the product, and that means we have a unique opportunity to catch any problems that others may have missed.

As the Development Team begin to see the finish line and the release of a new product looms, it is the unsung role of the technical writer to delay this exhale of relief and make sure the users are going to have everything they need. With an established product that’s normally straightforward, as there’s usually a handover process in place, but with new products it’s easy for aspects to be overlooked. As the technical writer writes the release documents, we are often the first to check details, such as how the install files will be made available and whether any new configuration steps have been discussed with the relevant teams. Even if these questions cause a delay in the release, we’re perfectionists – we want to make sure our users can succeed, right from the get-go.

Being a Perfectionist Pays Off

When the new product is finally released it has a magical effect. We all pause for a moment to take pride in the collective outcome of our individual efforts, and look forward to our users discovering all the things they can achieve more easily than before.