COMMST 191: Communication in the Engineering Profession

Sources and References

Primary textbook — Mike Markel, Technical Communication (Bedford/St. Martin’s). Supplementary texts — Lannon & Gurak Technical Communication; Joseph Williams Style; Edward Tufte The Visual Display of Quantitative Information; Sharon Crowley & Debra Hawhee Ancient Rhetorics for Contemporary Students. Online resources — Purdue OWL; MIT OCW 21W.732 Science Writing; Professional Engineers Ontario Practice Guideline on Communications.

Chapter 1 — What Technical Communication Is and Why Engineers Need It

Technical communication is the practice of delivering information about specialized subjects — designs, experiments, procedures, hazards, recommendations — to readers who must act on that information. Mike Markel’s definition centers the word use: a document is technical communication when somebody makes a decision or performs a task based on what it says. A feasibility study that shapes a municipal council’s vote, a memo that warns a site foreman about a contaminated fill layer, an email asking a vendor to confirm a concrete delivery — all of these count, and all can fail in ways that have real physical consequences.

In the workplace, engineers in Architectural, Civil, Environmental, and Geological practice spend roughly a third to a half of their working hours writing or speaking, and the proportion rises with seniority. Industry surveys cited by Lannon and Gurak show communication quality as a consistent predictor of promotion and of being trusted with client-facing work. The technical ability to run a stability analysis is necessary but not sufficient.

Technical communication differs from humanities writing in a few stable ways. It is reader-centered: the goal is not to express the writer’s thought in full but to give the reader what they need to act. It is bounded by purpose: every section should be justifiable against what the reader must do next. It is accountable: a claim is traceable to data, a standard, or a cited source, and the writer is legally and professionally responsible. And it is genre-heavy: readers expect specific document shapes and will be slowed down if those conventions are ignored.

These distinctions are not aesthetic. Engineers operate under codes of practice (in Ontario, Professional Engineers Ontario), under public-safety obligations, and under legal regimes that treat engineering documents as evidence. A report that is unclear, omits an uncertainty, or hides a trade-off is not just a stylistic failure; it is a source of risk. In a single week a junior engineer might write a supplier email, a site-visit memo, a draft progress-report section, a comment on a drawing, and a client slide deck — none of which resembles a five-paragraph essay. A course in engineering communication has to move fast across genres and teach the underlying habits — audience analysis, clean sentences, principled visuals — that transfer across all of them.

Chapter 2 — Audience, Purpose, and Genre

Every technical document is shaped by three questions: who will read it, why, and what kind of document are they expecting? Markel treats these as the scaffolding of the planning phase.

Audience. In engineering, a document rarely has a single reader. A stormwater-pond feasibility report might be read by a project manager, a municipal planner, a geotechnical specialist, a resident, and a lawyer. Lannon and Gurak divide readers into primary (who will act on the document), secondary (whose work depends on the primary reader’s action), tertiary (who need to stay informed), and gatekeepers (managers, legal, regulators who approve before release). Writing is easier when you pick one primary reader, imagine them concretely, and let that drive vocabulary, detail, and structure. It matters whether the reader is an expert (wants terse precision), a technician (needs executable procedures), a manager (wants bottom line, cost, schedule, risks), or a lay reader (needs analogies and plain language). Mixed audiences are why reports acquire layered structures — executive summary for managers, body for experts, appendices for technicians.

Purpose. Purpose is what the writer wants the reader to do. Purposes cluster into families: to inform, to instruct, to persuade, to record, to regulate. Naming the dominant purpose in one sentence — I want the client to approve option B — lets you check every paragraph against it.

Genre. Genres are stable document shapes that evolved because they make common jobs fast. A lab report’s IMRaD arc lets an expert skim to the section they care about. A progress report places status, problems, and next steps in predictable slots. An email uses subject lines and short paragraphs because readers triage a queue. Genres are not straitjackets but they are not arbitrary: they encode a community’s agreements about packaging information.

Audience, purpose, and genre interact. A progress memo for your manager is a different document from a progress section in a client report, even though both describe the same month’s work. Good writers re-run the three questions at the start of every document and resist recycling text without checking whether the new context wants the same information.

