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

Why read this post? To find out why you should buy this fabulous "biography" of Bell Labs, and to consider how a monopoly set itself up for extreme innovation.

Jon Gertner’s The Idea Factory: Bell Labs and the Great Age of American Innovation is tech reverie, business book, political thriller and a superbly researched history into how some of mankind's most profound technical innovations (semiconductors and the transistor, solar panels, lasers, communications satellites, cellular mobile and Unix...) developed from fundamental ideas into production and into normality.

It is an exhilarating and – to this engineer, at least – humbling read with an appealingly comfortable feel to it of the book almost having written itself.

A history of people, biography of a formula

The narrative follows the giants of Bell Labs from their induction into AT&T to their passing: insightful Claude Shannon and incisive William Shockley, the genial instigator John Pierce, the politically adept scientist Bill Baker and a cast of thousands working within the innovative innovation structure constructed by the angular visionary Mervin Kelly.

Kelly’s formula is the leitmotif running alongside those histories. Both culturally and architecturally, it was about ensuring happenstance. Scientists were meant to be unable to avoid engineers, chemists were meant to bump into physicists and the men who “wrote the book” to interact with those who “read it.” It was a theory of ivory corridors and canteens rather than towers.

Hearteningly for small-fry like me, those who shared lunch, labs and projects with the Giants are also called out by Gertner for their contributions as lab technicians, metallurgists, engineers, project managers, chemists or physicists. There is always that sense of perspective that the products initiated by the Shockleys and Shannons of the Bell Labs world really needed input from each and every member to take them to production.

He didn't mention the cooks, though.

The invisible enthusiast

Jon Gertner is a journalist who has written for the New York Times and – less promisingly, perhaps – is editor-at-large at Fast Company*. This is his first book, up to now his largest undertaking by far. He spent five years building up this story - and it doesn’t show.

Not once did I feel the weight of his research, nor the burden of history, whilst reading The Idea Factory: the research and painstaking editing behind it is transparent. Gertner writes precisely yet lively, reflecting perhaps both the industrial-academic environment he describes and the local aspect of his endeavour: he grew up near the slightly mysterious, legendary Bell Labs headquarters at Murray Hill and his need to write this story comes across as being personal. Thankfully he found the energy and made the time to write it.

A monolith of innovation

AT&T enjoyed and, in pushing the boundaries of legislation, abused its monopoly position to maintain its role as “The System”. Those researchers and developers thrived within a massively integrated firm with the manufacturing might of Western Electric (which lovingly crushed or bought up many competitors in the past), the financial momentum of the phone operator (equally crushing), and the laboratories that drove the organisation to higher margins as well as higher callings (in not just the telephone sense…)

The calling to innovation as a justification of monopoly is the fascinating twist on our perception of this otherwise shimmering paragon of development. Teams that innovate need to get grubby, they need to ensure they have the best people and should “Never underestimate the importance of money.”

Without mass production, sales and distribution, no product may be considered to be innovative – so all of those tedious tasks surround, and can occasionally swamp, a product as it moves onwards to the market.

Notational Philosophy

The story behind the invention and development of the transistor would be worth the price of entry all by itself. But Gertner embellishes it with such lovely, pertinent little details that the reader can find thoughts spinning off in unexpected directions. One gem is the rigorously maintained notebooks used at Bell Labs. Each team member was required to write down thoughts and events relating to a particular case (or project, as we would call them now). Walter Brattain's notebook, number 18194, relating to his work on semiconductors (case 38139) continued on page 40, after 4 years of interruption through the Second World War, with: "The war is over."

There are other notational quotes in the book: from Morry Tanenbaum, as he closed in on discovering how best to manufacture layers of p-type and n-type silicone for the transistor: “will try direct approach…” (he melted an aluminium wire through the top layer) “This looks like the transistor we’ve been waiting for.”

These notebooks are - handwriting permitting - legible now, and are exceedingly well archived and organised. Will we be able to say the same of our loosely-managed files and cloudy projects in another sixty years? On the other hand – how searchable are those notebooks? Who can extract the knowledge that they contain, as well as the narrative, without knowing them intimately?

John Pierce – my new role model?

