Engineering communication

Engineers spend a large share of their working time communicating: writing reports, specifications and emails, preparing drawings, presenting to clients and councils, and explaining risks to the public. Surveys of employers consistently rank communication among the skills they value most in new engineers, and investigations of failures repeatedly find that someone knew about the problem but the message did not get through. An excellent design that cannot be explained, checked or built from its documents is not an excellent design. This lesson covers the principles of clear technical writing, the structure of reports and memos, numbers, units and figures, engineering drawings, presentations, communicating with the public, the professional significance of sealed documents and records, and the responsible use of AI writing tools.

Know your reader and your purpose

Every piece of technical communication should start with two questions: who will read it, and what do I want them to know or do afterward? A city council deciding whether to fund a bridge repair needs the problem, the options, the costs and a recommendation in plain language; the contractor building the repair needs dimensions, materials and tolerances; the checking engineer needs the assumptions and calculations. One project may need all three documents, and writing any of them for the wrong reader wastes everyone's time.

Busy readers often read only the first paragraph. Engineering writing therefore puts the main point first: the conclusion, recommendation or request, followed by the supporting detail. This is the opposite of a school lab report that builds up to its conclusion at the end. Write so that a reader who stops after the first paragraph knows what you found and what you want.

Writing clearly

Technical writing should be accurate, clear and concise. A few habits make a large difference:

• Use short sentences and plain words. Write "use" rather than "utilize", "about" rather than "approximately in the region of".
• Prefer the active voice when the actor matters: "The contractor shall test the welds" makes responsibility clear; "The welds shall be tested" leaves it open.
• Be specific and quantitative. "The beam is overstressed by 18 %" beats "the beam is significantly overstressed".
• Define terms and abbreviations at first use, and use each term consistently; calling the same thing a "pipe", a "line" and a "main" in one report invites confusion.
• Separate facts, interpretations and opinions, and state uncertainties honestly.
• Use lists for parallel items and steps, and headings so readers can find what they need.
• Revise. First drafts are for the writer; later drafts are for the reader. Read the document aloud, or ask a colleague to read it, before sending.

Reports, memos and email

Most engineering reports follow a standard structure, which readers expect and can navigate:

• Title page, with the project, author, date, version and client.
• Executive summary: one page or less stating the purpose, main findings, conclusions and recommendations, written last and readable on its own.
• Introduction: background, purpose and scope, including what the report does not cover.
• Body: methods, data, analysis and results, organized under clear headings, with detailed calculations in appendices.
• Conclusions (what the results mean) and recommendations (what should be done), each traceable to the evidence in the body.
• References and appendices.

A technical memo is a short report of one to a few pages on a single topic, starting with the conclusion. Email is the most common engineering document of all, and it is a permanent business record that may be read in court years later. Use a specific subject line, put the request or conclusion in the first sentence, keep to one topic, and never put in an email anything you would not want read aloud at an inquiry. Important instructions, changes and decisions given orally should be confirmed in writing.

Numbers, units and significant figures

Numbers are the core of engineering communication, and errors with them have destroyed spacecraft and nearly brought down aircraft: the Gimli Glider of Lesson 1 ran out of fuel because of a confusion between pounds and kilograms, and NASA's Mars Climate Orbiter was lost in 1999 because one team's software produced thrust data in pound-force seconds while another expected newton-seconds. Good practice:

• Always state units, and use SI consistently unless the project specifies otherwise; when mixing systems is unavoidable, show conversions explicitly.
• Report results to a precision that reflects the data. If loads are known to two significant figures, a deflection of 23.4718 mm implies a precision that does not exist; 23 mm is honest.
• Put a space between a number and its unit (25 mm, not 25mm), use correct symbols and capitalization (kW, not KW; MPa, not mpa), and avoid ambiguous date formats such as 04/05/26.
• State the basis of numbers: gauge or absolute pressure, peak or RMS voltage, gross or net area, higher or lower heating value.

Figures and tables

A good figure can replace pages of text, but only if it is clear. Every figure and table should have a number and a caption that explains what it shows, be referred to in the text, label every axis with the quantity and unit, use a scale that shows the data honestly (a bar chart whose axis starts far above zero can exaggerate small differences), and remain readable in black and white and to readers with colour vision deficiency. Tables suit exact values that readers will look up; graphs suit trends and comparisons. Put the most important comparison where the eye can see it directly.

Engineering drawings and models

Drawings are the legal and practical language of construction and manufacturing: what is built is what the drawings and specifications say, not what the designer intended. They follow strict conventions so that anyone trained can read them: orthographic views (plan, elevation, section), standard line types and symbols, dimensions with tolerances, a title block identifying the project, drawing number, revision, scale, designer and checker, and a revision block recording every change.

In Canada, drawing practices follow CSA B78 standards and ISO conventions, with SI units; structural, mechanical and electrical disciplines each have their own symbols and practices.

Today most drawings are produced from three-dimensional computer models, and many projects use building information modelling (BIM), in which the architectural, structural and building services models are combined, checked for clashes (a duct running through a beam, for example) and linked to schedules and costs. The model is a powerful communication tool, but the issued drawings and specifications usually remain the contract documents, and engineers must ensure the two agree.

Presentations

Engineers present to colleagues, clients, management, regulators and public meetings. Effective presentations follow the same principles as writing: know the audience, put the main message first, and support it with a small number of clear points. Use few words on slides, large readable figures, and one idea per slide; the speaker carries the explanation. Rehearse with a clock. Anticipate questions, especially the hardest ones, and prepare backup slides with detail. When you do not know an answer, say so and promise to follow up, then do it.

Communicating with the public

Engineers are often asked to explain projects and risks to people without technical training, at public hearings, in community meetings and in the media. Public communication requires respect for the audience's concerns, which are often about fairness, trust and control as much as about numbers. Explain in plain language what is proposed, why, what the risks are and how they will be managed; use comparisons and visual aids; listen and acknowledge concerns rather than dismissing them as uninformed; be honest about uncertainty; and never claim something is "perfectly safe". Lesson 11 develops these ideas further. When speaking publicly, engineers must also respect client confidentiality and should make clear whether they are speaking for an employer or as individuals.

Sealed documents and records

When a professional engineer applies a seal or stamp, with signature and date, to a drawing, specification, report or calculation, they take personal professional responsibility for it, certifying that it was prepared by them or under their direct supervision and control and meets professional standards. In Alberta, APEGA's practice standard on authenticating documents requires professional documents to be authenticated by the responsible member, and many permit-holding companies also apply a permit stamp. Sealing a document you did not prepare or adequately review ("plan stamping") is professional misconduct. Regulators also require engineers to keep adequate records of their work, often for many years, because questions about a design can arise long after it is built.

Good records include design criteria, calculations with assumptions, correspondence, meeting notes, change records, review comments and their resolution, and field observations. A well-kept engineering notebook or project file is the best protection for the public, the client and the engineer.

Using AI tools responsibly

AI writing and coding assistants can draft text, summarize documents, suggest code and check grammar, and engineers increasingly use them. They can also produce fluent, confident text that is wrong: invented references, misquoted code clauses, unit errors and plausible but incorrect calculations. The engineer remains fully responsible for every document they issue, whatever tools helped prepare it. Good practice is to check every fact, number and reference against original sources, never paste confidential client information into tools that are not approved for it, follow employer policies, and be transparent with clients and colleagues about how the tools were used. Lesson 11 discusses the wider ethical questions raised by AI in engineering.