Chapter 3 — Rhetorical Foundations: Ethos, Pathos, Logos for Technical Writers

Crowley and Hawhee’s reading of classical rhetoric reminds engineers that persuasion is not separate from informing. Every technical document is an argument — that a design is sound, a hypothesis is supported, a budget is reasonable, a risk is responsibly managed. Aristotle’s three pisteis, or means of persuasion, name the three resources a writer has.

Logos is the appeal through reason and evidence, dominant in engineering: calculations, standards, test results, and inference chains carry most of the argumentative weight. But logos is more than “show the numbers.” It includes the selection and ordering of evidence, the reasoning that connects data to conclusion, and the explicit statement of assumptions. A reader who cannot reconstruct the argument from what is on the page is looking at failed logos, no matter how many figures are present.

Ethos is the appeal through character — the reader’s sense that the writer is competent, careful, and honest. Engineers build ethos through small signals: accurate citations, appropriate hedging, acknowledged limitations, correct units, consistent terminology, and a tone that neither oversells nor apologizes. Ethos is also built by not doing things: not hiding bad results, not cherry-picking, not making the reader catch errors. A single sloppy mistake can cost more ethos than a dozen polished pages earn.

Pathos is the appeal through the reader’s values and interests. Engineers sometimes imagine pathos is off-limits because the profession prizes detachment. That is a misreading. Pathos in technical writing is not manipulation; it is the recognition that readers care about real things — public safety, environmental quality, cost, reputation, the well-being of users — and that appealing to those concerns is legitimate. A recommendation report that argues for a more expensive drainage design because it reduces flooding of a residential neighborhood makes a pathos appeal when it names the neighborhood and sketches what flooding means for the people who live there.

The three appeals work together. A strong engineering document establishes competence (ethos), lays out reasoning (logos), and connects to what the reader cares about (pathos). When only one is present the document is fragile.

Chapter 4 — Ethics and Professional Responsibility

Engineers work on systems whose failure can kill people or contaminate water supplies. The Professional Engineers Ontario Practice Guideline on Communications and parallel codes treat communication as a dimension of professional duty. An engineer’s first duty is to the public, and that duty flows through every document they put their name on.

The core ethical commitments are demanding in practice. Honesty means claims are supported by evidence, uncertainties are disclosed, and interpretation is not shaded to favor a client. Accuracy means numbers are checked, units are correct, and cited sources say what the writer claims they say. Completeness means relevant facts are not omitted — especially facts that complicate the writer’s preferred conclusion. Clarity is an ethical obligation, not a courtesy: a deliberately confusing document that lets the writer deny responsibility for its implications is a form of dishonesty.

Several classic case studies shape how engineering communication is taught. The Challenger disaster is canonical: engineers who understood the O-ring risk failed to communicate it in a form the launch decision-makers could act on. The poorly designed table of past O-ring performance and the absence of a clean chart showing temperature versus damage have become teaching staples because they show that visual and verbal choices are not neutral. Columbia’s foam-strike incident produced a similar lesson about PowerPoint slides burying critical information in nested bullets. Closer to civil and environmental practice, the Walkerton water contamination inquiry in Ontario and the Elliot Lake mall collapse review both found that communication failures — missing reports, ambiguous language, unclear lines of responsibility — contributed to deaths.

Whistleblowing is the hardest case. When a project endangers the public, PEO’s guideline describes a ladder: raise the concern internally, document it in writing, escalate, and if unaddressed, report externally. Writing is central at every rung. A well-documented internal memo describing the hazard, the relevant standards, and the recommended action is both an ethical act and a protection for the engineer, because it creates a record that they did their job.

Ethics also covers quieter choices: reusing boilerplate without updating the specifics, copy-pasting a figure without citation, using a favorable photograph to disguise a defect, hedging a negative finding so a hurried manager misses it. These decisions define a writer’s integrity over a career, and they are trained, not innate.

Chapter 5 — Plain Language and Clear Sentences

