Thinking about writers

Being a good tech writer requires a lot of smarts and a lot of finesse. It's not just about knowing the authoring tools, learning the product, and knowing how to write.

It's understanding users, corporate priorities and the market.

It's learning which SMEs you can trust and which require double checking. It's learning how to motivate SMEs to help. It's learning how to work within other people's busy deadlines, to know when to push and when to hold back.

It's having the humility to accept other people's edits and the chutzpah to refuse other people's edits. It's having the tenacity to keep plugging away at something till you get it right, even though that process spans releases.

At your average tech writing job, it takes two years to become an expert in the product and customer base, form the necessary relationships, and learn the doc set. It is therefore important for companies to retain tech writers and to nurture them. Nurturing them means training, but it also means helping writers become more comfortable with responsibility - with honing and trusting their instincts.

All the supervision, editing and approval processes in the world won't make up for low quality writing. Unfortunately, all too often what holds writers back is all the supervision, editing and approval processes.

Writers have to "own" their areas of responsibility. Some writers won't do as good a job as others, but with time, training and nurturing, they'll get better. If possible, writers should see direct user feedback on their writing. Writers need to learn to have the reader perspective sitting in the back of their mind at all times. Every decision on terminology, wording, which information to include, topic length, and every other little thing should be made while thinking about the reader.

Some DITA CMSs include workflows that take doc ownership away from writers. I once had an editor who told me that our workflow was like a relay race - I as writer had prepared the first draft but then must pass the baton on to others. The editor didn't know anything about my users, the product or the market, and some of her edits created inaccuracies, but I had to fight for control of my content. That's the wrong way to operate.

Editors and information architects should not take responsibility away from writers. They can set guidelines and they can provide consulting services, but a writer has to be the expert in their own area. Otherwise it's just garbage in, garbage out.

Wait, you may say, what about hardware reference documentation that's essentially a list of specs? Well okay, there's an extreme end of publications that isn't really writing at all. But with tech writing, no matter how structured topics are or how complex a CMS is, at one end you have a writer and at the other end you have a reader. All the rest is secondary.