Category: Skills

Posted on

“Workshopping” Documents Through Technical Editors: An Important Function of Quality

David Dietz

How many times has this happened to you? You call up a particular large business, say, for example, your bank, and at some point—as you’re sifting your way through the numerous automated messages to get to just the right person to address your particular concern—you hear the following announcement: Your phone call may be recorded for quality assurance purposes.
Over the past couple decades, it seems like quality assurance (or QA) has become increasingly important to businesses around the world.

A fervent commitment to quality is easy to understand. With the seemingly unlimited choices available to vendors and consumers—not to mention the greater ease and frequency with which legal action is pursued—quite often the X factor that “seals the deal” for a sale (or opens the door for a lawsuit) is the quality of the company’s products and services.

You might think that this concern for quality would also extend to the documents a company produces. Well, you’d be half-right. While many businesses now employ their own internal QA staff, too often, skilled technical editors aren’t among those QA specialists—at least, not at first.

Many companies chug along for years thinking that those skilled enough to perform highly intricate and complicated work (such as structural or mechanical engineering)—and who are fluent in English—must surely be able to craft quality documents. After all, they’re the ones who know the product or service better than anyone else, right? Well … yes—and actually, that is part of the problem.

Workshopping Documents

A few years ago, I got a first-hand appreciation for how being a product’s creator can easily lure someone into believing that they are omnipotent and omnicompetent when it comes to that product. However, what a product’s creator may not realize at first is that this “ultimate knowledge and capability” is a double-edged sword. Because, while creators completely understand everything there is to know about the product, common human shortcomings can limit their ability to fully articulate it in any sort of medium—at least, not without a little expert guidance.

This lesson was brought home to me when I had the good fortune to write a play that a local theatre company was going to produce. For someone who’s been an aspiring playwright for many years, this was a pretty big deal, and I wanted to make sure that my script was in the best condition that it could possibly be for stage production. Now, perhaps you are asking: What does writing a play have to do with technical editing and/or QA? Well, believe it or not, all good plays go through their own kind of QA process, much like any other product, service, or technical document would.

In “the biz,” it’s known as “workshopping.”

Before a play ever sees full production on stage, it goes through a number of developmental steps. First, of course, the playwright imagines the story, setting, and characters. Then, the playwright writes a draft of the play’s script and puts it in the proper format for presentation. (Yes, even stage plays must conform to a very specific layout before any professional theatre company will even glance at it.)

Next, the play receives what is known as a “seated reading.” In a seated reading, a group of actors is cast in the various roles in the script and read the entire play aloud (including all stage directions, and sound and light cues) for the benefit of both the playwright and producers. And, if the playwright is particularly fortunate, other performers, playwrights, and production people—and even general theatregoers—will also attend the seated reading.

Because, at its heart, a play is such a visual medium, it’s more helpful to the playwright, the producers, and a general audience to actually see and hear it being performed, as opposed to simply reading the script. Once the reading is finished, all those present offer the playwright feedback, including positive and negative reactions, and suggestions for where the script could be improved.

Take it from me: A seated reading can be a singularly humbling experience. It opens your eyes to things that may not have occurred to you while you were writing the script, such as

  • inconsistencies in the story or characters (or both)
  • unintentional humor in the dialogue
  • physical components of the set and props that may be impractical for the theatre to create

But perhaps the most startling revelation I had during my first workshop experience is that sometimes the author knows details that are important to the overall script in his/her mind, but somehow, in the course of writing, he/she neglected to actually include those details in the script!

There is an old showbiz adage that one of the things an actor needs to be successful is a thick skin. Well, let me tell you, that holds doubly true for playwrights (take it from someone who’s both). If I had not gone through the QA process of workshopping, my ego would have continued to keep me blissfully unaware of both the serious—and not-so-serious—problems of my script. And thanks to the input I received from the various people who attended my reading, I was able to completely pull what was inside my head out into the open, put it on paper, and ultimately realize it on stage.

