Writing For Engineers & Other Techies

A while back, Michael Stelzner started a discussion about writing for engineers and other technical types (in particular, writing white papers for them). It was a subject near and dear to my heart because this is one of my favorite audiences to write for. Why? Because when you write for them, you write in a No B.S. Zone. No spin, no fluff allowed.

I posted some observations in his comments section, then realized that the list was much much longer. In pulling together the list of observations about how this audience looks at text, I realized again that some of them defy the stereotypes about techies — especially the ones that say techies can’t write. While there are some out there who, by their own admission, aren’t the strongest writers in the world (and I’ve worked with a few of them), I’ve worked with far more who write either moderately well or very well.

Much of this list applies to writing for any audience. The difference is that while other audiences might gloss over things and keep reading or consciously give authors the benefit of the doubt, techies can get fairly hung up on details.

• You have to know your subject or you’ll lose them. Engineers, programmers, and scientists can smell a faker a mile off.
• Credibility is also assessed by the details of your work, including the subtle things that can make your work look polished…or not so polished.
• You need a *short* lead-in, not a slow wind-up. Include a backstory if it’s needed, but get through it and to your point quickly.
• Write a solid conclusion that ties everything together and doesn’t bring up any new points. Yes, this is Conclusion Writing 101, but I’m not exaggerating when I say I’ve seen techies dismiss an entire document because of a badly written concluding paragraph or section.
• Use a minimum of adjectives (especially the “fluffy” ones) that aren’t part of their jargon.
• Be mindful of words and phrases that beg for or a demand a comparison or a qualification. If you find them, either finish the comparison or re-cast the sentence. Saying that something is better, faster, more efficient, more reliable, and so on without answering the question “…than what?” causes these readers to get overly hung up on your copy.
• Be consistent on the details. They notice, more than prevailing stereotypes would suggest, things like: punctuation at the end of bullet list items; conventions for figure and table titles (e.g., “Table 1: Process Flow” vs. “Table 1. Process Flow” vs. “Table 1 — Process Flow”); lack of parallelism in lists; misspellings. They may not always know what exactly isn’t right, but they will notice that something isn’t right.
• Be consistent on the design. They notice inconsistencies in font, line spacing, colors and shades within color families, design of running headers and footers (especially when there’s differences between even and odd pages), spacing between text and graphics. They may not always know what exactly isn’t right, but they will notice that something isn’t right.
• Check any and all math and equations, then check it again. If you’re weak on the math front, find someone who’s strong in math and have them double-check calculations.
• Check all facts, no matter how sure of them you think you are. This includes things such as software versions, product names, service patch numbers and release dates, names and revision dates of industry standards (e.g., IEEE), network protocols, and so on. They will know precisely what’s wrong.

In my next posting, I’ll look at creating graphics for this audience.