Chapter 1: Introduction to Technical Communication
The Role of Technical Communication in Engineering
Technical communication for engineers refers to the process of conveying complex technical information in a clear, precise, and accessible manner to a variety of audiences. Engineers must communicate effectively to ensure that their designs, analyses, and solutions are understood by their colleagues, clients, regulatory bodies, and the public. In the end, it ensures safety, compliance, and efficiency in engineering projects.
Identifying Purpose, Audience, and Genre
Understanding purpose, audience, and genre is essential for effective technical writing. Your purpose defines why you are writing. For example, are you explaining a design, persuading stakeholders of the value of project, or documenting a process? Your audience determines the level of technical detail and the style of language you use. Are you addressing fellow engineers, clients, or the public? The genre—or type of document or communication used (e.g., technical report, proposal, or email)—also determines the format, tone, and structure of your message.
By considering these elements before you write, you will make your communication clearer and more relevant for others. This upfront analysis saves time and ensures your writing fits the situation. Let’s take a closer look at each of these three dimensions: purpose, audience, and genre.
Purpose
All communication serves specific purposes. In the technical fields, your writing might aim to persuade, request, instruct, inform, or evaluate. For example, proposals attempt to persuade clients to accept a solution to a defined problem; technical manuals instruct users how to perform tasks; and reports may evaluate different technical solutions to engineering challenges. Of course, most technical documents serve more than one purpose—they may have two or more dominant objectives. The key takeaway, however, is that you must clarify your purposes before you begin to write.
Audience
Who are you writing for? The answer to this question has important effects on the content and style of your writing. For readers who are not specialists in your field, you may have to use less technical vocabulary, or if you use technical terms, you will need to clearly define what they mean. You may also need to provide longer explanations and concrete examples to help your readers understand. On the other hand, if your readers are also specialists in the field, you can assume a great deal more shared knowledge. The reality, though, is that technical professionals, more often than not, present ideas to people who have less technical knowledge. Business managers or clients, for example, might read technical reports. Therefore, it’s essential that you take their interests and needs into account. After all, if you lose the support of key stakeholders in a project simply because your ideas were not presented in audience-friendly terms, everyone loses out.
Genre
You may have heard the word genre used in relation to literature or film—the “horror film” genre, for example. However, the same term can be applied to different conventional forms of technical or professional communication. Think of genre as a conceptual “container” whose form has been collectively agreed upon over years of use. You might say that genres of engineering writing exist because they efficiently respond to reader needs in situations that arise repeatedly. By adhering to genre conventions, you ensure that your ideas are presented in a form that is recognizable and familiar to your audience. What’s more, readers will likely expect information to be conveyed in a conventional form.
To clarify this concept, take the example of a lab report. The lab report is a genre that many students encounter during their university studies. Lab reports are recognizable as such because they share features of content and form. Think for a moment about the “introduction,” where the author sets the scene. Important background information and context are provided, as are the goals of the experiment. Perhaps a hypothesis is put forward—an idea that will be tested empirically. In the “methods,” the author lays out what was done in the experiment, including the materials used and the procedures followed. In the “results,” observable or measurable findings are presented. Finally, in the “discussion,” those results are interpreted. Writers who ignore genre conventions do so at their own risk. For example, a research writer who interprets results before clearly laying out the procedures will confuse or frustrate readers. Table 1.1 lists some common genres of engineering communication, along with their purposes.
Table 1.1 Common Genres in Engineering Communication and their Purposes.
| Genre | Purpose |
|---|---|
| Business proposals | To outline a business plan to seek investment or partnerships |
| Feasibility studies | To assess the practicality and viability of a proposed project or solution |
| Grant proposals | To seek funding for research or development projects |
| Instructional manuals | To provide instructions and guidance on the use and operation of tools or equipment |
| Progress reports | To track the progress of a project, highlighting achievements, and identifying challenges |
| Research reports | To document original research findings, methodologies, and conclusions |
| Specifications | To provide detailed descriptions of the requirements and characteristics of a product or system |
| Technical presentations | To communicate technical information to audiences through oral presentations |
Perhaps you can think of other genres from your own subfield of engineering or computer science. Regardless, a challenge you should embrace is to search out models of these different types of writing and become a “researcher” of writing in your own field. By looking at numerous examples with an analytical eye, you will greatly improve your ability to craft writing in a recognized form and style.
Key Takeaways
In the end, it’s your job to make yourself understood. Your writing process should always begin with upfront analysis:
- Identify your purposes in writing.
- Plan for your audience’s needs.
- Establish the best genre through which to convey your ideas.
Keep these points in mind all the way from the conception and planning of the document to the final revisions and editing.
Practice Task
Case Study
When Words Kill: The Boeing 737 Max Tragedy
Imagine waking up, heading to the airport, and boarding a plane—a routine experience for many of us. Now, imagine that the pilot flying your plane is unaware of a critical control system on board, a system that can suddenly take control and force the aircraft toward the ground. Imagine further that when this system activates, there is nothing in the manual to explain what’s happening or how to stop it.
This is not a hypothetical scenario. It’s exactly what happened on October 29, 2018, when Lion Air Flight 610 (JT 610) plunged into the Java Sea just 13 minutes after takeoff, killing all 189 people on board.
This isn’t just a story about aircraft design or aerodynamics. It’s about something far more fundamental—something that cuts across every industry, every project, and every team: technical communication, and how its failure can have deadly consequences.
The Silent Killer
The Boeing 737 MAX featured a new system called the Maneuvering Characteristics Augmentation System (MCAS). It was designed to automatically push the nose down if it detected the plane might stall. However, the pilots didn’t know that it existed.
In the entire 1,600-page flight manual, MCAS was mentioned only in the glossary. No explanation of what it did. No instructions on how to disable it. Nothing.
Why would Boeing omit such critical information? The answer reveals something troubling about how we communicate in high-stakes industries. Boeing wanted to market the 737 MAX as requiring minimal additional training for pilots who had flown previous 737 models. More documentation meant more training. More training meant higher costs. Higher costs meant fewer sales.
Lives were literally traded for market shares.
Links in a Fatal Chain
The Indonesian investigation identified five critical factors that led to this disaster, and nearly every single one involved a failure of technical communication.
One: A critical sensor, which miscalibrated during earlier repair, was installed without proper testing or documentation.
Two: 31 pages were missing from the maintenance log—information that should have grounded the plane before its fatal flight.
Three: The checklist included a long‑standing ‘runaway stabilizer’ procedure that could have addressed the malfunction, but pilots were unaware that the new MCAS system was responsible for causing it.
Four: The cockpit warning systems provided conflicting information that the pilots couldn’t reconcile.
Five: The previous day’s crew experienced the exact same issue but didn’t effectively communicate the severity to the maintenance crew.
The day before the crash, a pilot traveling as a passenger in the jump seat of the same aircraft recognized the issue and explained to the flight crew how to disable the system.
Those pilots landed safely. However, that knowledge—that critical, life-saving information—wasn’t documented. It wasn’t passed on. It wasn’t communicated to the next crew.
A total of 189 people died because of it.
A Second Chance Missed
After the Lion Air crash, Boeing finally issued a bulletin explaining the MCAS and how to disable it. However, they insisted the 737 MAX was still safe to fly without further changes.
Five months later, on March 10, 2019, Ethiopian Airlines Flight 302 crashed under nearly identical circumstances. 157 more lives were lost.
They were the result of a choice—a choice to prioritize simplicity over safety, profits over people, and, most critically, a choice to withhold information rather than communicate.
The Communication Gap
A dangerous myth exists in engineering and the technical fields: that good technical work speaks for itself. That the data tells its own story. That if something is important, people will figure it out.
This is dangerously wrong.
The hard truth is this: Your brilliant design, your revolutionary code, your groundbreaking research is worthless if you can’t communicate it effectively. Technical communication isn’t just about transferring information. It’s about transferring understanding.
And understanding can save lives.
The Responsibility We All Share
So, what do we do about this? How do we prevent the next Lion Air disaster in our own fields?
First, we need to recognize that technical communication is not an afterthought. It’s not something to be delegated to technical writers after the real work is done. It is the real work.
Second, we need to document for crisis, not for convenience. The true test of technical documentation isn’t whether it works when everything goes right. It’s whether it works when everything goes wrong.
Third, we must understand our audiences very well. The Boeing case shows the fatal consequences of one-size-fits-all documentation practices. The engineers wrote for other engineers, not for pilots in crisis situations. They assumed technical knowledge that didn’t exist. They failed to consider how pilots would use this information under extreme stress. Knowing your audience, their knowledge level, and their needs isn’t optional. It’s essential. Different audiences require different approaches, and assuming that one type of writing works for everyone is a dangerous mistake.
Fourth, we need to create cultures where communication is valued as highly as innovation—where an engineer who writes clear documentation is celebrated as much as one who writes clever code.
History is filled with communication failures as dramatic and as preventable as Boeing’s. In the 2003 Columbia Space Shuttle disaster, poorly designed PowerPoint slides obscured critical safety information that might have saved the lives of seven astronauts [1]. Similarly, the 1981 Hyatt Regency walkway collapse in Kansas City, which killed 114 people, was partly the result of unclear communication between engineers and fabricators about a seemingly minor design change [2]. These are just two additional examples, but there are countless other tragedies where poor communication played a decisive role.
Your Turn
As an engineer, you must continually ask yourself: What critical information am I holding right now? What knowledge seems obvious to me but might be invisible to someone else? What am I assuming “they’ll figure out” when the stakes are high?
Most importantly: What am I not communicating that could cost someone everything?
The 346 people who died in the two 737 MAX crashes can’t speak to us. But their story can. It tells us that in a world of increasingly complex systems, our greatest vulnerability isn’t technical failure. It’s a communication breakdown.
The pilots of those Boeing planes were fighting not just a malfunctioning system, but a vacuum of information. They were trying to solve a problem they didn’t know existed, with tools they didn’t know they had.
Don’t let that happen on your watch.
Because the most dangerous words in any industry aren’t “I don’t know.” They’re “I didn’t tell you.”