Had any one of those people—each one possessing a different but vitally important set of theatrical expertise—been left out of the mix, I’m convinced that my play would not have enjoyed the kind of technical and critical success that it did.

The Play (or Document) is the Thing!

If you think of a technical document as being like a play script, then the importance of having a process to workshop or review for it becomes academic. And, to their credit, many companies will now concede this point. But, even if they establish a document review process, too often it heavily relies on simple self-checking alone. This can cause major problems. Because, although self-checking is an undeniably important part of the document creation process, solely relying on it isolates the author and overlooks the double-edged sword of “omnipotence and omnicompetence.” And no one is immune to its effects.

For example, at the company where I work when I’m not writing plays (or acting in them)—engineers write almost all of the technical documents. And, of course, they’re experts at making sure all the components work together the way they’re supposed to in the overall product’s design. But, much like a playwright, their “omnipotence and omnicompetence” can keep them too close to their subject matter. Or, to put it another way, it becomes difficult to see the forest for the trees. Consequently, like any other author, they can inadvertently leave out important information. Furthermore, because they are so focused on the product’s technical aspects (for instance, making sure that tab ‘A’ does indeed go into slot ‘B’), they tend to gloss over other important editorial considerations.

In an effort to help rectify this situation, the management at my company compelled the engineers to delegate their editorial duties. At first, they passed those duties off to administrative assistants; perhaps because they assumed—as many people do—that being able to speak fluent English is the sole qualification necessary to edit a document. However, this assumption overlooks the subtle but important distinction between copy editing and content editing. And, while many administrative personnel are more than capable of copy editing a document—checking for things like grammar, spelling, and punctuation—content editing requires the capacity to understand the subject matter on a much deeper, technical level.

The Case for Technical Editors

While using the copy-editing approach may produce a grammatically acceptable document, without a technical editorial (content) review, its overall quality is unlikely to be improved. To put it another way, it’s like having a seated reading attended and performed by set designers and stagehands only. While they can certainly comment on the physical components of the play, they are unlikely to provide constructive feedback on things like character development or story arc. It’s just not their focus or area of expertise.

Mistakes that have occurred while using only a self-checking departmental technical review cycle range from:
The simple:

  • Using vocabulary and abbreviations that are meaningful only to the author or company
  • Stating the obvious: “Project-specific drawings are created specifically for each project.” (As if they would be created for anything else…)

To the embarrassing (and customer-enraging):

  • Using the wrong customer’s business name throughout a document

To the technically incorrect:

  • Inadvertently missing (or misplaced) decimal points in measurement tables that could have an impact on construction or safety
  • Inconsistencies in numbers, reflecting changing calculation results—(perhaps because an analysis had to be rerun with different parameters, but the needed changes weren’t made in all areas of the document)
  • Procedural steps that do not make sense when one tries to understand what is being asked (information may be missing—most likely due to “omnipotent” knowledge; or perhaps the text refers to an illustration that does not logically match the text, and adjustments should be made to one or the other or both)

Therefore, just as it is important to have the correct mix of theatrical professionals at a seated reading, it is important to include professional technical editors as part of the review (QA) process for technical documents. Technical editors help to “bridge the gap” between simple copy editing and more complicated technical content editing. Contrary to common misunderstanding, technical editors are not simply copy editors. They’re specialists in technical writing, a unique discipline that molds and shapes highly dense, jargon-ridden, technical content.

Technical editors use their combined technical and grammatical expertise to transform the document’s language and presentation order into a form that the document’s intended audience will more easily understand and accept. This includes helping to ensure that facts are consistent, explanations are clear, and that figures and tables are in the appropriate location and clearly convey the information they are supposed to convey. Most importantly, technical editors can help the author determine if there are any gaps in the information. This kind of detailed review improves each document’s overall quality and usability, thereby increasing its value to both customers and vendors.

