More than a few years ago, bordering on the “many”, I was invited to take part in a graduate selection weekend for Ford in the UK. It was a battery of tests ranging from one-on-one interviews and team-working simulations to presentations and problem-solving “incidents” – all nicely wrapped up in dinners and coffees in a pleasant hotel in the countryside.

One of the tasks – maybe there were twelve of them, I didn’t count – was to decide what equipment should be offered as optional, standard or not at all for a sporty Ford Escort model (these were the pre-Focus days), to meet a budget. We then had to write a report explaining our choices, needing to meet a most important deadline (lunch).

Being a bit of a car enthusiast, I made what I thought was a decent selection (including ABS and airbags as standard equipment), whilst keeping some budget for a few luxuries as standard (a CD player, I think), to differentiate Ford from, say, BMW, whose cassette tape decks were one optional extra, speakers to hear music from seemingly another…

Being a well-drilled undergraduate engineer, I wrote the subsequent report in the only way I knew how - with an introduction, a summary, a body and conclusions.

When I was given the job offer a few weeks later (which I took - a decision point that remains with me to this day, and is definitely worthy of a post of its own), Ford gave me some feedback over the phone. My presentation had been borderline terrible, but the report I had written was excellent.

In fact, it turned out that I had been the only candidate to actually write a report. Everybody else had written prose.

So, in honour of that, and in recognition of the possible fact that report writing remains for me, over emails and presentations, the main recipient of work related keystrokes, here’s my report on report writing in engineering.

TITLE

An Investigation into the enduring and endearing constraints of report writing

Author

The Literal Engineer

SUMMARY

The act of reading a technical report involves a certain mental effort. This effort should be rewarded with increased knowledge. In order to minimise the effort and to maximise the potential for knowledge extraction, the report writer should generate the report in as standard a way as possible.

The act of writing a report invokes a particular and peculiar mode of language, which itself requires a mental switch and effort to maintain, the passive voice. Writing in the passive voice lends the report an appearance (but no guarantee) of objectivity. A potential pitfall of the passive voice is the risk of the writing becoming stilted and unreadable. Yet this pitfall is deemed to present a lower risk to knowledge transfer than chatty and poorly applied novelistic writing.

Deciding on the tense remains difficult. The report should be written with history and evidence in mind; a report is a snapshot of the status of whatever is being investigated at the time, in this case – report writing. Using the passive voice is, overall, a positive constraint.

EQUIPMENT

Mid 2012 MacBook Air

2006 Rain Recording PC workstation with Logitech keyboard and mouse

Microsoft Word 2013 and Online

Microsoft Office 365 / OneDrive

Typepad blogging platform

Evernote note taking platform

Firefox and Safari browsers

1. INTRODUCTION

A technical engineering report can be understood as a window to a complex and meaningful event (or series of events) that took place within an organisation. The intended goal of a report is that its findings be understood. For this goal of understanding to be even remotely achievable, the report writer must describe the event in sufficient detail with sufficient brevity and clarity to form a synthesis of the outcomes of that undertaking. A report should therefore be  logically structured and legible.

Ideally, the summary and conclusions from a report should add to the great body of human knowledge. It is recognised, however, that, more often than not, reports must be produced to describe small-scale and often painfully regular events.

Regardless of where a report lands on the scale of import (or lack thereof) to humanity, the form and language follow traditional structures. Report writing in the technical fields is designed to enforce (the impression of) objectivity. The passive voice depersonalises the investigation and can be construed as an attempt to prioritise facts over individual actions.

I did not post this report on 30^th Sep.2014

rather:

This report was posted on 30.09.2014.

The tradition of using the passive voice imposes a constraint on the writer, which forces upon him or her (the passive voice at the very least enables authors to avoid the awkward distinction of the sexes) a mental switch and effort to make and to sustain the passive voice. This is an appropriate cost of entry, as the reader needs only recognise one style, whatever the source of the report.

2. THE STRUCTURE OF A REPORT

Reports are constructed around a common set of elements that may vary in style, format or order from organisation to organisation, but nevertheless ensure swift navigation to the pertinent sections or level of detail for the experienced reader - from an overall summary (usually to be found near the beginning), to detailed descriptions of equipment and methods used, via a logically structured body of evidence and discussion. The report at hand loosely follows such a typical structure and does not purport to set any standards with its own form.

