Four Important Personalities at your Next Professional Society Meeting

When (not if) you visit the local chapter of your professional society, you will likely get more than you expected.  Whether you visited the Society for Technical Communication for a presentation on single-sourcing techniques or the American Medical Writers Association for tips on presenting medical information, you will likely encounter four types at the meeting. 

1. The Critic rarely finds anything or anyone that measures up to the lofty standards formulated by this person.  Although there is value in identifying things that are wrong in a situation, becoming identified with this person by other society members might not help your networking.  So (if you tend not to see the faults where they occur) go ahead and touch base with this person, but don't spend the whole meeting absorbing toxic words.  If you tend toward the critical, spend more time with the rest of the crowd.  In the end, hopefully you will have a good balance of perspectives.
2. The Newbie can bring a new perspective and new energy to old practice; however, if you are new to the profession or new to the profesional society, you do not start with a lack of either.  So the fellow newbies that you find at society meetings should be sought out and recruited as fellow laborers.  Make yourselves accountable to one another in order to stave off the critics.  Make yourself conversational on other newbies' tech comm hot topics.  Encourage eachother to attend meetings. 
3. The Networker keeps current on key technologies and demonstrates that knowledge in conversation and in articles.  This person also keeps in touch with the key people that might want to hire technical writers and the writers who might recommend a colleague.  Therefore, these people are worth following and emulating.
4. The Volunteer keeps the society going.  Therefore, without this class of people, there is no society, no advancement of the field, no opportunities for the critics or newbies, and no network.  By learning the things that make up the volunteer and his or her work, you will be well on your way to building a technical communication career that will make a difference.

Four Things that You Can Expect as a Tech Writer

Once you transition from technical communication classes to real-world technical writing, there are at least four things that you can expect.

1. Your boss will not have had any experience with technical writing.  Most likely, your boss will have worked his or her through the workplace environment.  Therefore, your boss may be very familiar with managing manufacturing personnel.  Your boss may be an expert salesperson.  However, unless you work for a firm that specializes in technical writing, the chance that your boss will be familiar with localization, page design, usability, or any other technical communication topic will be minuscule.
2. Your boss will likely provide grammar edits (usually incorrect), word choices (usually jargon-based), and layout demands that will completely contradict everything that you were taught.  Because you are the new kid on the block, this will be an opportunity to learn both tact and assertiveness.
3. Your boss will have no idea of how long it will take to interview Subject Matter Experts (SMEs), compile a manual, have it reviewed, and send it to print.  Nonetheless, your boss will likely be very familiar with the contractual delivery schedule that everything sold by the company must meet.
4. Your proposals to improve processes will meet resistance.  Still, do not let that stop you from writing style guides.  Your company needs to know to improve intercultural communication (even in brochures and tech manuals) and you need to stand on your training as a technical writer.

Five Things Aspiring Technical Writers Must Do

Anyone desiring to work as a technical writer should take the following five steps, reflect on the steps taken (to see if those steps reflect a true image of the writer), and repeat:

1. Write technically by finding a technical topic you know and producing something that educates the rest of us.  This will involve applying your writing skills in several venues, including:
• Writing articles for an organization that centers on technical communication (refer to #2 on this list)
• Writing procedures for open source programs or non-profit organizations that need documentation
2. Network locally at your local chapter of at least one of the following groups:
• American Medical Writers Association - A great resource for writers working for medical device companies, pharmaceuticals, or similar entities
• Association of Proposal Management Professionals - A place to learn about writing an exciting proposal under tough deadlines
• International Association of Business Communicators - The best resource for organizational writers, public relations writers, and other business writers
• IEEE Professional Communication Society - A resource for writers addressing electronics or software
• Society for Technical Communication - The largest group of technical writers (including a number of special interest groups)
3. Commit yourself to continual learning (of software, of technical writing techniques, and of the technologies we document).  This may involve:
• Accessing online help sites of popular software packages
• Reviewing the current topics in technical writing circles by reading:
• I'd Rather Be Writing - A blog produced by a technical writer
• ffeathers - Another blog written by a technical writer
• STC's Notebook blog - One of many resources available from the STC
• TechComm Today - Another resource from the STC
• One of the many other blogs on technical writing
• Taking classes or doing online research of the techology used by your new employer.  Since I have worked at NASA, a few oil exploration companies, and some computer companies, this has involved a wide range of learning.
4. Network online in addition to your local efforts.  Join LinkedIn groups that are organized around technical communication.  Create a profile for yourself on Monster, Dice, and CareerBuilder.  Make yourself known to the local headhunters.
5. Be visible -- Make certain that your newest writing is available online.  If the chapter of your professional society (refer back to #2) is not online, post it yourself.

Things that Technical Writers Need to Provide (Part 3)

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 Document Design
Although technical writers do not need to be experts in semiology, psychoanalysis, or content analysis, we need to know enough about document design to create manuals, web sites, brochures, and other communication packages that speak to the audience. We need to know enough about the audience's eye movement across the page to make a page that flows. That is, for English speaking audiences, we need to know that the audience's eye will track from the upper left to the lower right of the page. For audiences who primarily read Chinese, Hebrew, or Arabic, those eyes will track in different directions.

Additionally, we need to be aware of the limitations of the fonts we incorporate (Are the lines so thick that they are hard to read from a distance?), the mix of colors we use (Can the elements of our pictures be distinguished as separate elements?), and the amount of white space incorporated in our illustrations and text. Although Jan White claims that serifs have a functional value in that they direct the eye and san serif fonts anchor the eye (Kostelnick and Roberts, 1998, p142), there have not been corroborating studies confirming these findings. Therefore, other than my own anecdotal evidence in support of White's study, I really cannot recommend this limitation on use of fonts. However, I can point to more than a few sources that would confirm that using more than two or three fonts on a page will reduce the readability of the page (Becker, 2009)(Krug, 2006, p36).

As mentioned previously, we also need to consider the cultural side of our pages and illustrations. Do procedural photos that are directed at Americans include someone pointing to the audience with the middle finger? Does a photo for an Arabian audience show the sole of a model's foot?

References

Becker, E. (2009). AMWA Presentation to UHD.
Kostelnick, C., & Roberts, D. D. (1998). Designing Visual Language: Strategies for Professional Communicators. Needham Heights, MA: Allyn & Bacon.
Krug, S. (2006). Don't make me think: A common sense approach to web usability. Berkeley, Calif: New Riders.

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.