Joseph Williams’s Style is the best short book on English prose, and its advice applies with unusual force to technical writing. Williams’s central claim: clarity comes from matching grammatical structure to the story the sentence is telling — put the main characters in subject position, and put their important actions in the main verbs.

Engineering prose fails this test most often through nominalization — turning verbs into nouns. “The engineers performed an inspection of the beams” is a nominalized version of “the engineers inspected the beams.” The second is shorter and livelier because the character (engineers) and action (inspected) occupy their natural slots. Williams’s cure is mechanical: find verbs hiding inside nouns and liberate them.

A related enemy is the passive voice when it hides the agent. “It was determined that the sample was contaminated” tells the reader a determination happened but not who made it. Passive voice is not universally bad — sometimes the agent is irrelevant — but engineers overuse it because it feels professional, when in fact it blurs accountability. Use the passive when the agent is genuinely unknown, obvious, or unimportant; use the active otherwise.

Plain language is also about concreteness and sentence length. Long sentences chaining abstract subjects quickly become unreadable. Read aloud; if you run out of breath or lose track of the subject, break it up. Technical vocabulary is not the enemy — engineers need their specialized terms — but jargon used to impress is. The Plain Language Movement has been adopted by governments (the U.S. Plain Writing Act, Canadian guidelines) because plain language saves money and prevents errors.

Worth practicing until automatic: prefer short Anglo-Saxon verbs over Latinate ones (“use” over “utilize,” “show” over “demonstrate”). Cut redundancies (“end result,” “past history,” “in order to”). Avoid stacked modifiers. Keep subject and verb close together. Use parallel structure for parallel ideas.

Chapter 6 — Structuring Information: Paragraphs, Headings, Signposting

If sentences are bricks, paragraphs are rooms and headings are the floor plan. Engineers often treat structure as a last-minute decision, bolting headings onto continuous text. The result feels disorganized even when the sentences are clean.

A well-built paragraph has a topic sentence that names its point, followed by sentences that develop it with evidence, explanation, or qualification. Williams’s sentence-flow advice also works at paragraph scale: put old information at the start of each sentence to connect it to the previous one, and put new information at the end where it lands with emphasis. This “known-new contract” is the most reliable way to make prose feel connected.

Headings let skimming readers find sections and force the writer to commit to structure. Markel recommends informative headings over generic ones: not “Discussion” but “Why option B costs less over a twenty-year horizon.” Informative headings act as a skeletal table of contents and reveal structural problems — vague headings mean the writer has not decided what the section is about. Use parallel headings at each level: if one is a noun phrase, all should be. Numbered headings (1, 1.1, 1.1.1) are common in formal reports because they let readers cite sections precisely.

Signposting is the set of small phrases that tell the reader where they are: “This section argues that…,” “A further concern is…,” “To recap the three findings above…,” “Section 4 returns to this assumption.” Overdone it feels clunky; used conservatively it is what separates a navigable report from one you get lost in.

The pyramid structure deserves its own note. Engineering reports almost always benefit from placing the conclusion up front. An executive summary states the recommendation, the key reasons, and the main risks; the body supports it; the appendices hold detail. This inverts the order in which work was done (investigate, then conclude) but matches the order in which the reader needs information. In technical contexts, giving away the ending is the service.

Chapter 7 — Email, Memos, and Workplace Correspondence

Most engineering communication happens in email. Markel, Lannon, and the PEO guideline treat email as a serious professional genre because emails enter the project record: they are discoverable in litigation, can be forwarded anywhere, and create durable obligations. A careless 4:55 PM Friday email can be read in a courtroom five years later.

A professional engineering email has reliable features. The subject line names the project and the action requested in a phrase that still makes sense a month later; “Quick question” is the canonical bad subject. The first sentence or two state the purpose and what the sender wants — approval, information, a decision. The body supplies context in as few words as possible. The closing states the next step and, if needed, a deadline. The signature gives name, title, organization, and phone. Tone is harder in email than in longer documents; a neutral, respectful, slightly-warmer-than-necessary default is almost always right. Jokes risk losing context on forwarding; anger is very risky. The classic advice — write the angry draft, save it, reread the next morning, send the shorter colder version — still works.

