Editor’s Note: The following piece by David Stewart is part of our collection of “classics”–articles that stand the test of time no matter how many technologies come and go.
Imagine the perfect technical writing experience. Engineers gladly line up at your door to explain how the product works. You enjoy ample time to finish the tasks on your documentation plan. Your manager gives you free rein to work at your own pace. Your customers rejoice at the usefulness of your document.
A fairy tale? Perhaps. As a fledgling writer, though, that idyllic picture is my goal. To achieve even part of that goal, I’ve discovered a need to develop new work habits, behaviors, and processes. In addition to seeking the help of mentors within the technical writing community, my strategy involves looking to other functional areas within my company and learning from the approaches they use on their own tasks. I believe people new to the technical communication industry, as well as those who have toiled in the field for decades, can benefit from the examples of other functional areas.
Why do I think we can learn from other departments? After I made a career transition into technical communication, I quickly realized that technical writers don’t hold a monopoly on great ideas. My degrees are in electrical engineering and human resource management. Before becoming a technical writer, I worked as a software project manager for a telecommunications company and collaborated closely with manufacturing teams. I spent the previous six years as a trainer with the U.S. Air Force. My experiences exposed me to many effective techniques for accomplishing the job and many approaches that were less than successful. Each department has its own processes to share and lessons to impart. Armed with this thesis, I developed a personal set of basic guidelines and habits that I learned over the years from each functional area.
The Training Lessons: Know Your Topic and Product; Deliver Targeted Information Efficiently
In the U.S. Air Force, I spent years training fighter pilots how to avoid getting shot out of the sky by surface-to-air missiles. Like technical writing, training demands a thorough audience analysis. What kinds of information would be useful to you in doing this job? First, you would be expected to know the intricacies of jet aircraft as well as, or better than, the pilots do. You will have spent a great deal of time studying aerodynamic maneuvers and making yourself an expert on the handling characteristics of the jets. In addition to aircraft fundamentals, you would need to become familiar with a variety of missiles from several countries, focusing on their launch profiles and ranges.
The lesson I learned: Know your topic and product. My job was to present information and ensure the pilots understood it the first time. There is no customer support hotline to call when you’re flying at 20,000 feet and over 450 knots, trying to avoid a deadly missile. I strive to make my documentation as clear and understandable as the Air Force training sessions.
A related lesson I learned from Training is to deliver information efficiently and effectively. A hundred concerns, from weapons loading to parachute packing, vie for a pilot’s attention. If you simply show them a series of stale PowerPoint presentations, what kind of reception would you expect? You’d likely be met by a room full of underwhelmed pilots with glazed looks in their eyes. Rather than adopting such an approach, I wrote crucial data directly onto an overhead projector transparency. I quickly summarized my main points and transitioned straight to a question-and-answer session. I covered only the details absolutely necessary for the pilots to know. Similarly, as a technical writer I evaluate the delivery methods of my documentation (e.g., HTML, hardcopy, or PDF) and determine whether they suit my audience. The length of my manuals, and the depth of detail, likewise hinge on the needs of my customers.
The Project Management Lesson: Develop Realistic Schedules
As a software project manager, your greatest challenge is ensuring that software is developed by your team and shipped on schedule. Each functional area, from Training to Manufacturing to Tech Pubs, has a timeline to follow and deliverables to provide. You quickly learn to appreciate the teamwork needed to produce a successful product on time. No functional area works in a vacuum. Each is dependent to varying degrees on others to get the job done.
The lesson I learned: Develop realistic schedules. As a technical writer, I am routinely asked to build documentation plans for each of my manuals with oftentimes incomplete information. Deciding what to include and what to omit when developing a document draws on my project management background. As a project manager, I evaluated the tasks that my team could realistically achieve during the project and eliminated those we could not incorporate while still meeting our deadline. Sometimes I would prefer to completely revise the style of an existing document, but know I won’t have time if I want to fully cover the product’s new features.
The Human Resource Management Lesson: Partner in Change Efforts
Most employees have little contact with Human Resources (HR) aside from setting up pay records and coordinating performance appraisals, but HR encompasses much more. In an HR degree program, you study the fields of Organization Development (OD) and Organizational Behavior (OB). Organization Development analyzes ways of systematically implementing change within organizations, while much of organizational behavior deals with human interaction and the things that motivate people.
The lesson I learned: Actively participate as a partner in change efforts, and don’t just react each time something new occurs. Each week, my publications group is faced with an array of changes ranging from minor FrameMaker template updates to major managerial restructurings. OD and OB help me survive such changes with my sanity somewhat intact. I can suggest methods for implementing change so it occurs with buy-in from the people affected and with a minimum of disruption. The manner in which we react to difficult situations is completely up to each individual.
The Engineering Lesson: Keep up with Technology Changes
Completing an engineering degree and working with engineers in a variety of jobs impress on you the need to be technically accurate. My publication group’s primary concern is guaranteeing the accuracy of our documents. Nothing erodes a customer’s confidence in a manual, and sometimes the product itself, more than a document containing mistakes in content. My software engineering colleagues are expected to produce source code that is technically accurate, and the content of our user guides should be held to the same standard.
The lesson I learned: Keep up with changes in technology. We’ve all collaborated with many functional areas over the years. In my view, Engineering is consistently the department that stresses continuous education the most. Maintaining proficiency with technological advancements will help you not only understand the product you’re documenting, but also assist you to identify other fields you might want to experience in the future.
The Bottom Line: Talk with Other Functional Areas
The list I developed is not exhaustive, but it reflects my experiences while working with other functional areas. Do you work with folks in other departments I haven’t mentioned? Great! Talk with them. If you read my list and observe that other areas share some of the same hurdles as Tech Pubs, you’re right. Once you discover that fact, you can begin mining a valuable repository of solutions to your technical writing challenges.
