Technical Writing as a Career

I am a technical writer. I've been a technical writer now for almost seven years. Most people don't know exactly what a technical writer does, so here is a brief job description of what it is really like to be a technical writer.

First of all, I don't do much actual writing. Because most of my subject matter is highly technical, it would be near impossible for me to achieve the level of knowledge needed to write my own content. Instead, the majority of the writing is done by engineers or scientists, who pass the document on to me, where my job is to sift through the content and organize it. Sometimes I must repackage the information into a company standard template. And of course I proof the content. If information is unclear or missing, I contact the person who wrote it (typically called a subject matter expert, or SME), to gain clarification.

I often act as the in-house expert on sentence structure, grammar, and word processing software issues. I act as the champion of the publishing process established by the organization. My strength is in the organization of large volumes of content, both visually and structurally. Sometimes I use specialized software such as Adobe FrameMaker to complete my work, while other times I use Microsoft Word. In addition, I am often in charge of content management, which can turn into a whole job all on its own.

Technically speaking, I do not need to be an expert in most fields, although a background in networking is ideal when working in certain fields of IT. Some medical fields require a medical degree, and other fields, such as the airline industry, require an expansive previous working knowledge of the subject at hand.

I may write anything from a manual for a household appliance, to a trouble-shooting guide for a field worker, to a software installation manual. The majority of what I write, though, is the behind-the-scenes processes that are needed for a specific project. These documents include requirements specifications, detail design documents, in-house procedures and processes, and policies.

I learn a little about a lot. I usually work on multiple documents for multiple groups who are all working on the same project. For example, I may be working on a hardware installation manual while also working on a firmware document that describes the firmware to be burned into the hardware. The hardware folks are busy working on hardware issues, while the firmware folks are busy working on firmware issues, and neither have need to interact with each other, although the end product will be one seamless item.

Because most of my information comes from engineers and scientists, technical writing can become boring and isolating. Writing necessary documentation is generally very low on the priority list for engineers and scientists. Writing can get in the way of the product they are busy producing, so the documentation usually gets pushed off to the last possible second. When a project is winding down for the engineers, it is just winding up for me and vice versa. I usually don't get busy until very close to the end of the project, so I miss out on the hurry and flurry that was going on around me until the document arrives on my desk. Since my work is often the result of many meetings, I generally have no reason to attend the meetings until anything has been written. I sometimes refer to my work as being in "feast" or "famine" mode, depending on where in the lifecycle the product is.

Since I have no reason to attend most project meetings and am mostly utilized at the end of the project, I can suffer from isolation from the rest of the group. I am usually the only technical writer, whereas there are usually three or more engineers or scientists working together on the same project. I generally have to make a concentrated effort to remain connected to my peers. Feast or famine mode can make this unusually difficult, because it's hard to start up friendly chit-chat with others while they are working crazy hours to make their deadlines. Once their deadlines are met, I suddenly become in feast mode, where I am working crazy hours and they are finally getting a breather.

Financially speaking, technical writing can be a lucrative field and relatively easy to get into. I have seen quite a salary range, and it generally depends on how important an organization believes a writer to be. Those who do not value their technical writers offer low salaries. Those who see the importance of good document practices and are proud of their documentation offer very high salaries. Depending on the sensitivity of the documentation and the value it brings, a technical writer can be so fortunate as to pull in a six-figure salary, but this is not the norm nor typical for someone just starting out in the technical writing field.

One thing I do see is a lot of bad technical writers. People get into the field because it is relatively easy to get into, and they think organizing information is easy, so when they discover it is not, it's usually too late and they are in way over their heads. I could spend my entire career "fixing" botched documentation, and when documentation is bad, management tends to be quite vocal about it. Generally speaking, if management is quiet, then you know you are doing a good job.

And that, in a nutshell, is a quick look at what it is really like to be a technical writer. It has its ups and downs, just like any other career. Some days are a walk in the park, while others are like a pressure-cooker. The most difficult thing to get used to is the extreme highs and lows in productivity levels. But if you can ride it out, technical writing can be a lucrative and comfortable career choice.