So, you want to be a technical writer

I’ve been working with a client’s employee on some documentation, but the employee has very little technical writing experience. He created a document in Word and manually changed fonts, added spaces, etc. Basically, newbie stuff that’s easy enough to fix. He told me that he’d created hundreds of documents in his career, but no one ever told him to use a template or how to create the documents. So, he made it up as he went along. That’s fine, how was he to know there was a better way?

I enjoy training, so I talked to him about styles, why we use them, etc., and then I showed him how to apply them. Showing him the tech writing ropes has been fun, because he’s excited and positive about learning new things.

He immediately applied what I taught him and was making progress on the document, but then he hit a wall. He was importing images and couldn’t figure out how to use the drawing tools. What he did after this is why he won’t make a great technical writer – he stopped working on the document until someone could tell him what to do.

When I talked to him again, he told me what he was having a problem with.

Me: Did you look in the help?
Him: No.
Me: OK, did you google it?
Him: No, I wanted to ask you about it.

This is a big red flag for me when working with other writers. A good technical writer is curious, diligent in research, and should always always always be the first person to use the product’s help. I wish I could say this incident was rare, but I’ve run into plenty of other writers, usually newer to the technical writing game, who lack the curiosity and problem solving skills needed to be efficient and successful.

That’s not to say that this employee won’t eventually produce decent documentation, the positive attitude and eagerness to learn will go a long way. But without someone to hold his hand and guide him through the process, it will be a long time before he becomes an expert.