Memos are the internal cousins of emails, used for longer or more formal messages. A memo header lists To, From, Date, Subject. The body follows the same direct-opening discipline: point first, context next, action at the end. Recommendations appear at the top, not buried.

Meeting minutes record decisions, action items with owners and deadlines, and flagged risks. They do not reproduce the conversation. Weak minutes are either too long (transcripts) or too short (topic lists). A useful test: can a team member who missed the meeting do their next week of work from the minutes alone?

Two forms trip up juniors: request emails and status updates. A request makes the ask explicit, provides what the reader needs to say yes, and names a deadline. A status update gives state (green/yellow/red), milestones hit, blockers, and next milestones. Both should be short and get shorter with practice.

Chapter 8 — Technical and Progress Reports

A technical report is the long-form document that engineers are best known for producing. It synthesizes work on a problem into something a reader can act on. The shape varies by context, but the Markel template is a reliable default: front matter (cover, letter of transmittal, title page, abstract, table of contents, list of figures), body (introduction, background, methods, results, discussion, conclusions, recommendations), and back matter (references, appendices, glossary).

Each front-matter element does a specific job. The letter of transmittal hands the report to the client in a few paragraphs and says what it is and why it was produced. The abstract is a one-paragraph version of the entire report, including the recommendation — a reader who reads only the abstract should know what the report is saying. The executive summary (often distinguished from the abstract by length and audience) is a longer, manager-oriented précis, usually a page or two, that lays out the problem, the approach, the key findings, and the recommendation in plain language with the numbers.

In the body, the introduction establishes the problem, the scope, the objectives, and the criteria that will be used to evaluate the work. A reader who finishes the introduction should know what question the report is answering and how it will be answered. The background supplies whatever context the reader needs — previous work, site conditions, regulatory framework — and is often where boilerplate creeps in; resist the temptation. Methods describes what was done in enough detail that a comparable engineer could replicate it. Results presents the data without much interpretation. Discussion interprets the results, compares them to expectations, acknowledges uncertainties, and draws conclusions. Recommendations name the actions the writer proposes, in order of priority, with their rationales.

Progress reports are a specialized subgenre. Their job is to tell a client or supervisor where a project stands and what is coming next. Markel’s template for a progress report is worth memorizing: (1) project identification and reporting period; (2) summary of work completed since last report; (3) work in progress; (4) problems encountered and how they are being addressed; (5) work scheduled for the next period; (6) overall status against budget and schedule. The virtue of the template is that it forces the writer to name problems. A progress report that says “all is well” when it isn’t is a communication failure that can sink a project, because the client loses the chance to help.

A recurring discipline is reporting against the baseline. The baseline is the original scope, budget, and schedule. The progress report measures the current state against it — percent complete, dollars spent versus dollars budgeted, days ahead or behind. Variances are explained. A mature progress report does not hide variances; it names them early, attributes them honestly, and proposes corrective action.

Chapter 9 — Feasibility and Recommendation Reports

A feasibility report asks whether a proposed project can be done, and a recommendation report asks which of several options should be chosen. In practice they overlap, and Markel treats them together under the heading “analytical reports.”

The governing principle is criteria-based analysis. Before you can say whether an option is feasible or which option is best, you have to state the criteria the decision will be made on, and you have to state them in a form that can actually discriminate between options. For a stormwater management alternative, criteria might include peak-flow attenuation, construction cost, maintenance cost, land area required, ecological impact, public acceptability, and compliance with municipal standards. Each criterion should have a measurable or at least defensible scale.

Once criteria are fixed, each option is evaluated against each criterion. A decision matrix is the canonical tool: options as rows, criteria as columns, scores in the cells, and a recommendation that explains how the scores lead to the choice. Decision matrices are not oracles. They can be manipulated by choosing criteria, weights, and scales that favor a preferred answer. A professional recommendation report presents the matrix transparently, justifies the weights, and discusses sensitivity — what happens to the recommendation if a weight changes?

