Published on March 4, 2019

One of the most frequent things we hear from audiences – both of reports and presentations – who fail to engage with and understand the content being communicated is: “What’s the story?” It may seem like an odd request, since engineering communication may not seem to have a narrative arc. We’re not working in fiction, after all. Yet engineering work can indeed have “stories,” many of which are simply versions of a conventional narrative structure. In this post, you’ll see how appealing to some of these conventions can help engage an audience, structure your communication, and help the audience understand the purpose and meaning of your reports and presentations.

In communicating, engineers and scientists often focus on the methods, evidence or data backing some form of argument – the objective facts that can be marshalled in defence of a certain claim, such as why one engineering decision is better than another. This focus is drilled into engineers as part of the scientific method, in which developing a hypothesis, methods to test that hypothesis, and data to support or refute that hypothesis are the key elements. But when moving away from purely technical audiences and to engineering managers and even the general public, we tend lose track of the contextual elements behind that process, losing track of the whole story in presenting “just the facts.”

In this context, it helps to understand the scientific method and engineering practices as themselves a form of narrative – specifically fitting into the genre of quest with the scientist as hero. While engineers won’t expect to find the holy grail, defeat Sauron and his forces, or rescue their beloved from a tower, understanding your work within the context of this genre can help us to build engagement and understanding with audiences. More specifically, there are a few important conventions within the quest narrative structure that can help us tell our stories better:

First, there must a “quester” or protagonist. Often in engineering communication, however, this actor is obscured by objective, passive language. Passive voice is the to be + verb form – “the test tube samples were visually examined to determine” – instead of the active – “I visually examined the test tubes to determine their level of contamination”). While the passive remains a convention in scientific writing, it distances the audience from the actors and the action being described, and can alienate readers and listeners. At minimum, this should remind us that audiences connect more strongly to people and not to obscure the actors in the engineering activity. 

Second, there must be a reason for the quest to occur, and this is important, often missing context from engineering communication: “what is the problem that needs to be overcome,” and “how did it come about” are essential elements in creating engagement. This background needs to be developed in a manner that convinces the audience of its import or significance; otherwise the audience is lost at the outset. A hypothesis may function independently in scientific writing, but answering key questions – like “why is that hypothesis important” or “where did it come from” – can help to convince readers of the importance of the topic. Providing enough context to properly motivate your quest and explain the challenge is essential to developing the narrative behind your work.  

Third, a quest is supposed to consist of trials and tribulations, a series of actions and reactions, that may help solve the problem, create new ones, or provide reasons for more actions. What are the various methods we undertake or propose to solve a problem but “trials and tribulations”? And if we think about engineering methods and results in this way, we can frame our communication in much terms of a narrative that progresses towards a solution or an answer. In an engineering report, for example, a first set of methods may not give us the data we need to prove a hypothesis, but the results will answer some questions, and provide direction for future actions to address the original question or problem. As a reminder to foreground the action, outcomes, and reactions, an awareness of the quest narrative can really help to maintain the focus on the “story.”

 

Finally, the quest concludes with reflection, which produces a change in the original circumstances. The protagonist is changed by the experience, insofar as their journey has shaped their knowledge and awareness. In engineering, the narrative should similarly be rounded out by reflection on the original situation that motivated or necessitated the engineering work, and placed in the context of the original problem or question. This reflection often involves the necessary, explicit articulation of the meaning of the results, and wraps up our engineering stories. 

While we don’t expect narrative to the be dominant mode within engineering communication, knowing and telling the “story” is behind that work is very important. And thinking about engineering stories as a quest appeals to known conventions; in doing so, it can help to produce more engaging, direct, and clear communication, for both technical and non-technical audiences.