WARNING! POTENTIAL DRYNESS ALERT!

BE SURE TO HYDRATE BEFORE READING!

The title of this post hints at a subject that may seem a bit dry and irrelevant to some writers, but there are a lot of technical writers out there facing many of the same struggles all writers face. I’d just like to discuss some differences and commonalities of both forms. So, if you’re interested is seeing how the other half writes, you may want to check it out.

 

Throughout my career I’ve straddled the creative and technical worlds. As a director/animator producing creative television commercials, I had to understanding complex computer graphics technology and software applications. Working at IBM’s T.J. Watson Computer Science Research center back in the early 90s, I worked on projects developing tools for multimedia authoring and video editing and effects. To do my job I had to communicate and function between creative and technical types. My technical writing began at IBM with peer reviewed papers, usually with multiple contributing authors. Some of these had snappy titles such as:

  • The EFX Editing and Effects Environment
  • The Digital Transformation of Hollywood: Format and Resolution Independent Digital Post-Production
  • The Computer Sciences Electronic Magazine: Translating From Paper to Multimedia
  • Visual Simulation for Emergency Response Personnel
  • The Effects of Age, Media Packaging on Designing Training Systems
(I include the official citations below to acknowledge the publications and the contributing authors.)

These may sound like dry titles, but there’s a benefit when you’re the first or only author. You may get to present your paper at a conference somewhere. I’ve been lucky to present in Monterey, CA, Orlando, FL, The Hague, Netherlands, and Berlin, Germany. Here’s the sort of language that earned me a ticket to The Hague:

The nature of emergency response requires the utilization of a rapid decision making process, which is a key component to the success or failure of the incident outcome. Klein et al [1] synthesized a Recognition Primed Decision (RPD) model, which emphasized the use of recognition rather than calculation or analysis for rapid decision making.

My current day job as a Sr. Proposal Manager for an information technology services company keeps me writing material like this all the time:

A scalable and extensible team collaboration platform provides seamless integration of tasks across the software lifecycle.

I’ll tell you, my brain needs to unwind after writing like that, so at night I work on creative writing, such as my blog, speculative fiction, and memoir. That’s when I get to write things like this example from my speculative work:

The Nazran slowly piloted the craft over the ridge lines as they scanned the surface. Standing behind the pilot and the engineer, a tall, slender blue female studied the console. “Dead slow,” Danu ordered.

Here’s an excerpt from a memoir reflecting on the consequences of pulling multiple false fire alarms when I was seven years old:

They finally got me to admit to the crime, but there was still hope for me. I could avoid the terrible punishment that awaited if I answered his question properly. I’d argue that it wasn’t really my fault. The first thing that came to mind flowed right out of my mouth, “A man in a big black cape jumped out of the bushes and said, ‘Pull the alarm or I’ll beat you up!’” I sat back, sure of my story and of my innocence because I the man in the black cape forced me into the crime.

While these examples read quite differently, they’re similar by virtue of communicating information. The technical paper is couched in academic speak, using a formal style and vocabulary intended to impress the peer review committee that your paper explaines something new and important to a particular technical audience. The proposal speak is similar, but the underlying goal is to sell services to a customer—essentially advertising using a formal language and style.

The challenge for the technical writer is to take a potentially dry and otherwise dull subject that he or she has a limited expertise and make it readable. Technical papers are like responding to a prompt, known as a ‘call for papers’ on a particular subject. The only constraints are usually word count and a requirement to cite sources of information you use to support your position—Klein et al [1], above. An interesting rule about technical papers is that you must cite other papers. If you don’t, the review committee automatically rejects your paper. Essentially, no totally original thoughts or concepts are accepted. Nice, huh? Fortunately for the review committees, for any given call for papers, all submissions are generally quite different.