The structure of a recommendation report closely tracks the technical report template, but the discussion section becomes comparative. A good pattern: introduction and statement of the problem; criteria and their justification; description of the options; comparative evaluation against each criterion; summary of the evaluation (often as a matrix); discussion of trade-offs; recommendation with implementation notes and risks. The recommendation is stated unambiguously. “It is suggested that option B might be preferred” is weak; “We recommend option B” is what the reader is paying for.

Feasibility reports add an additional layer: they must argue whether the project should be done at all. The classic categories of feasibility are technical (can we actually build it with available technology?), economic (do the benefits exceed the costs over the relevant horizon?), legal and regulatory (is it permitted?), operational (can it be run once built?), scheduling (can it be delivered in time?), and environmental and social (are the impacts acceptable?). A feasibility study that checks only the technical and economic boxes and ignores the regulatory or social ones will get the engineer and the client in trouble.

One underdiscussed element: the null option. Good analytical reports include “do nothing” as an explicit alternative, and evaluate it against the same criteria as the active options. Sometimes it wins. More often it loses, but naming it makes the argument for action concrete.

Chapter 10 — Lab Reports and Experimental Writing

Lab reports are where most engineers first learn the discipline of writing up experimental work, and the shape they take in undergraduate courses prepares them for the journal articles and internal research reports they will write later. The canonical structure is IMRaD: Introduction, Methods, Results, and Discussion. A full lab report also includes an abstract, a theoretical background or literature section, a conclusions section, and references.

The introduction frames the question. It states the scientific or engineering problem, explains why it matters, and lays out the specific hypothesis or objective of the experiment. An undergraduate lab report often skips this step or replaces it with rote recitation; a professional one uses it to tell the reader why they should keep reading. The theoretical background (or literature review in research writing) locates the work in the existing body of knowledge: what is already known, what equations or models will be used, what previous work the current experiment depends on or extends.

Methods is the place where ethos is built most concretely. It has to be detailed enough that a competent reader could repeat the experiment. It names the equipment (with manufacturer and model where relevant), the materials, the procedures, the sample sizes, the measurement techniques, and the data analysis methods. Where calibrations matter, they are reported. Where deviations from standard procedure occurred, they are named and justified. A reader who cannot figure out how you collected your data has no basis to trust the results.

Results presents the data. The dominant convention is to show the data first and interpret it afterward, so results sections are relatively descriptive: “Figure 3 shows the load-deflection curve for each beam; the mean peak load across the five samples was 48.3 kN with a standard deviation of 2.1 kN.” Graphs and tables carry most of the information; the text tells the reader where to look and what the major features are. Do not duplicate in prose what the graph already shows; do point out the parts of the graph the reader might miss.

Discussion is the most important and most often underwritten section. It interprets the results in light of the hypothesis or objective. It compares them to predictions from theory, to values in the literature, and to expectations from design. It explains anomalies. It discusses uncertainty — both the statistical uncertainty in the measurements and the systematic uncertainties from the method. It acknowledges the experiment’s limitations honestly. A discussion that merely restates the results is a missed opportunity; one that explains what the results mean and what they do not mean is doing the real work of the report.

Uncertainty deserves separate attention. Engineering measurements always come with uncertainty, and a lab report that reports a value without a stated uncertainty is misleading by omission. Uncertainties can be expressed as a standard deviation, a standard error, a confidence interval, or a tolerance, depending on the conventions of the field. What matters is that the uncertainty is stated, its source is named (measurement precision, calibration, sample variation, method), and it is propagated correctly through subsequent calculations. A reported value of 48.3 kN means something very different if the uncertainty is 0.1 kN than if it is 5 kN.

A final point: lab reports are written for a reader, not for the instructor. Imagining the reader as a colleague in the next office — someone who knows the basics but was not in the lab with you — produces reports that are informative without being condescending.

Chapter 11 — Research, Source Use, and Citation

Engineering research is not the same as humanities research, but it has its own rigor. The sources an engineer draws on include standards (ISO, ASTM, CSA, IEEE, Eurocode), codes of practice, peer-reviewed journal articles, conference papers, government reports, manufacturer specifications, and textbooks. Each has its own level of authority and its own conventions for citation.

