As I mentioned before, my team has been looking to hire a couple technical writers.
While the requirements for any specific role may vary, I find that it is a role that scientists can transition into fairly easily, because so much of what we do hinges on our ability to communicate clearly and concisely about technical subjects.
I was really surprised when I was approached by a couple different scientists who told me they didn’t think they were even close to qualified, based on what the job description asked for. For the record, the job description asked for 3 years of technical writing experience in the software industry. These were both scientists who had successful research careers, been involved in education, and have reasonable publication records. I was surprised that they couldn’t see their own qualification, so I wanted to try to explain more about what tech writers do, in a way that helps scientists see how they might fit in there.
First of all, what do technical writers do? In general, technical writers prepare documentation that might be used as a resource or reference, like writing user manuals or help guides. In the last two weeks, the technical writers I work with on the training team have been updating workbook materials based on a new update to our software, planning the steps required for new learning activities with that software, and preparing PowerPoint slides for trainers to use in their classrooms.
One of the bigger differences in what they do, and what we do as scientists is that the tech writers prepare materials for someone else to use. This means they are more meticulous, and bring a different perspective, since they won’t be there to flip past the confusing slides, or provide additional explanations about confusing instructions. This is also their primary concern; it’s much easier to make spotless slides and bullet-proof activities when that is all you do.
Most scientists I have worked with have experience in writing those kinds of materials, either putting together protocols for use in the lab, preparing talks, or writing manuscripts. That is all great experience for technical writing.
Think about the last time you picked up the user’s guide to a piece of lab equipment or software. You couldn’t tell when the voice of the author changed, as each team member wrote different sections. How do these writers create such consistent content? Often, technical writers are people who have English majors, who enjoy writing. But for people making that transition, they are usually trying to figure out how to switch from writing creatively, to writing in a very predictable, clear way. To help with this, we use style guides.
My team uses the Microsoft Manual of Style, which describes a very particular way to write instructions for software, including how to structure sentences, and when to apply bolding or italics. This is more structured than when you submit a manuscript to a journal, but applying a style guide will feel familiar if you have ever had to revise a manuscript to send to a different journal or conference. To me, it seems easier to switch from writing technically about your scientific work, to writing about another technical topic, than it would be to go from creative writing to technical writing, since the experiences and motivations are quite different.
What other challenges do technical writers have? In many cases, a technical writer is creating documentation where none existed, or not enough existed. My team responds to updates to our software by reading release notes, and then playing with those features to make sure they understand how they work, and how those updates will impact other documents we have written.
For example, in a recent release, we were told that the Quick Filter feature is now just a Filter. The tech writers verified that it worked the same as before, and then identified where our materials referenced the old quick filter, and made updates to workbooks and slides. You can imagine, this creates issues with source control and version management. Fortunately, we have tools that help us deal with this, and generally, if you are working in a large enough organization, they will have some type of Sharepoint server or similar where documents can be shared, and histories can be tracked.
More and more strong communication is becoming an essential skill set to succeed in science. You have to write grant proposals, manuscripts, share your work at conferences and deliver lectures just to be considered a participant. All of this communication serves as great experience for moving into technical writing roles. So maybe the job asks for 3 years of software writing experience. There is a good chance the hiring manager would be willing to consider 5, 10, 15 or more years of scientific communication as a reasonable substitute.
Sandlin Seguin, PhD is an eLearning Specialist with Tableau, where she helps people learn to see and understand their data. Previously, she earned her PhD in molecular virology at the University of Pittsburgh, and worked as a Curriculum and Faculty Development Specialist at Bellevue College.