It is also based on very little evidence.

3. THE CONSTRAINTS IMPOSED ON LANGUAGE IN REPORT WRITING

Actions and analyses leading to conclusions and summaries – no matter how breathlessly exciting at the time of their experiencing – are, in translation into a report, passed through a mental filter that compresses them into the passive voice.

This imposes a constraint on the author, which, similarly to the imposition of a recognisable structure on a report, lightens the burden on the reader (see Section 3.1 for more considerations on the reader’s role).

As in so many cases, especially in the arts and in engineering, this constraint can be viewed as overall positive: few physicists or engineers have been recognised as possessing the gifts of novelistic writing (or even spelling); honing the craft of the passive voice relieves these authors of many grammatical pitfalls.

The key to the passive voice, and the difference to novelistic writing, is that there are no characters or personalities to deal with. Someone or something does not do something to some other thing or person. Rather, some action is done to some object.

The strut was loaded into a tensile testing machine and its stress-strain curve was determined.

The sample was subjected to 60 cycles of cyclic corrosion testing according to specification X

The tea bag was placed into the pre-warmed cup. The cup containing the tea bag was filled to just off brim-full with boiling water. The assembly was left to stew for 4 minutes.

Humans act in all technical investigations, but the passive voice strips them out as being extraneous information. Whilst this is not always to be considered positive in most human relationships, being able to divide out the common denominators is, just as in arithmetic and mathematics, key to understanding the basic signals of what is being investigated. Humans, then, are a form of noise – in technical reports, at least.

Writing in the passive voice is a skill that must be honed with practice. For as long as the passive voice does not come naturally to the author, each sentence needs to be reviewed to ensure that the reader is not forced to stumble upon a person or a character rather than a description.

The implication of objectivity is valid. It doesn’t matter who did the test (especially in the sense of Professor vs. technician, or he vs. she): it’s not a diary. That information can be captured in lab notes, engineers’ notebooks, or the famous case notes from AT&T Bell.

3.1 THE BENEFITS OF THE PASSIVE VOICE

The passive voice is intended to portray the investigation as being impartial. This:

• enforces a certain mental discipline
• requires a certain mental “Umstellung” that brings the author into a standardised frame of mind.
• Permits the reader to read reports from any source in a similar frame of mind.
• Avoids “War and Peace”-style questioning of who was doing what to what other thing – no need to buffer names
• Personalities and their status are largely avoided
  • The facts and conclusions come first

3.2 DISADVANTAGES OF THE PASSIVE VOICE

• It is easy to “hide” the contribution of laboratory personnel, lower level engineers, and so on, to attribute the report to one “star” player. This is more likely to be an issue in the world of university, where academics are forced to publish on a regular basis – a quality investigation on a returned part is less likely to be the cause of professional envy.
• Can be stilted, can become impenetrable,
• Enforces the use of some awkward words or constructions

4. SELECTING THE TENSE

A key decision that needs to be made early on in writing the report, one which generates some confusion, even within one report, is the tense. Some decision aids are suggested as follows:

• Tests are described in the past tense: they were performed (“the samples were tested using the tensile testing machine at yy mm / minute”)
• Results are described in the past tense: “the stress-strain curve Fig. x.y was generated”
• Findings may be either in the past or in the present tense:
  • If a test was performed on a particular sample, e.g. investigating a failure, then the findings may be presented in the past tense:
    • “brazing of the joint was found to be incomplete”
• If a result was fundamental, then the findings may be presented in the present tense:
  • “the maximum tensile strength of the xx joint is YY MPa”

5. CONCLUSIONS

The technical report remains its own art form. Its art is knowledge and its form shall minimise the resistance to knowledge transfer. I really think that the passive voice helps to – oh, damn!

BIBLIOGRAPHY

http://www.sussex.ac.uk/ei/internal/forstudents/engineeringdesign/studyguides/techreportwriting