A standard is a consensus document that codifies agreed-upon practice or testing methods; citing it tells the reader that the writer’s method is traceable to a recognized authority. A peer-reviewed journal article has passed through expert review and is the strongest form of citation for scientific claims. Conference papers are useful for current research but are reviewed less stringently. Government reports are authoritative for policy and statistics but vary in technical depth. Manufacturer specifications are indispensable for product-specific data but should be corroborated where possible. Textbooks are fine for well-established material but are weak citations for cutting-edge claims.

Engineers typically use IEEE citation style (numeric, bracketed, with a numbered reference list) for papers in electrical and computer engineering contexts, and some variant of author-date (commonly a Chicago or APA-like format) for civil, environmental, and management contexts. Both styles have the same underlying requirements: the citation should let the reader find the source, and the reference list should include enough information (author, title, publication, year, pages, DOI or URL when appropriate) to do so. The specifics of punctuation and abbreviation vary; what matters is consistency and completeness.

Plagiarism in engineering is treated seriously because it undermines the attribution of credit, the traceability of claims, and the integrity of the profession. It is not limited to copying sentences verbatim. Paraphrasing a source without citing it, adopting a figure without credit, reusing your own prior work without acknowledgment (self-plagiarism), and failing to cite a key reference are all forms of plagiarism. The cure is a habit of careful note-taking during research: when you save a quote or a figure, record the source and page immediately. Most plagiarism is accidental and the product of careless sourcing, not bad intent; a strong note-taking practice prevents it.

Source evaluation is a skill of its own. A citation is only as good as the source behind it. Questions to ask: who wrote it (credentials, affiliation, conflicts of interest); when (is it current enough for the claim?); where is it published (peer-reviewed? self-published? a trade magazine?); what kind of claim is it making (a piece of data, a theoretical derivation, an opinion?); and does it corroborate with other sources? The open web has made research faster and source evaluation harder, and engineers need to be explicit about where their facts come from.

Finally, integrating sources into engineering prose follows a consistent pattern: introduce the source, report the claim, cite it, and explain how it bears on the writer’s own argument. Direct quotations are unusual in engineering writing; paraphrase is the default because it lets the writer integrate the source into the flow of their own argument. Long quotations should be reserved for cases where the original wording matters — a definition in a code, a contentious claim in a standard — and should be properly blocked and cited.

Chapter 12 — Visual Communication: Graphs, Tables, and Diagrams

Edward Tufte’s The Visual Display of Quantitative Information is the textbook here, and its arguments have reshaped how engineers present data. Tufte’s core commitment is that a good graphic shows the data, clearly, with minimum distraction and maximum information density. The catchphrase he coined — “above all, show the data” — is a useful corrective to the default in much engineering software, which is to bury the data under colors, gridlines, and 3D effects.

Tables are for precise values that a reader might want to read individually. Graphs are for patterns, trends, and comparisons. Choosing between them is the first question. If the reader needs to know that the beam failed at 48.3 kN, a table gives that exactly. If the reader needs to see that load rose linearly and then flattened, a graph shows it at a glance. Both can be in the same document, and often both are needed.

Among graph types, line graphs show a continuous relationship between two variables (almost always with the independent variable on the horizontal axis). Scatter plots show the relationship between two variables across many discrete measurements. Bar charts show comparisons across discrete categories. Histograms show the distribution of a variable across its range. Pie charts are almost always a bad idea in technical writing because humans are bad at reading angles; a horizontal bar chart communicates the same proportions more clearly. 3D effects are almost always distracting, and shadows, gradients, and textures rarely help.

Tufte’s principles are worth stating directly. Maximize the data-ink ratio: most of the ink on the page should be showing data, not decorating it. Minimize chartjunk: remove gridlines, backgrounds, redundant labels, and decorative elements that do not encode data. Avoid lie factors: the visual representation should be proportional to the numerical reality. Truncated axes, for example, can make a 5% change look enormous and should be used deliberately and labeled clearly. Use small multiples: several small versions of the same chart, side by side, let a reader compare conditions quickly and are often better than a single cluttered chart with many lines.