For companies like mine, clear, concise, and correct technical documentation improves not only our bottom line, but also our reputation. Because no matter how impeccable the technical work may be, if it’s presented in a sloppy document, readers will question the accuracy of the technical information. This is a particularly important concern for my company because it operates in a heavily regulated industry: nuclear power generation. Our documents are scrutinized with a gem cutter’s precision by

  • utility personnel—engineers, managers, quality assurance personnel, and licensing personnel, among others
  • regulators—the Nuclear Regulatory Commission (NRC)
  • industry personnel in organizations such as the Institute of Nuclear Power Operations (INPO) and the Electric Power Research Institute (EPRI)

So, at my company, document mistakes can dissatisfy many different but equally important people. And complaints about document correctness and clarity (that is, quality) lead to internal corrective action processes for formal resolution, which cost both time and money.

For instance, a power plant may want to change the level of power it produces. Several different analyses must be run to determine the impact of the change, each using various operating parameters. Inconsistencies can occur when a number (or series of numbers) isn’t changed to reflect the results of the analysis for that set of parameters—a simple oversight easily made in tight deadlines… but one that a technical editor should detect. Why not the author? Remember that whole “omnipotence/omnicompetence” thing? It often tricks the brain into thinking it sees what should be there on the page (when, in fact, it’s not). A fresh set of eyes doing a thoroughly detailed review can ensure that the correct number is used.

Projects can get even more complicated (both technically and financially) when a regulatory agency like the NRC is involved. The project may consist of a proposed methodology that, if approved by the NRC, may save our utility customers hundreds of thousands of dollars once it is available to implement. But, if approval from the NRC is held up for any reason—including clarity or correctness within the documentation—so is the utility’s ability to use it.

A utility may also apply to amend its license so that it can increase (or “uprate”) the amount of power it generates and hire my company to perform and document the analyses necessary to make the uprate possible. Changes in plant equipment may need to be made. If incorrect data reaches customers, and customers don’t catch the mistake, they may begin making expensive physical changes based on that data. Furthermore, if incorrect data reaches the NRC, the time to provide clarification may result in delays to plant changes planned for already scheduled maintenance outages. Outages are incredibly expensive. Timing is critical, and delays can be extremely costly. Action based on one oversight or confusing information can cost companies, and many individuals, significant money and time.

So, if there’s an important lesson to be learned from my workshopping experience, it’s this: when it comes to any written material—whether it’s a script for a play or a technical document—as John Donne once famously penned, “No man is an island.” It takes contributions from many qualified individuals to successfully produce any sort of product or literature. And, when it comes to producing quality technical documents, it’s a good idea to include technical editors as part of your QA process.

(By the way, in case you were wondering… yes, I even “workshopped” this article through technical content editors before I even submitted it for publication! Thanks, Donna, Jennifer, and Anitha!)

Posted on

Let’s Change the Career Paths for Technical Editors

Jean Hollis Weber

Traditionally, trainee editors were expected to become good at copyediting before an employer would allow them to do substantive (or developmental) editing, and senior editors were expected to work well at both levels. In my view, this is a short-sighted and outdated approach to a career path, especially for instructional and technical writing. It does a disservice to both editors and their employers.
The skill sets for copyeditors and substantive editors are different (a focus on details versus the bigger picture; rules versus analysis; strong English-grammar skills versus strong analytical and problem-solving skills). Both skill sets are important, necessary, and valuable; but good substantive editors may be poor copyeditors and vice-versa, although some people are good at both.

I’ve worked with people who had superb analytical skills (finding problems in the text or inconsistencies between the text and the product being documented, and often suggesting very good solutions to those problems) but who had only a basic understanding of some punctuation and grammatical issues. As long as these people were tasked only with substantive or usability editing work, they were extremely valuable on the project, because they tended to spot problems that the subject-matter experts did not notice: errors in logic and structure, unstated assumptions, use of idiom and colloquialisms, and other problems that native speakers miss. Teamed with a skilled copyeditor, such a substantive editor can be a major asset to an organization.