An engineer who knows the difference between literally and figuratively? Very suspicious indeed! Yet here I am, proudly rebranding myself as an engineer who also deals in words (and sounds, but that's another project). I've always needed to write, just as I've needed to nourish the technical aspect of my brain. When I'm at work, I'm, like literally engineering. At home and here in this blog I can be literally minded - thinking, reflecting and, from time to time, writing about engineering.

It's a big topic covering an unimaginable range of products, from things that we touch and use every day - to the arcane, that we rarely, if ever, see. And yet it's a small, parochial topic, too. Specifications, drawings, tolerances, materials - all of these need nurturing by us, the oft-unsung engineers, wherever and on whatever we work. And to do that, we need, like it or not, literally to use words.

So, here's my fresh start, with a fresh suit - which will need some nipping and tucking as time and wear go on. Let’s see where the journey takes us...

This post was first published over at Engineers Looking For Stuff, to which I contribute every now and again. I enjoyed writing this one so much, and it's so pertinent to the way that I think about engineering, that I asked and received permission to republish it here. They are my words, after all!

Engineers have an often uneasy relationship with words. The common assumption is that if left to our own devices we'll mangle grammar, butcher words and generally leave a trail of linguistic destruction in our wake. This is largely unfair, as stereotypes tend to be, but we are rightly better known for our smithing of iron than of prose. If we think about language at all, it's usually in the sense of grudgingly having to cope with it, or even wishing it away: "we shouldn't bother too much about writing - it's the product that counts."

It's true that product reaching customers is the goal of all our efforts, but words play such a large part in helping us get there that it would be a shame to scurry away from them, as if they were rain and we had no umbrella.

Instead, we should embrace words, using this rain like farmers rather than bankers - because we use them a lot. In our concept proposals, our offers, our specifications, our emails, our reports and even on our drawings, words carry meaning and intent to others. And, usually, these documents have our names on them, thus tagging us as author for eternity. How often does our product do that? (The makers among you rightly have permission to feel smug at this instance - but that still doesn't exempt you from having to use words!).

So pride in a job well done, in the knowledge that good communication leads to good product, should drive a conscious decision to get our writing up to as good a standard as we can - which, of course, means work.

Whether I'm drafting a blog post or a test report, I often feel my mind racing a few words ahead of me, sifting through multiple cascades of options and meaning, every so often stamping on the brakes as I get stuck with a word that hovers on the tip of my (mental) tongue. Even after that flurry of activity, what I "splash" onto the page needs refining, to ensure that it makes sense and - in deference to the reader - gets to the point relatively quickly and painlessly.

This is what I mean by effort, and the onus of that effort should be on the writer. We have to communicate, and, no matter how good we are at sketching and drafting, we can't escape having to deliver words to others. These words carry meaning and other more subtle levels of meaning: the tone.

All of us write differently depending on the scenario. So, whereas I use the word shall all the time in specifications, you'll hardly ever see it in my emails.

Whilst specs and drawing call-outs should be dry and almost legalese, riding as they do on the precise definitions of the words we select, emails can be chattier, depending on your audience. It's always worth considering your emails to be formal documents, however; they have a history and you'll be amazed how often emails from six years ago crop up when you or others are searching for information on a project or product. That's the positive spin on this: there is the negative aspect, that you no doubt can also imagine. So always review before sending (think of that "send" button as "Publish Now" and see what an effect that has on your haste).

The spoken word sets the collaborative tone even more starkly. Face to face there are the immediate signals that everybody sends with voice, body language and participation (or lack thereof) in the discussion, which go beyond the scope of this post, but there are subtle, weasel words that can affect the way people think about their jobs. Indeed, these were the catalyst for this very post.

It was in a project meeting a while ago that I first really noticed them. The product required some pre-assembly of a threaded adaptor and the commercial manager piped up with the comment:

"Then you simply need to screw in the adaptor…"

There it was, that word, "simply." It suddenly struck me how belittling that word was. To him, that assembly was a value in cents. To us it meant: determining the right tightening torque and number of turns, specifying, trialling and commissioning the equipment, specifying control methods, setting up a PFMEA… You get the idea.

Since that meeting I've become very sensitive to "simply," "only," "just" and their ilk and always point them out to those to carelessly utter them.

We have to watch out for those words everywhere. Imagine what real meaning lies behind the innocent remark "we only changed the process parameters a little bit…"

We should eliminate "simply" from our vocabulary (and help others to do the same) not in the spirit of saying "everything is hard", but in the spirit of "we value your expertise, we want you to keep on mastering your work, improving it, and yourself. so that our product can rock even harder than it does now."

What's in a word? That much can be in a word.