Captions are a distinct problem and often underdone. A caption should stand alone — a reader flipping through the document and landing on a figure should know what it shows and why it matters without reading the main text. “Figure 3: Load vs. deflection” is weak; “Figure 3: Load vs. mid-span deflection for the five test beams; all samples showed linear elastic behavior up to approximately 40 kN before yielding” tells the reader something. Captions always include units, sample sizes or n, and any relevant conditions.

Tables have their own design discipline. Line up numbers by decimal place for easy comparison. Use horizontal rules sparingly — full grids of vertical and horizontal lines turn tables into cages. Round to the appropriate number of significant figures; presenting five significant figures when the measurement supports only two is misleading. Order rows and columns in a way that helps the reader see the structure (by size, alphabetically, by experimental condition) rather than leaving them in the order the data happened to be collected.

Engineering diagrams — schematics, cross-sections, plans, flow diagrams, P&IDs — are a distinct visual language with their own conventions. They are usually governed by standards (ISO, CSA, IEEE) that specify symbols, line weights, labeling, and title blocks. An engineer’s job with a diagram is usually to produce one that follows the relevant standard and then to integrate it into a surrounding document with a caption that names it, references it in the text, and explains what to look at.

Chapter 13 — Document Design and Typography

Document design is often taught as an afterthought, but a well-designed document communicates more effectively than a poorly designed one with the same content. Markel treats design as a rhetorical act: the visual form of a document shapes how the reader moves through it and what they remember.

The foundations of document design are consistency, contrast, alignment, proximity, and repetition — the classic CARP principles from Robin Williams’s Non-Designer’s Design Book. A consistent document uses the same heading styles, margins, typefaces, and spacing throughout. Contrast makes important elements visible; without contrast, a reader cannot tell where to look. Alignment gives the page an invisible structure that the eye follows. Proximity groups related elements together so that the reader sees them as belonging to each other. Repetition reinforces the visual structure so that each page feels like part of the same document.

Typography is the most important design decision. A typeface is either serif (small strokes on the ends of letters, like Times, Garamond, or Cambria) or sans-serif (clean ends, like Helvetica, Arial, or Calibri), and each has its uses. Serif typefaces tend to be easier to read in long passages of body text at small sizes in print; sans-serif typefaces tend to be easier to read at small sizes on screens. The traditional technical-report convention pairs a serif body font with a sans-serif heading font, but a single well-chosen font family with bold and regular weights works almost as well and is simpler.

Point size for body text is usually 10 to 12 points in printed documents. Line spacing at 1.15 to 1.5 is a reasonable default for drafts; single-spaced tight lines look crowded, and double-spaced lines waste paper for no benefit in final documents. Line length matters: lines that run too wide (more than about 75 characters) are hard to read because the eye loses its place returning to the start of the next line. Two-column layouts in journal articles are partly a response to this.

White space is not wasted space. It separates sections, lets headings stand out, and gives the reader’s eye a place to rest. Dense pages with no white space signal “hard to read” before the reader has parsed a word. Margins of about an inch on all sides, space above headings, and space between paragraphs all contribute.

Color should be used purposefully and sparingly in technical documents. Color can encode data (red for warnings, green for “pass,” blue for “info”), distinguish elements (heading color, link color), or simply decorate. The last use is rarely worth it. Remember that documents may be printed in black and white, projected with distorted colors, or viewed by readers with color vision differences; any information that is carried only by color is at risk. Use redundancy (color plus label, color plus shape) for anything important.

Lists deserve a specific mention because they are overused. A bulleted list is appropriate when the items are genuinely parallel and order-independent. A numbered list is appropriate when order matters or when later text will reference items by number. Running text is appropriate when items are not parallel, when they need connective logic, or when the relationships between them cannot be captured by a bullet. Engineering documents sometimes turn into strings of bullet points that hide the argument; when everything is a bullet, nothing is.

Chapter 14 — Oral Presentations for Engineers

The MIT OCW 21W.732 science-writing materials have useful guidance on oral presentation, and the advice overlaps heavily with what Markel and Lannon teach. The central insight is that an oral presentation is not a written document read aloud; it is a different medium that has to be designed on its own terms.

