You might get a kick out of this. I asked a couple of questions to Charles Stricklin at the WordPress podcast, and he answered my questions in his latest show (fast forward to the 40 minute mark). My questions aren't so interesting, but rather the way he handles the mention of my podcast URL, idratherbewriting.com.
What seems to be a completely straightforward term suddenly brings a sense of confusion and hesitance to Stricklin and his co-host. After a pause, they clarify that a tech writer is "someone who writes as opposed to someone who rides something."
Granted, they're probably just emphasizing that it's not tech rider (because with audio, it sounds almost the same). But listening to them pause made me wonder whether tech writer was any more sensible.
This is only the tip of the iceberg when it comes to the issue of what we call our profession. When I tell people I'm a technical writer, 99 percent of the time I have to clarify what this means. Most people outside the industry don't connect technical writing with user help. Even if I say I write "online help," most still don't get it.
The STC is viciously engaged in a struggle to change the job title of "technical writer" to "technical communicator" to more accurately reflect what we do. By changing our name and its description, they feel we would not only gain more respect for our roles, we would also jump up salary levels.
Lately many people have written about this subject. In Mike Murray's "Roadmap from Writer to Communicator," Murray explains that for at least the past 20 years he's had to perform tasks well outside mere writing. This makes the term "technical writer" grossly inaccurate. He says,
Even as early as 1985, it was easy to see that I would have to be more than "just" a technical writer. I had to learn the new Microsoft Office suite, including page layout and design. I found myself doing less writing and more creative design work. More important, the new technology provided me the means of using my creativity to develop entirely new communications tools and processes.
Susan Burton, executive director of the STC, explains that more than half of the professionals who belong to the STC don't have the job title of "technical writer":
STC's members don't hold a single job title. The most common is “technical writer,” but, according to a 2003 survey, that title accounts for only 43 percent of our members. Others include “documentation manager,” “information developer,” “content provider,” “documentation specialist,” and “technical editor.” ("Technical Communicator, Your Time Has Come")
She goes on to say that limiting ourselves to the job title of "technical writer" excludes us from the respect, recognition, and salary we deserve:
Long-time STC members who have risen to positions of prominence in industry, government, and academe have long said that our job titles are part of the “respect” problem. Simply put: our members do much more than write, and they're not getting credit for those other job functions. That has a negative impact on salaries as well.
The STC blames the Department of Labor for much of the confusion. The Department of Labor's current description of a technical writer is as follows:
Write technical materials, such as equipment manuals, appendices, or operating and maintenance instructions. May assist in layout work.
Burton explains that this definition leaves "no place in that paragraph for online help, wikis, animation, and dozens of other platforms now used by STC members." Instead, the STC would like to change the job title from "technical writer" to "technical communicator" and define it as follows:
Develop and design instructional and informational tools needed to assure safe, appropriate and effective use of science and technology, intellectual property, and manufactured products and services. Combine multi-media knowledge and strong communication skills with technical expertise to educate across the entire spectrum of users' abilities, technical experience, and visual and auditory capabilities. (Burton, Susan -- "You May Already Be a Technical Communicator")
What's most interesting about the new definition, Burton pointed out at the last STC Summit keynote, is that the term writing doesn't appear anywhere in the new definition.
Some might think it's trivial to just change terms from writer to communicator. Leah Guren, a strong proponent of the term communicator, explains that no matter what we call ourselves -- technical writer or technical communicator -- the reaction will be the same. So if ambiguity is inevitable, we should choose our own terms. She says,
Tell them that you are a technical writer, and watch their eyes glaze over. (You'll find that many people think it means a programmer.) Even within industries where technical communication is well established (such as high tech), few of our techie colleagues (developers, engineers, product managers) really understand what we do—or even what we produce. No matter what we call ourselves, we must have our elevator story ready—that one- or two-sentence explanation of what we do. ("Why I'm a Technical Communicator")
In other words, those who cling to the term "technical writer" because they believe it to be more familiar to others are kidding themselves. Technical Writer is just as obscure as Technical Communicator. So there's no strong argument for keeping the term technical writer.
I've been thinking about this issue for a while, and it's even more poignant considering that my podcast name refers to the term technical writer, which Guren calls an "ancient moniker."
First let me say that I'm proud to be called a writer. I've always wanted to be a writer, and the core function of my job is ultimately the written word (however enhanced it is with graphics, layout, online help, re-use, and so on). I don't think being called a "writer" is derogatory.
However, I agree that the term should ring more clearly in others' ears. Isn't it ironic that we technical communicators cannot clearly communicate what we do? I thought that using the term "technical writer" would alleviate the confusion and reduce the pretension, but I'm realizing that whenever I tell people what I do, the term technical writer is not any better (except to people already in IT).
Because of my desire for clarity, I also resist being called a "technical communicator." Everyone on this planet is a communicator to some degree or another. Communicator doesn't clarify what we do much at all. It's even more bland, non-descript, and ambiguous than writer, because at least writer hints at one of our deliverables.
(While I dislike the term communicator, I'm not opposed to it being used in the title "Society for Technical Communication," because the Society broadly encompasses a variety of professions. But it's only an umbrella term, not one that describes a specific type of worker.)
Competing alternative terms for technical writer include information designer, information developer, content provider, content manager, documentation specialist, usability specialist, information architect, user help specialist, instructional designer, help designer, user help developer, help architect, user assistance developer, and different combinations of these same terms.
The problem is that while technical writers may do some usability, some knowledge management, and and some instructional design, often these areas are peripheral to our core task: providing user help.
In the end, I'm all right with technical writer. But I do admit that it can be misleading and can lead to pigeonholing us into only performing writing tasks. I'm fond of "user help designer," but I realize it's not much clearer; plus I don't think of myself as a designer. The term "user" is also problematic. Still, at least user help designer or something similar would allow us to more freely move outside of writing tasks.
I'm interested to hear what you think.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include the following technical communication topics: Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, and certificate programs. I'm interested in information design, API documentation, visual communication, information architecture and findability, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.