What exactly do technical writers “do”?

Friends and family often ask that question.

It’s complicated to answer because the nature of the work varies so much. Sometimes it means formatting preexisting documents to conform with a company style guide; sometimes it involves writing the style guide! Sometimes it involves writing everything from scratch; sometimes it involves not writing but streamlining the existing documents for usability. Sometimes it involves learning how to use a sophisticated documentation tool or content management system; sometimes it involves actually deciding what tool to use. Sometimes, the technical writer simply puts all the content into a single text file and let other people take care of the formatting; sometimes, the technical writer must make decisions about how the final manual ought to look (down to graphics and font sizes). Sometimes the only way to gather information is actually to use the product; sometimes one has no choice but to rely on second-hand knowledge from other users about how something works (or how to make it work).

Often job descriptions for technical writers indicate that the company seeks candidates who are “proficient in/expert at/have 5+ years experience in Technology X.” In fact, by definition a technical writer is someone who starts out as an ignoramus and who uses his own attempt to learn a new technology from scratch as a way to understand the common tasks customers must learn to use a technology successfully.

Often technical writing has more to do with business processes than technical processes. The technical writer may need simply to identify a number of tasks and then explain the procedures need to accomplish these tasks. In many cases, a technical writer’s work can not only provide user assistance but serve as effective marketing for the product. If manuals and user guides provide clarity about the product’s potential uses, that makes it easier for the customer to make a purchase decision.

How much time does the technical writer spend on writing the manual or user help? A lot less than one would think. Usually writing begins after the information has been gathered and the template is ready to go. Ironically, the technical writer usually ends up spending more time writing emails to engineers than writing documentation for the end user. Engineers often don’t have the time to explain things thoroughly or to write things down, and sometimes time zone differences prevent real-time conversations. It’s often easier and more time-efficient for the writer to “guess” about what is right and then check with the engineer to make sure.

The job requires flexibility and great improvisational skills. It requires great time management and the ability to scope a project. What things should the technical writer learn — and what things should the technical writer not waste time learning? Which tasks should the technical writer spend his time doing — and what tasks are more efficiently done by people with more specialized knowledge? When you read my job narratives (i.e., work experience) on this site, keep in mind that when I started each task at the company, I had no idea what I was doing! The manager never told me exactly what needed to be done except in the most general terms. I had to figure it out. I had to do a needs assessment and learn specialized tasks and figure out the optimal way to fulfill these goals with  the deliverables. Part of the challenge (and fun) of technical writing is adapting to a new set of circumstances with each project. Each job situation is different and requires a new needs assessment and documentation plan. Over the last few years I’ve picked up a few tricks along the way about how to perform these tasks efficiently. One thing I’ve found has helped me a lot in doing a job is simply giving progress reports that are as candid as possible and communicating potential problem areas to the team long before they become real problems.

It’s easy for technical writers to lose sight of the fact that documentation is only one part of product development. Sometimes other concerns take priority, and the technical writer must find ways to work around it (or at least to find other things to work on in the meantime). On the other hand, it’s important sometimes for a technical writer to speak up and even put his foot down. Some technical writers are content just to be a passive information sponge throughout the project. Personally, I think that is counterproductive; I try to play as active a role as possible when doing technical documentation. To identify information gaps and potential problem areas, you can’t wait for them to knock on your door. You have to seek them out actively and spend time understanding them.

Finally, a technical writer needs a sense of limits. Sure, any documentation can look great if you have an infinite amount of time to prepare it. But it’s important to make a realistic plan within the time constraints and be ready to prioritize when time becomes scarce. One common problem, for example, is spending too much learning and not enough time writing. One way to mitigate this problem is to think of documentation in a modular way. If you set up a template and organization scheme quickly and produce topics which are useful while still being independent of one another, that reduces the problem of the writer feeling squeezed at the end.

That is my point of view. Other technical writers, of course, may have different opinions.