The audience in an oral setting cannot skim, cannot reread, and has limited attention. Every sentence in a talk has to be understood in real time, which means simpler syntax, shorter sentences, and more signposting. Listeners forget most of what they hear within minutes, so a talk should have a small number of clear messages — usually three or fewer — and should repeat them: tell them what you are going to tell them, tell them, then tell them what you told them. This advice is a cliché because it works.

The structure of a talk tracks the pyramid principle even more strictly than a written report does. Start with the problem and why the audience should care. State the main finding or recommendation up front. Spend the body supporting it with evidence. End with the implications and a clean summary. A talk that buries the conclusion five minutes in loses the audience who needed it at minute one.

Slides are a separate design challenge. The classic failure mode is the slide with seven bullet points that the speaker reads aloud while the audience reads ahead. A better approach is to use slides as visual aids for the audience’s eyes while the speaker delivers the verbal argument — one image or chart per idea, titles that state the point of the slide in a sentence (“Option B costs 22% less over a 20-year horizon” rather than “Cost comparison”), sparse text, and large type. A slide that cannot be read from the back of the room is not doing its job. A rule of thumb: if you could deliver the talk without speaking because the slides say it all, your slides are too dense.

Delivery is underrated by engineers. Speaking a little more slowly than feels natural, pausing between sentences, looking up at the audience rather than at the slides, and varying pitch and volume all make a talk easier to follow. The single most common delivery problem in engineering presentations is speaking too fast out of nervousness. Practicing out loud — really out loud, with a timer — is the single most effective preparation, and twice is not enough. Three times is better. Five is better still.

Handling questions is another skill. Listen to the question fully before answering. Rephrase it if it was unclear. Answer briefly. If you do not know, say so — “I don’t know; we would have to check X” is always better than a bluff. If the question is hostile, answer its factual content, not its tone. Questions are a gift: they tell you what the audience is confused about or cares about, and they give you a chance to reinforce your main message.

A final practical note: timing. Engineering talks almost always run long. The fix is to prepare a version of the talk that is comfortably shorter than the slot, so that if you speak slightly slower than in rehearsal (which is normal) you still finish on time. Ending early is fine; ending late is a gift to the next speaker you cannot afford to give.

Chapter 15 — Writing in Teams

Most engineering documents are written by more than one person. Team writing is a distinct skill because its problems — inconsistent voices, duplicated or missing sections, last-minute chaos — are predictable and avoidable.

A team project benefits from an explicit plan at the start: audience, purpose, genre, deadline, agreed before anyone writes a sentence. The team then produces a detailed outline with section headings and target lengths and assigns sections to writers. An outline agreed at the start saves hours of revision later. Style conventions should also be agreed up front: citation style, unit conventions, terminology, heading and figure templates. A one-page style sheet is worth producing.

Version control is a common failure point. The worst case is a team emailing around “Report_v3_final_JMM_edits_final2.docx.” The fix is a single source of truth — a shared document, or a Git-tracked LaTeX project — with one person responsible for maintaining it. Collaborative tools with tracked changes and comments should be used from the start of the draft, not only at the end.

Review cycles benefit from explicit rules about who reads what and what they are looking for. A team that separates developmental review (does the argument work?) from copyediting (is the prose clean?) from proofreading (typos) and does them in that order avoids polishing prose that later gets cut. Meetings are useful for decisions that cannot be made asynchronously — the main argument, a structural disagreement, a choice between options — and less useful for drafting or polishing, which are individual work.

Conflict happens. Authors disagree; reviewers cut beloved sections; co-authors miss deadlines. The remedies are boring and effective: name the disagreement, separate technical content from personal stakes, defer to audience and purpose, escalate if needed.

A last thought on revision, where writers improve the most. The first draft’s job is to get something on the page. The second draft reorganizes — moving sections, cutting what does not serve the argument, confirming the pyramid. The third tightens sentences and makes prose flow. The fourth proofreads. Trying to do all four at once is why writing feels paralyzing; doing them in order is why some people write quickly. Engineers known as good writers are usually those who revise the most, not those whose first drafts are best. Revision is a skill anyone can practice, and a course that teaches it hands students a tool they will use for the rest of their careers.