Just write

There are just about as many approaches to writing as there are writers. Some technical writers start with an outline, some start with engineering specifications or market requirements. Unless it is a completely new product or process or whatever, most technical writers start with the existing (or similar) documentation. Some writers take a sort of 'stream of consciousness' approach. With all of these approaches, the author has at least a general thesis in mind: we know what we want to write about. I am particularly fond of this last approach for technical writing.

Starting writing is almost always difficult. Gene Fowler, a 1950's era screenwriter, is attributed as saying, "Writing is easy. All you do is stare at a blank sheet of paper until drops of blood form on your forehead." Overcoming the initial inertia of a "blank sheet of paper" can be almost overwhelming. As the director of a technical writing team, I was fond of telling my staff to "just write." Don't get caught up in style, or organization, or what you don't know. Just write what you do know. "Just writing" (with the appropriate end in mind, of course) allows for a focus on the text itself -- the rhetoric of the message. And as a great bonus, it leads to getting a lot of writing done. At the end of the day, the paper is not blank.

Knowing when something is "finished" has its own set of problems, There is always something else that can be written, or edited, or otherwise mucked around with. Using the parieto rule, 80% of the writing probably takes 20% of the time; the last 20% takes 80% of the time. Much of that is because we change and reorganize and edit and format and do a number of things at the end that don't have a lot to do with content. "Just writing" also helps prevent too much mucking. If you are focusing on the writing, you are not focusing on editing or formatting or rearranging. When you have nothing new to say, you stop -- and move on to the next topic to "just write" about that. It actually works.

At my company, we have been interviewing senior managers for the technical communication and training departments. A major topic of discusion is our corporate initiative to move to a structured authoring paradigm for creating "architected" knowledge bases using XML and DITA. XML is the extensible markup language. DITA is the Darwin information typing architecture. Both are technologies that facilitate creating documentation in a topic-based architecture, which makes it easier to reuse content. Because the new manager will manage in this new paradigm, it is important that we discuss it as part of the interview process. To date, each candidate who has already worked in a structured authoring environment stated that the technical communication team initially resisted it. From initial resistance, technical communicators either embraced it once implemented or left for environments more appropriate for their interests (often completely out of technical communication). I hear similar stories from my colleagues at other companies: initial resistance, then either a complete turnaround or total exodus.

Now the reason my little writing trick is of particular interest to me here is that it seems to be a good way to approach writing in the structured authoring paradigm. Research that I began for my master's thesis surfaced some initial data that supports this. However, my sample size was small and it was admittedly slanted toward adopters of structured authoring, so it really provides more of a possible direction for research rather than answers to the questions that I initially sought. One unanswered paradox continues to intrigues me: Why do some technical communicators seem to thrive writing in "topics," focusing almost exclusively on the text rather than format or style? And why do some thoroughly resist it? Before we had "word processors" and everything was typeset, technical writers had little to do with the way something would appear in a final document. The same is true when writing for publication even today; each publication has its own rules about style and format, which leads the author to emphasize the content without relying on format as a rhetorical vehicle for the message. So "just writing" is not specifically a question of the digital age, but it has come to the forefront as technical writing more and more becomes structured authoring.

Ruminations about offshoring

Discussions about outsourcing technical communication come up frequently in Society for Technical Communication events. Everyone "knows" someone who has lost a job due to outsourcing or has worked with an outsourcer or has provided outsourcing services. Where technical communicators stand on the topic generally has much to do with their own personal experience of outsourcing.

Outsourcing is not a new phenomenon. "Contractor" used to imply something less than "employee." A fellow contractor once referred to a group of us -- most ungraciously -- as "high tech prostitutes," the implication being that a contractor would do anything for money. I was offended by the remark. I would have characterized it differently: contractors tend to be willing to do what it takes to get the job and to get the job done.

As a natural progression of globalization, outsourcing has moved to offshoring (outsourcing that moves certain functions to another country). 'High tech' has outsourced and offshored functions like translation and quality process auditing to Canada and Ireland for decades. Perhaps because these functions were new (quality systems) or required expertise not available en masse (translations) in the United States, the popular reception of this type of offshoring generally was not particularly negative. Now, with more mainstream and traditional functions being offshored, offshoring is again getting media attention. Outsourcing, it seems, has gone mainstream.

Information technology support, call center support, software development, technical communication, and popular media reporting that previously was performed domestically is being offshored to skilled workers in India, Eastern Europe, China, and elsewhere. The company where I work is an international telecom developer that has grown largely through acquisition, with two of the divisions acquired in two different countries. Further, we use an outsourcing consultancy that often uses the more recent outsourcing method of "onshoring" (using workers in rural and other lower-paying areas).

Because it is on the minds and lips of my fellow technical communicators and my coworkers, outsourcing, offshoring, and onshoring picque my interest. I am particularly interested in different perceptions of these phenomena and intend to review how popular media as well as certain trade articles talk about them. If I can obtain IRB approval in time for this initial microstudy, I will also review discussion list posts on the topic from STC and techcomm lists that originate both domestically and abroad. To get at the meaning of the text, I will do text analysis of the metaphors and other rhetorical language that is used, analyzing the sources and the results to determine what patterns emerge. Although I have some notions of what I will find in this research, the rapid and widespread expansion of outsourcing in its many forms as well as the explosion of international collaborative teams may be changing how these phenomena are perceived.