Things that Technical Writers Need to Provide (Part 2)

A recent discussion on the Technical Writer group at LinkedIn asked how to explain to a client that a technical writer need not be an expert in the subject matter of the manuals. As technical writers, we have to be learners, but we usually do not begin as experts in the scientific topics we cover. However, we must be:

• Experts in Communicating Across Cultural Lines Because our audience likely consists of at least one more culture than our own, technical communicators must take account of differences between different cultures. Therefore, G. Hofstede's cultural dimensions, A. Trompenaars' cultural theories, and E. T. Hall's cultural factors should be known and used as a first step in making our manuals applicable across cultural divides. Additionally, knowledge of the audience's culturally-based preferences.
  
  Worldwide audiences have wide-ranging ideas of how one communicates logic, credibility, and the rest of the message. In America, manuals often contain a picture of an open hand with the palm extended (refer to the illustration) to tell the reader to stop and read this text before proceeding. To the Greek, the same picture says “go to hell” (Flammia & Voss, p.84). To a Westerner, white may be associated with brides or the “good guy.” In China and Japan, white is the color of mourning (Vanka, p.16). Therefore, a writer should either know enough about cultural differences that can affect text and graphics or that writer should know enough to have their work checked by an editor for localization issues the document is complete.

(To be continued.)

References

Flammia, M., & Voss, D. (2007). Ethical and Intercultural Challenges For Technical Communicators and Managers in a Shrinking Global Marketplace. Technical Communication, 54(1), 72-87.
Vanka, S. (1997). Culture and Colors: Sacred Green, Lucky Pink? The Futurist. 31(40), 16-17.

Things that Technical Writers Need to Provide (Part 1)

A recent discussion on the Technical Writer group at LinkedIn asked how to explain to a client that a technical writer need not be an expert in the subject matter of the manuals. As technical writers, we have to be learners, but we usually do not begin as experts in the scientific topics we cover. However, we must be:

• Experts in interviewing the subject-matter expert (SME). In other words, we will have researched the topic, formulated intelligent answers, created ways to keep the SME engaged in the conversation, envisioned ways to calm a nervous SME, and organized methods to assemble the information into a helpful document.
• Fluent in speaking to and for the user. As we interview the SME, we must inject questions that the user would ask. As we write, we need to describe the steps of our procedure with the audience's education, technical expertise, and culture in mind. When in meetings, we need to represent the user among the engineering and programming experts. When observing in the design lab, we should bring results of recent usability research. To do these things, we must know the audience. Whether this knowledge comes through conversations with the sales force, through direct-response cards inserted into our manuals, or via social media accounts created for the promotion of our company, it does not matter.
  
  Likewise, as we speak to the reader through our document, we must write with a consistency that promotes user understanding. In other words, we must use one term for each piece of hardware or software that we document. We must resist the temptation to use "fastener" and "clip" for the same piece or switch between "clicks" and "taps" in the same procedure. To ensure this consistency, many writers assemble a glossary and stick to its terms. Additionally, compiling a glossary creates a valuable tool for translation and localization (which brings us to the next point).

To be continued.

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.

Finding the Time to Write Right

At this point, I am:

• Still part of a Master of Science in Professional Writing and Technical Communication at the University of Houston-Downtown (UHD),
• A student of a course on technical communicators' use of social media,
• An employee of at a major player within the oil/gas industry,
• The technical writer in charge of documenting a number products that non-destructively test ferrous pipe, and
• A student that may be within a month of completing his research on his thesis.

I have not yet:

• Finalized the last set of proposals to management regarding cross-cultural communications, localization, single-sourcing, usability testing, or plain language;
• Completed the writing on my thesis;
• Completed the course on technical communicators' use of social media;
• Completed the never-ending train of assignments at work (and am not seeking an end to them); and
• Investigated methods of fulfilling the responsibilities of a professor while working as a technical writer (however, I have read that professors at junior colleges usually work at one other job).

So why am I starting a blog?  Certainly, it is not for a lack of things to do (especially since I am also the father of a teenage son who usually needs as much help with his homework as I once needed).

One reason to start pops up out of the social media class I mentioned. Another reason to write this blog is to build up a reserve of examples I might use as I teach future classes. Maybe some of the blog material I put here might – with the input from all of you – be presentable to my compatriots at work.

The biggest reason that I write comes from my being a writer.