Today’s technical editing environment has expanded to include usability editing, mainly of electronic documents (Web pages, wikis, PDFs) but also printed instructional material such as user guides and repair manuals. Usability editing is concerned with the suitability of a document to meet its readers’ needs in terms of organization, presentation, navigation, and other factors. We all know that grammatically correct text is of little use if the instructions are unclear, steps are out of sequence or missing, or if the audience can’t find the information required. Usability is an area in which analytical and problem-solving skills—and people skills—are more valuable than grammar skills.

The best copyeditors go beyond the basics when editing. They find inconsistencies (“Figure 6 shows the back of the machine, but the text talks about the buttons on the front”), check facts (“the Apple Inc. logo has not been rainbow-striped for many years, and the company name has changed from Apple Computer Inc.”), and point out audience-specific issues (“your audience is international; most of them think 12/4/2010 means April 12, and many of them think ‘summer’ is December through February”). They have read widely, so they spot typos like “For Whom the Bells Toll” and a ZIP code starting with 2 for Spokane, WA, and they know that Stephen Hawking is British.

My career has included scientific editing, technical editing (copyediting, substantive editing, and usability editing), technical writing, and documentation project planning and coordination. I am well aware that I am better at dealing with the “big picture” than I am with the details, and I am much happier and more productive as a substantive or usability editor than as a copyeditor.

In my experience, most editors work best at either the detail level or the “big picture” level, and indeed prefer one or the other. Others have reported the same experience. For example, in June 2003, during a discussion on the STC Technical Editing SIG mailing list about the development or “maturation” of a technical editor, someone commented,

“During the last three years, we outsourced the editing… Some [editors] were more experienced with doing substantive editing and some with copyediting…

“We found that the two editors who could perform substantive edits at the macro level both needed intense instructions and deliberate coaching when assigning them copyedits. Otherwise, they would ‘go overboard’ and perform a more substantive edit every time, which was very unnecessary and didn’t match the client’s defined processes. BTW, these editors were highly technical and for our client, could very easily understand the jargon and products, which made them expert at seeing gaps in the writers’ instructions and conceptual text.

“Conversely, the copyeditors had great difficulty ‘stretching’ to do more substantive edits.”

My conclusion? We should change the career path for technical editors from a progression (copyeditor to substantive editor to senior editor) to some arrangement that allows all editors to be recognized, promoted, and financially rewarded for improvements in skills and productivity in whatever they do. This arrangement could involve having at least two progressions or tracks (one for copyeditors and another for substantive editors), but that might put impediments in the way of people who want to “change tracks.” A workable and equitable system would benefit both editors and the companies who employ them, so let’s start now to develop one.

Jean has a chapter titled “Copyediting and Beyond” in New Perspectives on Technical Editing, ed. Avon Murphy, Baywood Books, [In Press, due 2010]. She maintains a web site for technical editors, http://jeanweber.com/(external link).

Posted on

Scholarship Winner: Discovering the Breadth and Depth of Technical Communication and Technical Editing

Lindsay Taylor

Editor’s Note: Once again this year, the STC Technical Editing SIG offered scholarships to one undergraduate and one graduate student in technical communication. One part of the scholarship application was to describe a project or research that the applicant was involved in. We asked the scholarship winners to write a newsletter article summarizing their project or research. This is the first of such articles from our undergraduate scholarship winner.

Before taking my first undergraduate courses in technical communication at the University of Wisconsin-Madison, I had never imagined how complex and broad the field of technical communication really is. My coursework made it clear how much more I had to learn about technical communication, such as the different fields one can work in (science, engineering, etc.) or the different approaches to editing (individually and in a team).

To exemplify the variety of lessons I have learned—all precedents for future studies—I would like to describe two projects that were of particular value. Each demonstrates very different but equally important elements of my technical communication education. The first, for an introductory technical communication course, was writing and editing a semester-long research project on treatments for Parkinson’s disease in the fall of 2008. The second project, for a technical editing course, was a comprehensive team technical editing assignment on the UW Engineers Without Borders (EWB) handbook in March of 2009. I will describe what each project taught me about technical communication and how I will use that information in my future work as a technical communicator.

