Barry Clegg Goes Head to Head with Information

by Dennis O’Keeffe

As a technical writer, there are times when I think I’m alone. The job of a technical writer must be easier at other companies. I’m sure that other companies are team oriented; engineers and programmers don’t turn and run when they see a technical writer headed their way. Surely they send e-mail to keep technical writers in the loop, or perhaps they invite writers for coffee to explain the latest developments in the project. At other companies, the programmers must send technical writers screen captures with an explanation of their intricate details. And surely, co-workers don’t ask, “What is a technical writer?” or “What do you do, exactly?” My sense of isolation regarding these matters was eased on Tuesday, September 6 when I attended the Southwestern Ontario Chapter’s first general meeting of the season.

The beginning of the end for mediocre

The guest speaker, Barry Clegg, described the problems he encountered at his former workplace. This company had a large body of technical information that wasn’t conveyed clearly to its customers, co-workers, or management. Barry explained that, in its complacency, the company had developed a tolerance for mediocre, outdated, or non-existent technical documentation.

Upon realizing this problem, Barry spoke to his boss and volunteered to hold an information session on the topic of technical writing, called, “Going Head to Head with Information”. This information session was held over the lunch hour and offered tips on documenting technical data. Other offerings included free sandwiches and juice. Is there a better way to lure suspicious or disinterested co-workers into the realm of technical writing?

Defining technical writing and identifying its benefits

During the course of the session, Barry had to explain the purpose of technical writing and why it’s important. “Crikey!” I muttered to myself. Is Barry talking about his workplace experience or mine? How does he explain it? I cocked an attentive ear.

Barry described the process of technical writing as the explanation of difficult or sensitive ideas by using a combination of words, diagrams, and illustrations. He gave a few examples of what good technical documentation can do for a company: reduce maintenance costs; speed up customers’ acceptance of manufactured equipment; and help sales. Conversely, poor technical documentation can: damage sales; increase training costs; increase maintenance costs; and give the company a negative image. This all sounded convincing to me and was somewhat familiar, but how do you make “them” understand? Barry repeated several times that he didn’t work with stupid people; he worked with people who had a tendency to act stupidly. So the challenge was getting his co-workers to convey technical information in a manner that would produce positive results for the company.

Looking for answers in the right places

To do this, he thought the challenge was to have people think “outside the box”; however, with the present state of things he would be happy if his co-workers thought inside the box. For example, one of his co-workers preferred to use pie charts to illustrate complicated data. Barry, however, proved that using simple bar graphs was a much more effective means of expressing the same data. In this case, there was no need for Barry’s co-worker to invent a new method of conveying his data; he merely had to adopt an alternative method that had always been available. Thus, Barry saw no need to re-invent the way his co-workers expressed technical data; instead, they needed to use available methods more succinctly. He explained that simple instructions accompanied by a simple diagram made data more easily understood.

The legacy is clear

Barry ran four information sessions where he distributed technical communication packages, including a condensed copy of technical writing tips. His reward for these efforts was the realization that some of his co-workers became more aware of the job of a technical writer and the need for a clear, concise explanation of technical information. Co-workers began to bring him documents for advice on how to organize them and to clearly explain their technical information. After Barry left the company, the Human Resources department included technical writing sessions in the orientation of new employees. These sessions were based on those formerly presented by Barry.

Possible solutions

As a title, “Going Head to Head with Information” conjures up feelings of conflict; however, Barry explained his true intent: many technical people have difficulty documenting their own projects in a manner that is easily understood. In some cases technical people don’t have strong language and writing skills; and some have no interest in the writing process at all. Moreover, some engineers and programmers believe that no one else can do it for them, because they, themselves, are the subject matter experts. So how is the problem of inadequate or non-existent technical documentation resolved? Encouraging technical people to clearly document their own projects is one solution to the problem. However, Barry presented a second solution.

Barry made it clear to his former boss and to the company’s Human Resources department that there are hundreds of technical writers in every region of the province who can transform technical information into technical manuals. He questioned whether hiring a technical writer could be less expensive than having a technical person design, build, and document a project on his or her own. Barry used spreadsheets of data to investigate this question, and, in the end, he proved to his boss that hiring a full-time technical writer would be more cost effective for the company. Thus, Barry was able to recommend that the Human Resources department hire a technical writer.

Conclusion

Although the title of Barry’s information session may have suggested it, he had no intention of being confrontational or raising the image of conflict in his workplace. In his opinion, the conflict existed between technical information and those who were responsible for organizing and re-writing it. How does one gather it, organize it, and express it clearly? Although I identify with this challenge, I can’t help thinking that perhaps Barry was touching on the other half of the problem: how to extract this information from subject matter experts who are not always willing to share it. These people, themselves, could be seen as the information with which technical writers must go head to head. I thought about this possibility and then asked myself, “So am I really alone, or am I just sore in the head?”

About Dennis O'Keeffe

Dennis O’Keeffe is a technical writer at Automation Tooling Systems (ATS) in Cambridge, Ontario.