Writers of technical documents and proposals need to make every word count.
Readers, proposal reviewers, and editors do not care to read through a rambling dissertation; nor do internal review personnel. How do we squeeze reviewer-friendly and internal-compliant responses into severely limited space? Based on my experience as a (co)author for a variety of proposals –large & small, contractor & academic, winning & losing- here are ten simple tips to keep technical text succinct and on-point.
(1) Technical writers need to attack redundant phrasing. For example,
Our Team is actively engaged with clients…
This does beg the question what inactive engagement might be. Note that this snippet also ‘deverbifies’ an activity: it replaces a perfectly lovely, active verb with something far more cumbersome. Consider replacing the above snippet with:
Our Team engages with clients…
(2) Related to (1), certain word combinations are so oft repeated as to lose impact or even signal weakness. For example, “deeply involved” …as opposed to shallowly? Phrases like this may work in some contexts, but they usually signal inability to detail involvement or experience in a meaningful way.
(3) De-gerundify your text. Gerunds are the bane of my technical writing existence. They add length and also deny an opportunity to wield an active verb. For example:
We are capable of researching, developing, testing and evaluating…
This could be, simply:
We can research, develop, test and evaluate…
But… caution: the verb “can” implies weakness and perhaps even lack of prior activity, so it might be better to say:
We research, develop, test and evaluate…
This is the most active form: it says that we actually do something. Now. This gives a space savings of about 40%... and is stylistically better, too, in many circumstances!
(4) Repeating repeated phrases is repetitious and repetitive! A common occurrence in multi-section technical/proposal writing is repetition of key messages, e.g. “We are the best team to accomplish this task.” Typically, writers repeat phrases like this to emphasize a point and/or ensure that a reader doesn’t miss it. But repetition often dilutes the message.
(5) Bold it… and then ask why the other stuff is there! A few years ago, a colleague desperate to compress eight pages to two asked for help. I requested that he simply bold the most important items… items that I shouldn’t touch. He did that, and I then returned the document, containing only those bolded statements. Okay, I admit… this was a snarky response; but the point is that if something isn’t important, then why is it there at all? We need to prioritize and let the main points stand out.
(5b) Boldface font is such a powerful tool that I try to use it no more than ~once or at most twice in a paragraph, or no more than a few times o a page. Bolding too much text decreases its impact. The same goes for many other tools we use for impact, e.g. italics, color changes, etc. Use special formatting very sparingly.
(6) De-synonymize those rambling word lists! There are many words in technical writing that mean basically the same thing, in most contexts. For example:
Research, investigate, explore, examine, probe, etc.
…and yet I see lists of these words in the same sentence or paragraph! The writer probably wants to underscore the activity, but what (s)he actually does, instead, is add so many words that a busy reader will simply skip the whole mess. Who would blame them?
(7) Use “search & replace” to introduce space-saving acronyms on first use, and also to tackle repeated phrases. A recent proposal contained the phrase “The XXX Team” approximately one hundred times. Searching and replacing most of those with “The Team” or simply “We” (plus a minor subsequent verb change) saved a lot of space!
(8) Tables can save space…if assembled correctly. One trick is to take narrative text at 12-point font and compress it into a table at 10-point font. This saves space and also brings joy to compliance reviewers. And note: tables seldom require narrative style or formal grammar, e.g. subordinating conjunctions, complete sentences, or even verbs. Tables can often be shortened substantially, with this in mind.
(9) Tackling length is particularly difficult now that many writers have different versions of MS Word, which is inherently horrendous for reliable pagination. To make matters worse, many clients or agencies now ask for documents in doc/docx form; PDFs are usually more reliable. We have to take each and every document and run it through specified reading software and ensure proper pagination.
(10) Take the time to do some math to figure out how much work is needed for a particular compression. For example, if you need to compress a 17 page document to 15, this implies shedding 2 pages or ~2x46=92 lines, or ~5 lines per page. That is helpful to know: attention to paragraph breaks, table padding, figure sizes, captions and similar items can usually make that much quite easy. If you need to eliminate ten lines per page, that probably requires a thorough grammatical and stylistic attack. To eliminate half a page from every page (yes it happens!) will probably require expert knowledge of content.
In addition to these grammatical, stylistic, and formatting issues, echo-chambering is a significant problem for proposal teams. Societies of mutual resume admirers seldom provide honest feedback. If you can place a neutral pair of eyes on a difficult chunk of text, that person might be willing to fish out a few points that came across- very useful feedback. If a neutral but knowledgeable reader cannot immediately discern wheat from chaff, then you want to know that… ASAP. For this reason, I consider it worthwhile to ask technical contributors to bullet main points and prioritize them, before trying to form complete sentences or paragraphs. It takes me much longer to “fix” text than to build it from clear bullets.
I hope that this helps other technical writers… and doesn’t seem too much like a college writing lecture. Feel free to contribute your own tips and anecdotes!
This article was originally posted by Keith Williams on LinkedIn on July 24, 2015.