As an English major, I have written many research papers throughout my undergraduate career. In my first semester of the Technical Communication program, however, I was assigned to write a comprehensive, 15-page research paper on a scientific or engineering-related concept. While my background in science prepared me for the material, I was intimidated by the idea of writing a research paper of such magnitude outside of my own discipline. Even my work directing an interdisciplinary writing-tutoring program did not fully prepare me for the writing style used in technical communication, a style very different from what I was used to in the humanities. To write this particular research paper, I read countless samples of science writing and technical documents, meticulously followed my professor’s (Laura Grossenbacher’s) handbook on technical communication, and capitalized on peer-editing sessions with my classmates, all of which exposed me to different styles of technical writing. Though the report was supplemented by the edits and comments of my classmates, the paper was essentially an independent project that tested my ability to think critically and learn a new skill. By the end of the semester, I felt that I had produced an effective research paper and had discovered a new appreciation and passion for technical communication. This individual project reminded me of the importance of revision, word economy, and researching skills, all of which continue to contribute toward my success writing in a variety of disciplines. I know that I will remember this project one day when I am faced with a challenging technical communication assignment that tests my ability to be flexible and open-minded in learning new skills. I also value the independence that this project gave me: the ability to own a document from start to finish.

The second compelling technical editing project I worked on was with UW’s Engineers Without Borders (EWB) handbook in a technical editing course in spring 2009. Last year, two senior UW-EWB members informally produced a comprehensive, 50-page manual for new EWB members, describing everything from the group’s mission to how to use Skype when working in developing countries. The handbook was an important resource but would benefit from improvements in content, organization, and design. Our class was assigned to help improve the overall appearance and effectiveness of the document. In teams of four, our class worked to comprehensively edit the entire document. I’d like to describe this project because the team editing approach was so distinct from writing an individual technical document.

While I have worked on group projects before, I had never quite tackled a project of such magnitude. I learned how to collaborate with a team of editors who all see different positive and negative elements of a document. Just to interact within a group of four editors was challenging, but beyond that, the five groups in the class had to agree upon several universal editing points within the document. This project was particularly fascinating because of the amount of communication that went on among and between groups. Editing this large document would have been time-consuming and rather impractical for just one editor. This team editing project truly taught me about the effectiveness of a group of editors, something that I had not completely understood before this course.

One additional technical editing lesson I learned from the EWB handbook editing project was the great difference between copyediting and comprehensive editing. As a Writing Fellow (a UW writing tutor), I was trained to prioritize global issues in a document; then, as the copyeditor of the Wisconsin Engineer magazine, UW’s undergraduate engineering publication, I focused specifically on local, mechanical edits in documents. However, in addition to these issues, my work on the UW-EWB handbook taught me that the field of technical editing also requires analysis of organization and content and maintaining an open communication line with the author. My group and I closely collaborated with the authors of the handbook, and we were responsible for making universal changes throughout the document on both objective items, such as capitalization, and on more subjective topics, like the tone of the handbook. I discovered that several elements of editing are interdisciplinary, despite the great differences between writing styles and fields.

Both of these projects stemmed from great assignments set by excellent professors. I am grateful for the distinguished professors I was able to learn from during my undergraduate technical communication studies at UW. The lessons I gained from their projects were diverse, yet each provided fruitful practice for a future career in technical editing. I realize now that technical communication crosses many disciplines, topics, and writing styles, and as a recent graduate deciding on a career path, the diversity of the field is the most compelling factor to me. I will retain the lessons I have learned from both of these projects and will apply that knowledge in my continued education of the field of technical communication.

Posted on

Creating an Anthology on Editing

Avon J. Murphy

Pulling together New Perspectives on Technical Editing, an anthology on editing, was a complex, yet exhilarating experience. The process fell into four stages.

