Changing How We Describe What We Do

Returning to the Geek Squad profile on “60 Minutes,” there was another comment that stood out to me (emphasis added):

New York school teacher David Barkhymer, who considers himself a bit of geek, fell into the last category: he spent three days trying to hook up his new 32 inch HDTV, plodding through menus and a manual that was almost certainly written by Korean engineers.

As technical writers, we understandably have concerns about our jobs getting sent abroad along with those of our friends the programmers. Listening, however, to people’s stories about their own layoffs and what happened to their former positions after the fact, I don’t think I’m going too far out on a limb to say the bigger danger to our jobs lies within our organizations, with managers who think the responsibilities of our jobs can be transferred to someone else. Sometimes, it’s the developers (or engineers). Equally often it’s the folks in QA or tech support. I’ve heard of a few instances where documentation was transferred to marketing staff. These attempts to transfer our work are, of course, absurd because programmers/engineers, QA, tech support, and marketing are already overwhelmed with work.

The current issue of the STC’s Intercom magazine, coincidentally hitting our mailboxes about the same time as this “60 Minutes” story aired, revisits the topic of protecting our jobs from offshoring, dispensing advice that economic realities are making it necessary for us to remind ourselves of annually. The advice offered in this article, though, applies equally well when the threat facing your position lies within your organization.

More than the article, though, what resonated with me were comments made during a discussion of this same article over on Michael Stelzner’s Writing White Papers blog. In particular was Jim Logan’s comment (which I include a slightly abridged version of here):

The key is to add value beyond merely writing. If what you offer a client is perceived as writing, you become a commodity and price will determine the decision to hire your services.

I position my services such that my writing is a tool or “thing” that I do, it’s not what my customers buy. My customers buy more sales leads, more new customers, increased profitability, etc. I deliver those things with written words. The real value is me, which they can’t get elsewhere.

This position is available to everyone. The idea is to determine what you’re selling and not allow your services to be a commodity.

I’m always surprised when I meet technical writers who still describe their jobs as simply “writing manuals and online help” because it’s a view that’s too limited for these times. Taking Jim Logan’s second paragraph and simply replacing a few words, a technical writer’s position statement might be, “My employer [or clients] buy reduced call volume on their help desk hotline, less time to resolve individual calls, increased traffic in the online support knowledgebase, etc.”

If you were to rewrite this statement for your own situation, how would it read?