Technical writing – a report from the coalface

Written by: Hans van Bemmelen
Published: 2-04-2024

Every technical writer probably has a different idea of what the discipline amounts to. In this piece, I will describe my personal approach – undoubtedly yours will be different.

What is technical writing?

In a way, all my work is technical writing as I do not do any general writing for consumers or journalistic pieces. Quite a lot of it is on the borderline of technical writing and copywriting: press releases and articles for corporate magazines about technical products such as specialist vehicles. I would still classify that as technical writing because both the people who provide me with input (usually design engineers) and those who read my output (fleet managers, engineers, etc.) tend to have an engineering background. They (and I) have another thing in common: a dislike of marketing waffle. Purely technical recent work has included installation and operating manuals for heavy lifting equipment in power stations. Currently I am working on a long-term project to create training materials for Self-Propelled Modular Transporter (SPMT) operators. I am also assisting with a new version of the industry guideline for this equipment.

Is it any different from normal writing?

In my view, there is little difference between normal and technical writing. Both call for a thorough understanding of the subject we need to communicate and an appreciation of the intended readers. The key difference is that if you have to interview technical people to get input, it really helps to have a fairly good understanding of the subject – engineers can be rather judgmental if they think you haven't done your homework. However, once you have gained their confidence they are usually happy to tell you everything about their work, and appreciate an attentive listener. Once you have built up a good rapport, they appreciate that you are there to help get the product they have developed into the customer's factory and ensure that it is working correctly.

Research

For me, doing my homework mostly means reading books to give me a good understanding of the basics of the subject, and then reading up about the latest developments on the internet. Textbooks aimed at technicians rather than engineers can be particularly informative as they often provide more technical detail than academic books. There are areas, such as heavy lifting and industrial cleaning, where few books are available. In those cases, you have to rely more on manufacturers' publications and occasionally on conference presentations. Having a good understanding of the subject helps me ask the right questions to obtain the input I need for writing the marketing materials or technical documentation.

A few years ago I was working on some documents about gas turbines for aircraft. There was no opportunity for a site visit but I really wanted to get closer to the equipment. In the end, I managed to get a turbine blade from an online supplier, and it was really nice to literally get my hands on one of the components I was writing about. 

Interviews

The aspect of my work I enjoy most is going onsite to interview engineers and technicians about their work and the products. I usually prepare for that by setting up a document with a two-column table, with my questions in the first column. On site, I then type their replies into the second column. I do record the interviews and log the sound file numbers in the second column for quick reference. However, I try to rely on my notes as reviewing the recordings tends to be quite time-consuming. Most of the time I write my notes and the replies in English, even when interviewing people in Dutch, but I realize that that would not work for everyone. A laptop is less convenient during interviews in a workshop or the yard so in that case I rely on the recording or handwritten notes.

Many years ago, I decided to invest in a proper sound recorder and microphones. I find this kit easier to work with than small consumer-grade recorders. Surprisingly, the interviewees often ask questions about it and recognize it as solid equipment – much like what they build. So that helps break the ice.

For some projects, I also take photographs or short videos. I am by no means an ace at that, but it saves briefing a photographer, and knowing what is going to be covered in the article or manual makes it easier to shoot the right subjects. However, I insist on having a short break between the interviews and photography, to give my brain time to change over and to refine the shot list.

Writing

If I have done my research well and conducted the interviews effectively then the writing should be straightforward. The main issue I have come across is that sometimes the briefing, especially if done by a website or marketing agency, does not quite tie in with the content to be created. In those cases there is a need for some diplomacy (not my strongest point) when discussing how they could change the design to fit the new content.

Reviewing: bigger is better

Once I have written the first draft of an article, I send that to the client or interviewee for comments. If it is a straightforward article, then I will ask them to use Track Changes. However, not everybody is familiar with that, and it can get very confusing if there are comments from multiple reviewers. For some projects, I put all the content in the first column of a table, my queries in the second column, and then add a column for each reviewer to contribute their comments. That can give a clearer overview. Sometimes I print that table on A3 or larger paper (my plan printer goes up to A1, but Word does not like that) so we can scribble on it during an in-person meeting. Undoubtedly some will consider that a quaint, archaic approach, but it often works for my clients and me. More diplomacy is then needed to combine all the comments and incorporate them in the final document.

Been doing it for decades, still enjoying it

Having started my career as a technical translator, I slowly pivoted towards writing both marketing materials for technical products and purely technical writing. A few decades of reading the source texts for my translations has taught me quite a lot about writing, which I can now put into practice. Writing gets me more involved with projects, and has not suffered from the rate erosion in the world of translation. But translating is more straightforward and can make me feel more productive. So my writing and translating complement each other very well. After a few decades in the industry, on the whole I am still enjoying the work and getting close to a wide range of technical products and people.