The longest stage was the gestation stage. I’d written an annotated bibliography on technical editing for the National Council of Teachers of English two decades earlier. Long a highly organized pack rat in careers as academic researcher, government research analyst, and finally editor, I had several hundred articles and a hundred books on technical editing. But something was missing from all this literature. As much as I’d gripe about the hole over the years, I couldn’t quite identify what I wanted. Tom Warren, of Oklahoma State University, challenged me to do something about it.

Energized by adrenalin, I charged into the second stage: What would we learn by looking at our discipline from different points of view at once? This question morphed into another: How much would we learn if recognized experts wrote separate chapters addressing the deeper questions suggested by their specific approaches to editing? Thus was born the idea of a collection of research-based and experience-based chapters looking at technical editing from various angles.

The collection eventually came to include such disparate angles—the “Perspectives” in the book title—as research methodologies, editing with electronic tools, editing within particular environments, the teaching of editing, and so on. Dozens of questions wrote themselves. For example, what methodologies can editing researchers best use? Is technical editing more complex than it was in the mid-20th century? What choices do teachers of technical editing have for designing their course? How can the structure of an organization dictate editorial career paths? How can copyeditors ensure quality? How have computers changed technical editing? What special problems do science editing and journal editing present?

The most challenging stage personally was getting the right people on board. As Technical Communication book review editor for nearly two decades and as manager of several research efforts, I’d been monitoring the careers of several accomplished editors; my short list of candidates was almost ready before I wrote it out. I was looking for original thinkers within their niches who had published a good deal, were dependable, and would keep me informed about their progress. Michelle Corbin, Angela Eaton, Barbara Gastel, Geoff Hart, George Hayhoe, Carolyn Rude, Tom Warren, and Jean Hollis Weber were all such people. The time-consuming part was to convince each individual to participate. I showed them the shape of the book, its contribution, the possible main points and resource leads, how the editors could individually contribute within their specialties, and the impact of this writing upon their careers. After some anxious weeks for me, all of them finally accepted the challenge.

The final stage was comparatively easy. Having lived so long with the book-to-be, I watched the proposal write itself. Baywood Publishing was the only company I seriously considered, and it quickly accepted the proposal. With schedule, style sheet, and chapter template on their computers, my contributors then set to work on what has become a most rewarding book.

As the writers submitted their chapters, my developmental editing focused on innovative thinking about questions, acceptable research methodologies, avoidance of excessive duplication among chapters, and incorporation of already published literature. On the second and third drafts, I focused more on voice, paragraph structure, sentence clarity, and formatting within my template restrictions.

The full manuscript went to Baywood in late September 2008, Baywood approved it in mid-November, and I sent the slightly revised files in early December. The manuscript is now (late April 2009) in typesetting. After proofing, correcting, and indexing, the book should appear in something like 15 weeks. I’m certainly happy to be working with a publishing firm that stresses the importance of high-quality procedures, including editing. Would I want to edit another anthology? Ask me after I’ve recovered from this one!

Posted on

Thoughts on Copyediting, Outsourcing, and the Technical Communication Profession

Russell Willerton

In July 2008, Business Week published an article by Nandini Lakshman called “Copyediting? Ship the Work Out to India(external link).” This article focuses on Mindworks Global Media, an Indian company that handles copyediting, layout, and reporting tasks for several American newspapers.

When Mindworks started, the company took on Indian clients. Over the past several years, however, the company has taken on more U.S. clients as readership of print publications has declined and cost-cutting efforts have increased.

Nandini writes that outsourcing work to India helps keep publications in business. She quotes Mindworks CEO Tony Joseph, who said editorial outsourcing “helps [publishers] improve efficiencies in editorial packaging and reallocate resources to reporting and writing.” Mindworks told Nandini that the company helps publications cut costs 35% to 40%.

I posted a query to STCTESIG-L on July 11—primarily out of curiosity—to ask if anyone was familiar with copyediting of technical publications being outsourced to India. (Clearly, such a question reflects the fact that I live and work in the U.S.) Virginia Janzig, Ben Jimenez, and Marie Highby cited examples of copyediting being done by or in tandem with employees in India. Gururaj B. S. and Sankara Rajanala pointed out that while many editors work for Indian companies, work done by Indian companies is not always outsourced work.

