What it means to be a technical communicator

Posted 22 February 2011 by
Bob Chapman

Bob Chapman

The following is a polished version of a post I made in a group discussion on LinkedIn. In this case, a person who was about to graduate with an English degree was wondering about finding a position in technical writing.

The tool discussions you see on this thread are important for professionals currently practicing the trade. When I started writing 20 years ago, I wrote print documents that were meant for long-term storage. Today, I edit screen copy that becomes outdated at the next software release. My toolset has evolved over this time. The essential nature of what I do has not changed.

You are asking about entering the field of technical writing. Why do you want to be a technical writer? Are you trying to find a job? Are you thinking about a career?

It is fine if you are not sure of your answer. I worked in many professions since college graduation. New jobs and opportunities open. Old jobs and opportunities close. Sometimes you do not know what you to do until you have dabbled around. I know that would never had dreamed of doing what I am doing right now while sitting in a college classroom.

The essential nature of what I do is to communicate (not tell) technical information to an audience that includes technical and non-technical people—sometimes at the same time. My desire, my lust is to communicate this information in the cleanest and sharpest manner possible.

Some definitions of technical writing are true, even when humorous.

You may decide to give technical communications a go after graduation. Whether or not you stay in this field depends on whether you discover how much you lust after manipulating written and visual communication to an audience that does not care to read your every word. Your audience only wants to do something. Your words are the path to that goal.

Your greatest compliment lies in how little people notice your work. When this happens, support costs go down and people make good decisions. This is true whether your product is an electronic defibrillator or a SQL database application.

Sometimes your work is not where you expect it to be. Helping to design a web page user interface for a product to make it clearer and self-intuitive is as much technical communication as preparing the white paper describing the need for that product to potential customers. Depending on company size, you probably will not write the user interface and the white paper for the same project—although there are exceptions to this.

Your profession is conveying technical information. Yet, you have a concern for marketing. Sometimes you have to think like a Mad Man when all you want to do is explain the widget.

Visual communication is as important as the words you use. You have to have good presentation and layout before anyone will read your good words.

Sometimes you have technical illustrators to create the pretty diagrams and pictures. Most of the time, I need to create my own. Even when you have the help, you will want to have some control over the diagrams used to illustrate your text. After it, this project is your baby.

Sometimes you feel pride in what you do. One of those things for me was some involvement in the Boeing 777 development program. As a contractor, I did many things “inside the gate” at Boeing.

In 1990, I wrote the first planning documents in the 777 program for performing manual and automated system functional tests on the aircraft. In many ways, these documents were only wish lists by engineers dreaming about the future. As such, these documents required later revision by others, but I was Number One.

Later, I prepared several types of documentation for the online rejection tag system Boeing implemented with the 777 program. INCA (Integrated Non-Conformance Analysis) replaced the need to transfer handwritten information to electronic format for database entry.

The first All Nippon Airways 747-400D, Yuki's Whale

The first All Nippon Airways 747-400D, Yuki's Whale

For a while, I assisted engineers from All Nippon Airways, one of the partner airlines involved with the launch of the 777, through Boeing Customer Services. On this assignment, my workday started over at 4:00 pm when the telephone calls started from Japan. One perk with this assignment was the front row seat when the first ANA 747-400D exited the paint shed at the Everett plant—the “Marine Jumbo” or “Yuki’s Whale.”

Later, I worked in Planning at the former Kenworth truck plant that was in Tukwilla, Washington. It was across the street from what is commonly called “Boeing Field.” One day I heard the then-unusual higher pitched whine of a 777 taking off on a test flight. My attention was drawn immediately out the window—and away from my site manager who was talking to me—to watch it take off. I apologized, briefly explaining the minor bit parts I had in that plane, and said, “There is a little bit of me in that plane.”

In 2005, I did the instructional design and production of the web-based training for the Boeing modifications to SLATE, the online systems requirements database used for the 787 program. My title was “technical writer.” I feel a similar pride when I see a 787 plane at Paine Field not far from where I live in Everett.

There is one way to sum this up. I cherish the comments from a project manager that once said about a help system I created, “This is the first time I’ve seen a help system actually say something.”

Post Details

Leave a Reply

Page optimized by WP Minify WordPress Plugin