Proposals, while using similar language and style in their construct are much more tightly constrained. The customer, say the US Government, issues a request for proposal—RFP with very specific requirements. Often the RFP comes with a statement of work (SOW)—proposals are full of acronyms, the primary reason being tight page requirements—with a list of tasks you need to address in your response. Each RFP sets tight guidelines for page count, font type and size, margins, and other requirements. If you’re not in compliance with one requirement, the evaluators reject your proposal, and flush all your work down the drain.

Unlike technical papers that are different from each other, each proposal is very much the same, as they all follow the same requirements, answering the same questions. It’s the answers that are different, yet still similar. For some Government RFPs an evaluation team may have to review hundreds of proposals—sometimes fifty or more pages. That’s a job I wouldn’t want. The same basic response over and over again, which is why they’re only too willing to toss out any response that’s not compliant, removing one from the stack they don’t have to read.

Proposal writers must craft a response that’s compliant and readable. Poorly written proposals that make the evaluator stumble over words or try and figure out rambling run-on sentences will not likely make the final cut.

The goal of technical papers and proposals is clear communication of the salient ideas, which means making the content read well. Now here’s a major difference between technical and creative writing. Most technical papers and virtually all proposals are team efforts. There’s no single author creating everything. However, there is a principal author who takes all of the content from other members and creates the single narrative voice.

Arguably the biggest differences with creative writing are the development of plot, character, dialog, and the potential lack of constraints—though memoir imposes some constraints. You won’t find these elements in technical writing. However, narrative is not limited to creative writing alone. Narrative is the intersection between technical and creative writing.

Subject matters experts may provide content and creative writers may invent plot, characters, and dialog, but both forms start someplace and take the reader through a journey to arrive at a conclusion. I suggest that’s what good narrative does. My technical writing benefits from my creative writing experiences with storytelling. I try to apply that process to proposals and technical papers and the effect is a more readable document with the ability to sway the reader to a desired conclusion. Likewise, my technical writing experience with its constraints and rules sharpens my mind to avoid plot holes and paradoxes in my creative work.

In the end, writers write, though we write across a broad spectrum of subjects and styles. I think it’s a good idea not to compartmentalize oneself into a narrow and specific style. I know my work on both sides of the divide—left and right brain—has benefited from crosspollination between the two forms. I encourage other writers to see what they might learn from exploring other domains.

As usual, I’m always curious to know what other writers think and how they go about their personal writing process.

Finally, as stated above, I’m including the details on the technical papers I cited by including complete information (where available) about each of the titles mentioned. Where an electronic link of some sort exists, it’s included. In the case of working with co-authors, after all these years I still want to thank them and say that working collaboratively was a pleasure.

 

The EFX Editing and Effects Environment

IEEE MultiMedia, Volume 3, Number 1, Spring 1996, p15-29

Sherman R. Alpert, Mark Laff, W. Randall Koons, David A. Epstein, Danny Soroker, David C. Morrill, Arthur J. Stein:

http://ieeexplore.ieee.org/document/486701/

The Digital Transformation of Hollywood: Format and Resolution Independent Digital Post-Production

Spring COMPCON 94, Digest of Papers, February 28- March 4, 1994, San Francisco, California, USA. IEEE-CS 1994, ISBN 0-8186-5380-9 p442-444

David A. Epstein, W. Randall Koons:

The Computer Sciences Electronic Magazine: Translating From Paper to Multimedia

CHI ’92 Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, p11-18

Randall Koons, Anne M. O’Dell, Nancy J. Frishberg, Mark R. Laff

http://dl.acm.org/citation.cfm?doid=142750.142752

Visual Simulation for Emergency Response Personnel

Randall Koons, Peter Venturini, Phil M. Wade, Scott Wilson

ITEC 2000 Exhibition and Conference, Netherlands Congress Centre, The Hague, Netherlands

The Effects of Age, Media Packaging on Designing Training Systems

ITSEC, December 2006, Orlando, FL

Randall Koons

http://slideplayer.com/slide/269330