Although less well known (to me, at least) than the “transistor guys”, I felt an immediate affinity to one character that was totally new to me, John Pierce, of Telstar Satellite fame. “An instigator is different from a genius, but just as uncommon,” writes Gertner. “It was probably accurate to say that Pierce had too many ideas to actually pursue on his own, and too many interests… to focus on any single pursuit.”

Ah, I know this feeling only too well.

“’I tried to get other people to do things, I’m lazy,’ Pierce once told an interviewer.

‘Do you think this has helped your career?’ the interviewer asked.

‘Well, it was my career,’ Pierce replied.”

Pierce was a catalyst within Kelly’s formula of deliberate entanglement – wandering into offices with a bit of an idea and “just” starting things. It’s something that really should be encouraged, and perhaps remodelled in the virtual world, given how few offices are actually connected back in the real, normal world.

Moving on (looking wistfully back)

The book ends naturally with the passing of the golden generation and the fading into normality that is more poignant than any dramatic burn-out and crash. Gertner offers his thoughts on the meaning and lessons to be extracted for today’s Googles and Microsofts, for the myriad of startups gunning for their lunch – and for mere mortals like me.

Firstly, he considers whether swapping a factory of ideas (Bell Labs) for a geography of ideas (e.g. Silicon Valley) can match the muscle provided by monopoly. It’s close, perhaps, but, for all the advances that Silicon Valley has given us, in comparison with Bell Lab’s output, it has been largely incremental.

Secondly, he wonders if there is a way of escaping monopoly and government involvement in basic research at all. Here, he points out that “77 of the 88 U. S. entities that produced significant innovations were beneficiaries of federal funding.”

The concept of government involvement in anything brings with it the perception of incompetence, but Gertner summarises research into research with this:

“Creative environments that foster a rich exchange of ideas are far more important in eliciting important new insights than are the forces of competition."

White shirts and ties - the key to innovation?

Amidst all the deeply scientific and creative thinking going on at Bell labs during the “wonder years”, one constant appears to have underscored the whole process – everybody wore white shirts, and ties. Some eccentrics were known to go sockless in their shoes, but the fundamental aspect of Bell labs appears to have been the shirts.

My wardrobe consists of perhaps three white shirts, one of which is my wing-collar concert shirt for orchestra: it hardly brimming with scientific rigour.

So, when knocking on other peoples’ doors we should clearly be wearing crisp white shirts.

Hmm… a hint of sartorial determinism there? Perhaps Kelly has a better take on innovation:

“It’s the interaction between fundamental science and applied science, and the interface between many disciplines, that creates new ideas…”

This book is simply worth reading, and is worth reading again. So once you’ve got it, read it and lent it out, make sure you get it back…! 