We know that native speakers of a language often reach a level of fluency in that language that can be difficult for others to achieve. Said Jennifer Collister, working in the U.S. for a company founded by Indians, “When I’m editing pieces of the proposals, I can tell just by the writing style who is a native English speaker and who isn’t. However, the non-native English speakers get their point across but are just making grammatical and sentence structure mistakes.”

I suspect that this not-quite-native fluency in English contributes to a reduced level of confidence many U.S.-based writers might have in work done by editors whose native language is not English. Janice Gelb’s comments reflect such sentiments: “The cost of hiring an inexperienced or less competent employee (and I hasten to add that I am not speaking specifically of employees in India) often appears to be less in strict monetary output but in fact does cost the employer in the long run. These costs are both in real dollars (cost of redoing unacceptable material, increased cost of translation, increased volume of support calls, and so on) and intangibles such as customer product satisfaction and perception of corporate concern with quality.”

However, a detailed post from Sankara Rajanala (affirmed on the list by Mike Boyd), provided a different view. I provide these excerpts.

“It is not true that non-native speakers can never do as well as native speakers, especially when it comes to writing and editing. Eminent examples of this are Joseph Conrad and Vladmir Nabakov. I am deliberately omitting Indian authors…. Recently, I was on a conference call with a lot of new ‘faces’ (new to me). The next day I was asking a friend who was also on the call (from a different location) who the American on the call was; he said everyone is an Indian: turns out, one was based in the U.S. for a long while and I mistook him for an American…. No one can defend outright ungrammatical use of English but there are a lot of Indianisms that make our use of English colorful (to be avoided in technical documents for sure) and the name of the game is accommodation….
Not so long ago American English itself was dubbed as Americanisms, until H. L. Mencken got into the act. Right now, there are many Indians who proudly say ‘we are like this only’. But on the job, we diligently follow the norms of whichever language (Am, Brit) we are supposed to be writing in.”

Don Cunningham, professor emeritus at Auburn University, wrote that recent trends in outsourcing reflect on the state of the technical communication as a whole. “If we do not market ourselves and our profession effectively we will likely lose a significant amount of work to those who are willing to work for less. And this is not totally a geographical/locational issue.”

Adrienne Maxie pointed out that jobs do not necessarily belong in any one country. She asks, “What if we changed the way we looked at ‘our jobs’? Technically, the jobs don’t belong to ‘us’; rather they belong to the employer who then contracts with us to provide a specific task in exchange for a monetary value. Since the jobs do not belong to us as writers, editors, etc., then the employer can contract with whomever he or she decides can provide the most output for the least amount of money.”

Ram Venkatraman’s comments (in excerpts here) reflect a similar view:

“The other day, while holidaying in a remote Indian town, I met three young Frenchmen. Two of them had just completed their engineering degrees and secured internship in an Indian company. The third young man is expecting to complete his degree in networking technologies sometime next year and took my business card and promised to get in touch with me when he is ready to take up an internship. This is what students in India did when they did not have opportunity in their homeland decades ago. That is what I did….Now, while I totally understand the concerns of folks whose jobs might migrate to other countries where cheaper labor is available, the big picture is a historical transformation that has been shaping up for centuries. Like the three Frenchmen, people may move to places where there are opportunities. Living and earning in India can provide the same lifestyle as earning and living in Germany. Millions of people around the globe do precisely do that. My family moved to study in US more than a decade ago. Then, one fine day we moved back to India because the opportunity was there. If the opportunity moves to Timbuktu, I will be packing the bags again.”

This discussion reminded me that technical communication is one of the many facets of the global economy, and that technical communication tasks can be done from any spot on the globe. Wherever we find ourselves, we must demonstrate and articulate the value we bring to our employers and their consumers. Standing still will ensure we get left behind.