English Technical Editing

A White Paper Worth Writing

What if your company developed a tool that could save your customers $100,000? As a technical communicator, would you be interested in writing a white paper about it?

My immediate answer was something along the lines of, “You betcha!” Working for a government contractor, I don’t always write about attention-grabbing subjects with big, financially impressive outcomes. Lots of what I cover is dry and highly technical, which isn’t always fun to write about.

That’s why I was excited about this assignment—and why I chose it for my Project 3 topic in EH 603. So, let’s talk details.

A Compelling Narrative

I quickly learned in my research that a tool doesn’t mean a hammer in this context.

In my day job, I write all kinds of materials for a government contractor that specializes in designing, manufacturing and supporting electrical systems for a variety of applications. For the purposes of this post, I’ll focus on the “supporting” aspect of the business, which is known in-house as Depot & Test Services. Recently, a customer approached my company with a problem: For more than a year, the customer had been unable to determine a root cause for unit failures as recurring storage and sustainment costs continued to eat into the bottom line. My company solved the problem in less than a month and saved the customer more than $100,000.


The secret? A suite of modular testing tools my company has been developing for more than a year.

It’s a great story—exactly the sort of narrative companies love to tell about themselves. The only problem is that the story doesn’t exist. Yet. And that’s where I come in.


Researching the Story

To tell this story the right way, I’ll have to do my research. For that part of the project, I’m planning to use two main sources. The first is the existing documentation, which is turning out to be much more promising than I expected (with one caveat). Of the 15 modular tools in the collection, project engineers have written data sheets for 12 of them. Plus, they have another data sheet for the base that holds the tools (a pre-manufactured cage).

The data sheets I’m using to research this topic include lots of wiring diagrams that look something like this one. Note: This isn’t an actual diagram from one of the data sheets.

So far, these have been an excellent resource. As a non-engineer, I can barely tell one end of a microchip from another without help. Documentation like this points me in the right direction, and I fully appreciate that. On the other hand, what’s less excellent about the data sheets is the fact that all of them were written in engineer-speak. Here’s one of the better examples of the lexical carnage I’m dealing with: “The M___ Card is a card designed to go in the standard platform card cage designed to interface with the standardized M___ input connectors.” (Say what?) So while the data sheets have plenty of value, they have their limitations. But despite needing to translate all the documents into standard English, I’m finding them invaluable as a source of raw information.


Which brings me to my second source—a pair of in-house Subject Matter Experts. I’ve already spoken with the SMEs by email and in person, and they’ve helped translate jargon and fill in some of the gaps in the documentation. They’ve also explained how some of the trickier technical concepts apply to the design. One big thing I learned? A tool isn’t a tool in the sense of a hammer. It’s an electrical circuit card that plugs into a backplane.

Of course, talking to SMEs isn’t always easy. (Have you ever tried to convince an engineer to explain multiplexing in non-technical terms? You should give it a shot sometime.) But I believe I’m gathering the most important information from our discussions. 

Once I finish the research, it will be time to write. And for me, that’s the fun part.

After all, the material isn’t even (all that) dry this time.