A Letter from the Trenches of Technical Writing

Although I have not yet landed a professorial job teaching technical writing, I currently plan to teach technical writing on a part-time basis while continuing to work as a tech writer. Therefore, when I do get that first teaching job, I would like to offer my students the perspective of a technical writer on the front lines.  Having written NAVSEA manuals for 7 years, I have an idea of how to comply with multiple specifications.  Having edited and co-written manuals with the programmers of Unisys (who later became the programmers of the United Space Alliance), I have interviewed Subject Matter Experts, augmented the interviews by looking for their in-code comments, and pulled together their manual on time and under budget.  From my years of contracting with BP, I have experience in writing for offshore systems.  Finally, with over 5 years of working with Tuboscope, I have an idea of the processes involved in using ultrasonics and electromagnetic induction to test ferrous pipe for flaws.

From this experience and more, I would tell students that there are at least four things that you need to be good at to succeed as a technical communicator:

• You need to be write well and like to do it. Any engineer or technician can pull together an unstructured, grammatically-incorrect report (and save the company the expense of your pay). A technical writer is needed to pull together a document that meets the need of the audience while communicating the needed points.
  
  Regarding the part about liking to write, if you are really good at writing, you usually do like it. However, if you hate writing and are only after the paycheck, the tight deadlines usually associated with technical communication might not make this the best profession for the undecided.


• You need to get accustomed to continually learning. While in college, I read that the greatest number of technical writing jobs involved writing about computer programs; therefore, I took classes in COBOL and FORTRAN. Naturally, the first technical writing job I got had nothing to do with programming. Instead, I had to learn about pressure drops, cavitation, metal-to-metal seals, and other issues cogent to valves sold to the Navy. Through my 7 years at that Navy contractor, 12 years at NASA, and 10 years at various oil/gas companies, I have always had to learn topics I had not considered before.
• You need to learn your business environment by:
  • Introducing yourself to the stakeholder for the department that drives the company.
  • Making certain that your communications contribute to that department's and that stakeholder's success.
  • Just looking at the way things are done and following that model (but not giving up what makes you unique).
  • Meeting the subject matter experts and finding out how to help them.


• You need to learn about your audience. When I started tech writing, that meant going to the educational seminars my company provided for chief petty officers. Today, it might include creating a Facebook page, printing a mail-in card for inclusion in manuals, or conducting a wants-and-needs analysis. Additionally, it might include translation and cultural communication considerations (each of which would provide enough material for months of blog posts).

With all of this having been said, I look forward to hearing from you, my newest audience.