Tina the Technical Writer doesn't work here

If you're a technical writer, you may have had this experience:
The new guy on the product support help desk walks in, holding the system administrator's guide that you designed, researched, wrote, and illustrated. He scans your cubicle, looking for signs of - heaven only knows what, but clearly it's not there.

Help desk guy: "Hey, I just started here and they handed me this manual. It's great! Who wrote it?"
You: "Um...I wrote it. I'm the technical writer."
Help desk guy (gawking): "YOU wrote it??"
You: "Yes. That's my job. I write the manuals. I write the help, too."
Help desk guy: "Who helped you with it?"
You: "Each of the developers answered my questions about the features they own, and they each reviewed the topics where their features are discussed."
Help desk guy (floundering): "But...I mean...how did you know what to write?"
You: "I started with the product requirement documents and the feature design documents, and I spent a lot of time playing with the product as soon as it was stable enough for me to poke around at it."
Help desk guy: "You actually use the product?"
You: "Sure. There's really no other way to get familiar with it, and I have to understand it myself before I can help other people understand it."
At this point the help desk guy generally wanders off to recover from having his world rocked.

If you've ever had that conversation with the disbelieving help desk guy, you know the source of his disbelief and your frustration: Enough people have encountered non-stellar tech writers that stereotypes exist. You can't change that. Neither can I. The only thing we can do is choose not to conform to the stereotypes.

So forget Tina the Technical Writer, the character in Dilbert. She's a cartoon character. Roll up your sleeves and get into the technical details of the thing you need to explain to your customers. Tell your developers when you spot things that may cause problems for customers - "Can you build some validation into this field? Right now, this form lets me build a test condition that's nonsense." Focus on what you do best and let the stereotypes take care of themselves. It doesn't take long for people to realize that whatever they expected, in you they've got a person who readily grasps technical concepts, is passionate about communicating useful information to people who need it, and visibly contributes to the organization's success.

The idea that wouldn't die

Some ideas sound great for about five seconds, and then gracefully go away. Some sound uninspiring at first, but gradually reveal their brilliance. And some ideas sound like Manhattan Projects for opening pickle-jars, but they just won't go away. Exhibit A in this category is the idea of certifications for technical writers.

Full disclosure first:
I do not meet the educational requirements so loved by personnel departments. I have never studied journalism or English, beyond the bare minimum. I do not have a bachelor's degree in anything. I have a trade-school degree in electronics. I became a technical writer more or less by accident. So I don't like the idea because it might mean my résumé and sheaf of awards might not be enough to get me in the door for interviews.

Let's step back, though, and think about this.

What problem are we trying to solve?
There's no arguing the fact that in every profession, there are people who just aren't any good at what they do; and it's hard to get rid of them once you've hired them. It would be easier if there were a way to avoid hiring them. There is; but it requires knowing something about the work. Organizations hiring their first technical writers don't have that expertise; but they need to get it right the first time. So there is a real business problem to be solved.

Many professions use certifications, some with more success than others. I respect people who are certified project management professionals. I know the effort it represents, and I know the range of skills upon which it focuses. I respect people who have been certified as professional engineers; again, I know that the letters "PE" after the name represent a great deal of work and a fair degree of skill.

I'm not nearly as comfortable with teacher certification, because I'm not persuaded that it's meaningful. I've dealt with far too many teachers who could be described at best as mediocre. Go ahead and flame me. In ninth grade I had a science teacher who could not do sums. (Hey, here in Texas we are all about equal opportunity.) Is it possible to create technical writing certifications that are more meaningful than teacher certifications?

To be useful, certification needs to do three things:

• Correctly identify the essential skills of the profession.
• Assign them appropriate importance relative to one another.
• Test them in a valid way.

The sheer diversity of work that comes under the heading of "technical writing" makes it difficult even to identify a core skill set. Is there a meaningful "common denominator" among all the skills represented in our profession?

I was once hired as a technical writer for a job that involved no writing at all. I was to add conditional text tagging to existing material in such a way that the team could produce manuals for new products without changing the text and conditions already in place for existing products. I have had technical writing jobs that included extended periods of creating pictorial instructions only. One might think that any technical writer should have an excellent command of grammar and punctuation; but would it have been meaningful to require proficiency in grammar and punctuation in these situations?

Should we even think of technical writing as a single profession?

Many have suggested specialized certifications to address this. But technology moves quickly, while certifying bodies move slowly. What's going to be the good of having a ten year old certificate in web design? The only solution I can see is to certify people's understanding of concepts rather than implementations. Don't certify people in web design; certify their understanding of usability, searchability, and accessibility. Don't certify people in writing manuals; certify them in organizing information and knowing when to show rather than tell.

That might actually work.