Technical Writer

Over at I’d Rather Be Writing, Tom Johnson asks STC candidates to submit a story about a defining moment in their career.  I am not a candidate (or even a member) of the STC*, but like many of us, I do have a defining moment that has shaped my career as a technical writer.

It was my first technical writing job.

It was a big project.  We had a team of 15 writers. The team leader was very particular about grammar and punctuation, and he was an excellent proof-reader. As the greenest writer on the team he took special care to ensure I was up to standard. From a writing point-of-view it was probably the most polished documentation I have ever produced in my working life.

We were proud of what we had produced.

Until we presented it to the trainers who were to teach it to the call centre staff who had to use the new system. 

“But that’s not how the operators do it,” the trainers said.  “They take the call first and then …”

We had built our whole training around the system specs, not on the operator’s procedures.  (I haven’t come across this recently, thank goodness. It’s one thing we seem to have learned in the last ten years, that we should write around the user, not the system, but it was prevalent back then.)

Worse, our team leader took it as a personal attack. 

These people had a genuine issue.  It wasn’t with the writing, it was with the fact that what was written did not fit with their current policies and processes.  (We weren’t changing these, just changing how they carried them out on the screen.)  But our team leader treated it as if they were criticising the writing.  (Think of the most precious writer you know, someone who refuses to change even a word because his writing is perfect as it is, and you get the idea.) 

He started to defend himself.  Then he got vitriolic.  He claimed the trainers had no idea; he told them that if they couldn’t train the new system that wasn’t his problem.

It was a fiery session and I have to say that the trainers came out of it far more graciously than the tech writers did.

I still remember that meeting, and I still use it as the basis for everything I do in technical writing.  In particular:

• Always start with the user, not with the system.  As I said above, most of us seem to have learned that lesson now, but it’s a pretty important thing to remember

and

• Don’t take criticism of your writing personally.  People are commenting on the content, not on your writing. In all my years of technical writing no-one has ever used my writing to attack me.
• Listen to that feedback. People are saying important things about the content. Don’t let your ego get in the way.

Good lessons learned.

 

 

* The Australian equivalent is the Australian Society for Technical Communication—try http://www.astcstate.org.au/ where state is your three letter state abbreviation.

Last Modified : April 7th, 2007
Filed under : Tech Writer
Navigate : Previous post / Next post