*(5 amazing lists on the habits of 8 of the most productive ’10 of’ list writers in business today, to click you cleverer” would be a headline, even if that's only four lists)

As opposed to engineering with hectic grumpiness

Ah, finally - it's the Christmas holidays. At last, I've a chance to divert the kids into the path of their doting and understanding grandparents, then to sneak upstairs for a spot of stolen quiet-time. Time for switching off, for thinking and, in not too big a dose, writing.

Time for calm, quiet reflection is an astoundingly rare commodity. It has to be cherished and nurtured wherever possible, especially in that most unlikely of environments, work, where we happen to spend a goodly chunk of our lives. Reflecting on the the year that is petering out as I write, the biggest theme for me has been focus, or how difficult it has been to apply it with any regularity, and asking why I've not been successful at blanking off the world to exclude everything and everyone save the task to hand.

In the hustle and bustle of this engineering world that we inhabit, it's easy to get caught in the undertow of "actionism" (from that great German word Aktionismus) - doing stuff, doing more stuff, doing the same stuff again, doing more of the same stuff slightly differently; all of it urgent, most of it dull, mostly simultaneous, all of it with consequences for colleagues, suppliers and customers that mean, under the circumstances, we're unable to say "sod it." We're lynchpins without the luxury of deciding our priorities. Well, that's how I've been of late.

So, making use of this Christmas calm, I've tried to slow down, to reappraise how I - how we - work as engineers. The goal, I have decided, after a few sips of tea and a little staring out of the window, is that we must be able to work with grace, patience and precision.

This may sound like a whimsical, romantic view of master watchmakers or coffee roasters at their most reflective - but there's no way around it: it's the best way to approach any task. So let's have a think about what each of those concepts mean, and see if they make sense.

Grace and patience

Grace and patience are the rhino hide protecting the core of precision, which is the aim of any engineering activity. When they are too thinly applied, actions and deadlines chip away at the "precision" aspect of what we do. If we lack precision, then it's easy to become rattled or ratty when our decisions are questioned.

Grace is the ability to take on board what a task or a product requires, as communicated by people or by circumstance - or, as is more often the case, as not quite communicated by people or by circumstance. Grace means:

• Not being caught up in the emotion of the action
• Not being ruffled by the urgency of the action
• Retaining the ability to think clearly
• Retaining the ability to call in help and assistance from others without transferring the "panic"

... all the while, if possible, without becoming aloof, or putting on the "insufferable smile."

Patience is very much linked to grace, but means having the inner robustness to delve into a task, to keep at it, to maintain the ability to ask the right questions, to wait for the right answers as they develop. It is and requires:

• the ability to focus on a project
• the ability to "plod" through the logic of a project

Precision

Precision is the mark of getting things as right as they can be. It doesn't mean perfection (of which there is very little to go round), but rather getting the small things right, even if it's a version change to 1.1.2, so that the big steps can also be taken later. There are hundreds of examples that I could list, but in our world, understanding tolerances, GD&T callouts, specification callouts. etc spring to mind. They need to be defined them correctly in the context of your product.

Note that I don't mean setting tolerances arbitrarily small - precision is a result of the discussions with production, with suppliers, with customers, in the spirit of grace and patience. Getting things right, properly, defensibly.

Discovering the environment of grace and patience

A corollary of all of the above is that we as engineers need the environment in which to work with grace and patience. I would love to be able to say that we should be developing everything in splendid isolation from business needs. Like an AT&T Bell Labs from the glory days of transistors and lasers, or a 1960s IBM, we should be capable of working on the future. To be honest, though, I can't even imagine working in such a world. It could be wonderful, it could be terminally dull (though I dream it would be the former).

We need to face reality. I work in the automotive industry, which tends to be rather full of rowdy reality, so I know what it means to suffer business pressures alongside engineering and development pressures, in open-plan offices, without air conditioning.

Attaining the "state" of grace and patience in such an environment has to stem from a conscious decision to find and to nurture them first. As far as I can see, the breakthrough needs to be mental.

Without coming over too Zen, I think (but can't say from experience) it should be possible to filter out background noise and to focus on the task at hand. We can help ourselves by taking small physical steps like turning off email alert pop-ups, silencing phones and perhaps setting up "do not disturb" signals for our colleagues; big headphones, for example. Occasionally escaping to a lonely meeting room can work, though it does mean leaving a whole desk's worth of tools behind.

What I'm saying is that we (I, at least) need to be clearer of what our mental capabilities are, what we need to learn and how we should develop ourselves, our processes and our communications with colleagues (commercial, quality, purchasing, suppliers - that whole bubble world that we interact with) so that we end up being able to focus on work, permit the minimum of distractions and can take time to research, collaborate and to iterate our way to the future, all in the spirit of grace, patience and precision.

Easy job. Let's have at it in 2014...!

Just before this (at the time long overdue) vacation, I was invited to attend a meeting with a technical sales guy from a supplier. Normally, I must admit, I tend to be somewhat (too) polite with people I meet on a professional basis, which can get in the way of the real goals of a meeting - obtaining information and actions. This time, though, exhausted as I was following the stresses and strains of moving house, and from lack of quality sleep during the hot summer nights, I was on a shorter fuse than normal.

And it felt great. I finally didn't care about potentially hurting somebody's feelings with indelicate questions - I just asked, and asked again if I felt I was getting a wishy-washy (salesy) answer. I was liberated to become a grumpy engineer: I stopped filtering myself, tying myself in worrisome knots, and got to the heart of the matter much more quickly than I would have.

So the lesson here for me was that I should try to distill the essence of grumpiness (giving waffle and muddiness of answer short shrift, wanting to get out of meetings as quickly and as effectively as possible), without having to go down the route of exhaustion or really offending my business contacts. Tips, tricks, resources on this would be welcome!

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.