Technical Writing/Editing: Pain or Pleasure

I have noticed a few things about technical writing in Saskatoon, and Saskatchewan in general.
First, there aren’t very many of us in Saskatoon…especially not freelancers or tech writing companies…compared with Calgary, for example.
Second, most people still think a technical writer writes about “technical stuff”–electronics, software, IT, mechanical, etc., which is only partly true, some of the time.
Third, most people here don’t think of writing as something you would contract out. Usually they either have the “anyone can write” perspective, or they look at it as a necessary evil and do as little of it as possible.
I’m trying to change that, to show businesses that there is value and ROI in getting a professional to write their user manuals, policies, procedures, case studies, white papers, etc.
I’d be interested in hearing your thoughts on this.

Need a writer? Or do you just need some help?

Someone said “There’s no such thing as writing…just re-writing” and as time goes on I’m realizing this is true in several ways. I was reminded of this while talking to people at a trade show I recently attended. I engaged several people from various booths in conversation and mentioned that I “write” manuals, procedures, training materials, and other documents. As usual, the response was, “We write our own manuals.”

What can I say to that? You shouldn’t! You should let me do it! I’m a professional! I also can’t really tell them their writing isn’t good enough. At that point for all I know they may be very effective communicators. Obviously these wouldn’t be the most effective marketing techniques.

But experience has shown me that most small to medium sized companies who do their own technical writing are not entirely happy with their results. Usually they know their documentation needs improvement but several factors are holding them back from getting what they need. First, they don’t know where to find someone who they are confident can help. Second, they are not sure whether the price they will pay will be worth the benefits of better documentation.

So I have realized that often what the client needs is not a technical writer, but a technical re-writer. Other ways to describe it is editor or documentation consultant–someone who can meet them at the point where they need help, and can provide cost-effective recommendations and assistance. The client knows the content they want in the documents, and they often have good ideas about how it can be best organized for their customers. I know how to organize, present and clarify information so it has the effect the client wants.

As for the cost of my services? Usually, the savings realized from reduced product support (telephone, in-house and field service) and decreased product returns pays for my fees in the first few months after completion of the document upgrades.

“Do I really need a tech writer?”

Well…no, actually.  But do you really want to do this nasty job yourself?

I’ve lost count of the number of people to whom I have offered my technical writing services, who look at me like I must be crazy. After all, they have smart people working for them…people who understand the content that needs to be written, who have great computer skills, who know how to write a sentence. Why would they pay someone from the outside to do what they could do themselves?

The only honest response I have come up with is: “Great! Enjoy the experience.” The truth is, these organizations probably do have people with skills, and with some effort they could probably turn out a  manual, procedure, or other document. However, further down the road they may wish they had brought in an expert.

Writing a manual or procedure is not simply the process of putting a series of steps into words. And a tech writer is not simply a person who writes sentences. Typically, a capable and experienced “technical communicator” (the correct description of the role) performs most of the following tasks in the process of producing documentation:  assesses the clients documentation needs, analyzes the content/tasks/etc to be documented, determines the scope of the project (especially if multiple documents are involved), gathers resources, identifies subject matter experts (SME), designs the document format and style, does research, writes the content, works with SMEs to verify and edit one or more drafts, publishes a final draft, maintains records, files, style guides, document plans, and many more aspects of the project. Throughout this process the technical communicator often assumes the role of project manager/leader and, if the project is large, may manage several personnel with specialized skills (illustrators, photographers, IT support, etc). If the project is smaller, most of these tasks still have to be handled at some level, and the person handling them needs to know how not to get bogged down in them.

So if you have someone who can handle these tasks, and you are willing to free the person up to become your in-house technical writer…good for you. But don’t expect that person to manage a documentation project AND do the job they were doing before. Something will break, and chances are you won’t end up with documentation at the level of quality that you had hoped for.

Tech Writing for Process Industries

This being the first post on a new website/blog, I’m putting out an open invitation for responses from other tech writers–especially those who work in process industries. Writing is a lonely business at the best of times, but so far I haven’t met many writers who serve process industries. Anyone out there who would care to share their experiences?