{"id":276,"date":"2025-09-03T14:36:45","date_gmt":"2025-09-03T18:36:45","guid":{"rendered":"https:\/\/opentextbooks.concordia.ca\/practical-guide-to-technical-writing\/?post_type=chapter&p=276"},"modified":"2026-02-20T18:31:04","modified_gmt":"2026-02-20T23:31:04","slug":"chapter-1-introduction-to-technical-communication","status":"publish","type":"chapter","link":"https:\/\/opentextbooks.concordia.ca\/practical-guide-to-technical-writing\/chapter\/chapter-1-introduction-to-technical-communication\/","title":{"raw":"Chapter 1: Introduction to Technical Communication","rendered":"Chapter 1: Introduction to Technical Communication"},"content":{"raw":"
\r\n\r\nChapter Contents<\/span>The Role of Technical Communication in Engineering<\/a>Identifying Purpose, Audience, and Genre<\/a>Key Takeaways<\/a>Practice Task<\/a>Case Study<\/a>\r\n\r\n<\/div>\r\n

The Role of Technical Communication in Engineering<\/strong><\/span><\/h1>\r\nTechnical 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.\r\n
\r\n
\r\n\r\n[caption id=\"attachment_1009\" align=\"alignnone\" width=\"5472\"]\"\" Photo by Headway<\/a> on Unsplash<\/a>[\/caption]\r\n\r\n<\/div>\r\n<\/div>\r\n

Identifying Purpose, Audience, and Genre<\/strong><\/span><\/h1>\r\nUnderstanding purpose, audience, and genre is essential for effective technical writing. Your purpose<\/strong> defines why you are writing.\u00a0 For example, are you explaining a design, persuading stakeholders of the value of project, or documenting a process? Your audience<\/strong> determines the level of technical detail and the style of language you use. Are you addressing fellow engineers, clients, or the public? The genre<\/strong>\u2014or type of document or communication used (e.g., technical report, proposal, or email)\u2014also determines the format, tone, and structure of your message.\r\n\r\nBy 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\u2019s take a closer look at each of these three dimensions: purpose, audience, and genre.\r\n

Purpose<\/strong><\/h2>\r\nAll 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\u2014they may have two or more dominant objectives. The key takeaway, however, is that you must clarify your purposes before you begin to write.\r\n

Audience<\/strong><\/h2>\r\nWho are you writing for? The answer to this question has important effects on the content and style of your writing.\u00a0 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.\u00a0 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.\u00a0 Therefore, it\u2019s 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.\r\n

Genre<\/strong><\/h2>\r\nYou may have heard the word genre used in relation to literature or film\u2014the \"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 \u201ccontainer\u201d 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.\r\n\r\nTo 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 \u201cintroduction,\u201d 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\u2014an idea that will be tested empirically. In the \u201cmethods,\u201d the author lays out what was done in the experiment, including the materials used and the procedures followed. In the \u201cresults,\u201d observable or measurable findings are presented. Finally, in the \u201cdiscussion,\u201d 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<\/span> lists some common genres of engineering communication, along with their purposes.\r\n

Table 1.1<\/span> Common Genres in Engineering Communication and their Purposes.<\/p>\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n
Genre<\/th>\r\nPurpose<\/th>\r\n<\/tr>\r\n<\/thead>\r\n
Business proposals<\/td>\r\nTo outline a business plan to seek investment or partnerships<\/td>\r\n<\/tr>\r\n
Feasibility studies<\/td>\r\nTo assess the practicality and viability of a proposed project or solution<\/td>\r\n<\/tr>\r\n
Grant proposals<\/td>\r\nTo seek funding for research or development projects<\/td>\r\n<\/tr>\r\n
Instructional manuals<\/td>\r\nTo provide instructions and guidance on the use and operation of tools or equipment<\/td>\r\n<\/tr>\r\n
Progress reports<\/td>\r\nTo track the progress of a project, highlighting achievements, and identifying challenges<\/td>\r\n<\/tr>\r\n
Research reports<\/td>\r\nTo document original research findings, methodologies, and conclusions<\/td>\r\n<\/tr>\r\n
Specifications<\/td>\r\nTo provide detailed descriptions of the requirements and characteristics of a product or system<\/td>\r\n<\/tr>\r\n
Technical presentations<\/td>\r\nTo communicate technical information to audiences through oral presentations<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\nPerhaps 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 \u201cresearcher\u201d 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.\r\n
\r\n

Key Takeaways<\/h2>\r\n<\/header>\r\n
\r\n\r\n\"\"\r\n

In the end, it\u2019s your job to make yourself understood. Your writing process should always begin with upfront analysis:<\/p>\r\n\r\n

    \r\n \t
  1. Identify your purposes in writing.<\/li>\r\n \t
  2. Plan for your audience's needs.<\/li>\r\n \t
  3. Establish the best genre through which to convey your ideas.<\/li>\r\n<\/ol>\r\n

    Keep these points in mind all the way from the conception and planning of the document to the final revisions and editing.<\/p>\r\n\r\n<\/div>\r\n<\/div>\r\n

    \r\n

    Practice Task<\/h2>\r\n<\/header>\r\n
    \"\"Become a researcher of writing in your own field. Search the Web for a well-crafted technical report. Which reader needs are addressed in each section of the report?<\/span><\/span>\u00a0<\/span><\/div>\r\n<\/div>\r\n
    \r\n

    Case Study<\/span><\/span>\u00a0<\/span><\/h2>\r\n<\/header>\r\n
    \r\n

    When Words Kill: The Boeing 737 Max Tragedy<\/strong><\/h4>\r\n
    \r\n\r\nImagine waking up, heading to the airport, and boarding a plane\u2014a 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\u2019s happening or how to stop it.\r\n\r\n<\/div>\r\n
    \r\n\r\nThis is not a hypothetical scenario. It\u2019s exactly what happened on October 29, 2018, when Lion Air Flight 610 (JT 610) <\/span><\/span>plunged into the Java Sea just 13 minutes after takeoff, killing all 189 people on board.\r\n\r\n<\/div>\r\n
    \r\n\r\nThis isn\u2019t just a story about aircraft design or aerodynamics. It\u2019s about something far more fundamental\u2014something that cuts across every industry, every project, and every team: technical communication, and how its failure can have deadly consequences.\r\n
    The Silent Killer<\/strong><\/h5>\r\n
    \r\n\r\nThe 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.\r\n\r\n<\/div>\r\n
    \r\n\r\nIn 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.\r\n\r\n<\/div>\r\n
    \r\n\r\nWhy 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.\r\n\r\n<\/div>\r\n
    \r\n\r\nLives were literally traded for market shares.\r\n\r\n<\/div>\r\n
    \r\n
    Links in a Fatal Chain<\/strong><\/h5>\r\n<\/div>\r\n
    \r\n\r\nThe Indonesian investigation identified five critical factors that led to this disaster, and nearly every single one involved a failure of technical communication.\r\n\r\nOne:<\/strong> A critical sensor, which miscalibrated during earlier repair, was installed without proper testing or documentation.<\/span>\r\n\r\nTwo:<\/strong> 31 pages were missing from the maintenance log\u2014information that should have grounded the plane before its fatal flight.<\/span>\r\n\r\nThree:<\/strong> \u00a0<\/span>The checklist included a long\u2011standing \u2018runaway stabilizer\u2019 procedure that could have addressed the malfunction, but pilots were unaware that the new MCAS system was responsible for causing it.<\/span><\/span>\r\n\r\nFour:<\/strong> The cockpit warning systems provided conflicting information that the pilots couldn't reconcile.<\/span>\r\n\r\n<\/div>\r\n
    \r\n\r\nFive:<\/strong> The previous day's crew experienced the exact same issue but didn't effectively communicate the severity to the maintenance crew.\r\n\r\n<\/div>\r\n
    \r\n\r\nThe 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.\r\n\r\n<\/div>\r\n
    \r\n\r\nThose pilots landed safely. However, that knowledge\u2014that critical, life-saving information\u2014wasn't documented. It wasn't passed on. It wasn't communicated to the next crew.\r\n\r\n<\/div>\r\n
    \r\n\r\nA total of 189 people died because of it.\r\n\r\n<\/div>\r\n
    \r\n
    A Second Chance Missed\u00a0\u00a0<\/strong><\/h5>\r\n<\/div>\r\n
    \r\n\r\nAfter 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.\r\n\r\n<\/div>\r\n
    \r\n\r\nFive months later,\u00a0<\/span>on March 10, 2019<\/span>,<\/span><\/span> Ethiopian Airlines Flight 302 crashed under nearly identical circumstances. 157 more lives were lost.\r\n\r\n<\/div>\r\n
    \r\n\r\nThey were the result of a choice\u2014a choice to prioritize simplicity over safety, profits over people, and, most critically, a choice to withhold information rather than communicate.\r\n\r\n<\/div>\r\n
    \r\n
    The Communication Gap\u00a0\u00a0<\/strong><\/h5>\r\n<\/div>\r\n
    \r\n\r\nA 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.\r\n\r\n<\/div>\r\n
    \r\n\r\nThis is dangerously wrong.\r\n\r\n<\/div>\r\n
    \r\n\r\nThe 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.\r\n\r\n<\/div>\r\n
    \r\n\r\nAnd understanding can save lives.\r\n\r\n<\/div>\r\n
    \r\n
    The Responsibility We All Share<\/strong><\/h5>\r\n<\/div>\r\n
    \r\n\r\nSo, what do we do about this? How do we prevent the next Lion Air disaster in our own fields?\r\n\r\n<\/div>\r\n
    \r\n\r\nFirst, 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.\r\n\r\n<\/div>\r\n
    \r\n\r\nSecond, 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.\r\n\r\n<\/div>\r\n
    \r\n\r\nThird, 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.\r\n\r\n<\/div>\r\n
    \r\n\r\nFourth, we need to create cultures where communication is valued as highly as innovation\u2014where an engineer who writes clear documentation is celebrated as much as one who writes clever code.\r\n\r\n<\/div>\r\n
    \r\n\r\nHistory is filled with communication failures as dramatic and as preventable as Boeing\u2019s. 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.\r\n\r\n<\/div>\r\n
    \r\n
    Your Turn\u00a0\u00a0<\/strong><\/h5>\r\n<\/div>\r\n
    \r\n\r\nAs 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 \u201cthey'll figure out\u201d when the stakes are high?\r\n\r\n<\/div>\r\n
    \r\n\r\nMost importantly: What am I not communicating that could cost someone everything?\r\n\r\n<\/div>\r\n
    \r\n\r\nThe 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.\r\n\r\n<\/div>\r\n
    \r\n\r\nThe 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.\r\n\r\n<\/div>\r\n
    \r\n\r\nDon't let that happen on your watch.\r\n\r\n<\/div>\r\n
    \r\n\r\nBecause the most dangerous words in any industry aren't \"I don't know.\" They're \"I didn't tell you.\"<\/span>\r\n\r\n<\/div>\r\n<\/div>\r\n<\/div>\r\n<\/div>\r\n ","rendered":"
    \n

    Chapter Contents<\/span>The Role of Technical Communication in Engineering<\/a>Identifying Purpose, Audience, and Genre<\/a>Key Takeaways<\/a>Practice Task<\/a>Case Study<\/a><\/p>\n<\/div>\n

    The Role of Technical Communication in Engineering<\/strong><\/span><\/h1>\n

    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.<\/p>\n

    \n
    \n
    \"\"
    Photo by Headway<\/a> on Unsplash<\/a><\/figcaption><\/figure>\n<\/div>\n<\/div>\n

    Identifying Purpose, Audience, and Genre<\/strong><\/span><\/h1>\n

    Understanding purpose, audience, and genre is essential for effective technical writing. Your purpose<\/strong> defines why you are writing.\u00a0 For example, are you explaining a design, persuading stakeholders of the value of project, or documenting a process? Your audience<\/strong> determines the level of technical detail and the style of language you use. Are you addressing fellow engineers, clients, or the public? The genre<\/strong>\u2014or type of document or communication used (e.g., technical report, proposal, or email)\u2014also determines the format, tone, and structure of your message.<\/p>\n

    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\u2019s take a closer look at each of these three dimensions: purpose, audience, and genre.<\/p>\n

    Purpose<\/strong><\/h2>\n

    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\u2014they may have two or more dominant objectives. The key takeaway, however, is that you must clarify your purposes before you begin to write.<\/p>\n

    Audience<\/strong><\/h2>\n

    Who are you writing for? The answer to this question has important effects on the content and style of your writing.\u00a0 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.\u00a0 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.\u00a0 Therefore, it\u2019s 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.<\/p>\n

    Genre<\/strong><\/h2>\n

    You may have heard the word genre used in relation to literature or film\u2014the “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 \u201ccontainer\u201d 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.<\/p>\n

    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 \u201cintroduction,\u201d 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\u2014an idea that will be tested empirically. In the \u201cmethods,\u201d the author lays out what was done in the experiment, including the materials used and the procedures followed. In the \u201cresults,\u201d observable or measurable findings are presented. Finally, in the \u201cdiscussion,\u201d 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<\/span> lists some common genres of engineering communication, along with their purposes.<\/p>\n

    Table 1.1<\/span> Common Genres in Engineering Communication and their Purposes.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n
    Genre<\/th>\nPurpose<\/th>\n<\/tr>\n<\/thead>\n
    Business proposals<\/td>\nTo outline a business plan to seek investment or partnerships<\/td>\n<\/tr>\n
    Feasibility studies<\/td>\nTo assess the practicality and viability of a proposed project or solution<\/td>\n<\/tr>\n
    Grant proposals<\/td>\nTo seek funding for research or development projects<\/td>\n<\/tr>\n
    Instructional manuals<\/td>\nTo provide instructions and guidance on the use and operation of tools or equipment<\/td>\n<\/tr>\n
    Progress reports<\/td>\nTo track the progress of a project, highlighting achievements, and identifying challenges<\/td>\n<\/tr>\n
    Research reports<\/td>\nTo document original research findings, methodologies, and conclusions<\/td>\n<\/tr>\n
    Specifications<\/td>\nTo provide detailed descriptions of the requirements and characteristics of a product or system<\/td>\n<\/tr>\n
    Technical presentations<\/td>\nTo communicate technical information to audiences through oral presentations<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    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 \u201cresearcher\u201d 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.<\/p>\n

    \n
    \n

    Key Takeaways<\/h2>\n<\/header>\n
    \n

    \"\"<\/p>\n

    In the end, it\u2019s your job to make yourself understood. Your writing process should always begin with upfront analysis:<\/p>\n

      \n
    1. Identify your purposes in writing.<\/li>\n
    2. Plan for your audience’s needs.<\/li>\n
    3. Establish the best genre through which to convey your ideas.<\/li>\n<\/ol>\n

      Keep these points in mind all the way from the conception and planning of the document to the final revisions and editing.<\/p>\n<\/div>\n<\/div>\n

      \n
      \n

      Practice Task<\/h2>\n<\/header>\n
      \"\"Become a researcher of writing in your own field. Search the Web for a well-crafted technical report. Which reader needs are addressed in each section of the report?<\/span><\/span>\u00a0<\/span><\/div>\n<\/div>\n
      \n
      \n

      Case Study<\/span><\/span>\u00a0<\/span><\/h2>\n<\/header>\n
      \n

      When Words Kill: The Boeing 737 Max Tragedy<\/strong><\/h4>\n
      \n

      Imagine waking up, heading to the airport, and boarding a plane\u2014a 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\u2019s happening or how to stop it.<\/p>\n<\/div>\n

      \n

      This is not a hypothetical scenario. It\u2019s exactly what happened on October 29, 2018, when Lion Air Flight 610 (JT 610) <\/span><\/span>plunged into the Java Sea just 13 minutes after takeoff, killing all 189 people on board.<\/p>\n<\/div>\n

      \n

      This isn\u2019t just a story about aircraft design or aerodynamics. It\u2019s about something far more fundamental\u2014something that cuts across every industry, every project, and every team: technical communication, and how its failure can have deadly consequences.<\/p>\n

      The Silent Killer<\/strong><\/h5>\n
      \n

      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.<\/p>\n<\/div>\n

      \n

      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.<\/p>\n<\/div>\n

      \n

      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.<\/p>\n<\/div>\n

      \n

      Lives were literally traded for market shares.<\/p>\n<\/div>\n

      \n
      Links in a Fatal Chain<\/strong><\/h5>\n<\/div>\n
      \n

      The Indonesian investigation identified five critical factors that led to this disaster, and nearly every single one involved a failure of technical communication.<\/p>\n

      One:<\/strong> A critical sensor, which miscalibrated during earlier repair, was installed without proper testing or documentation.<\/span><\/p>\n

      Two:<\/strong> 31 pages were missing from the maintenance log\u2014information that should have grounded the plane before its fatal flight.<\/span><\/p>\n

      Three:<\/strong> \u00a0<\/span>The checklist included a long\u2011standing \u2018runaway stabilizer\u2019 procedure that could have addressed the malfunction, but pilots were unaware that the new MCAS system was responsible for causing it.<\/span><\/span><\/p>\n

      Four:<\/strong> The cockpit warning systems provided conflicting information that the pilots couldn’t reconcile.<\/span><\/p>\n<\/div>\n

      \n

      Five:<\/strong> The previous day’s crew experienced the exact same issue but didn’t effectively communicate the severity to the maintenance crew.<\/p>\n<\/div>\n

      \n

      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.<\/p>\n<\/div>\n

      \n

      Those pilots landed safely. However, that knowledge\u2014that critical, life-saving information\u2014wasn’t documented. It wasn’t passed on. It wasn’t communicated to the next crew.<\/p>\n<\/div>\n

      \n

      A total of 189 people died because of it.<\/p>\n<\/div>\n

      \n
      A Second Chance Missed\u00a0\u00a0<\/strong><\/h5>\n<\/div>\n
      \n

      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.<\/p>\n<\/div>\n

      \n

      Five months later,\u00a0<\/span>on March 10, 2019<\/span>,<\/span><\/span> Ethiopian Airlines Flight 302 crashed under nearly identical circumstances. 157 more lives were lost.<\/p>\n<\/div>\n

      \n

      They were the result of a choice\u2014a choice to prioritize simplicity over safety, profits over people, and, most critically, a choice to withhold information rather than communicate.<\/p>\n<\/div>\n

      \n
      The Communication Gap\u00a0\u00a0<\/strong><\/h5>\n<\/div>\n
      \n

      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.<\/p>\n<\/div>\n

      \n

      This is dangerously wrong.<\/p>\n<\/div>\n

      \n

      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.<\/p>\n<\/div>\n

      \n

      And understanding can save lives.<\/p>\n<\/div>\n

      \n
      The Responsibility We All Share<\/strong><\/h5>\n<\/div>\n
      \n

      So, what do we do about this? How do we prevent the next Lion Air disaster in our own fields?<\/p>\n<\/div>\n

      \n

      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.<\/p>\n<\/div>\n

      \n

      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.<\/p>\n<\/div>\n

      \n

      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.<\/p>\n<\/div>\n

      \n

      Fourth, we need to create cultures where communication is valued as highly as innovation\u2014where an engineer who writes clear documentation is celebrated as much as one who writes clever code.<\/p>\n<\/div>\n

      \n

      History is filled with communication failures as dramatic and as preventable as Boeing\u2019s. 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.<\/p>\n<\/div>\n

      \n
      Your Turn\u00a0\u00a0<\/strong><\/h5>\n<\/div>\n
      \n

      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 \u201cthey’ll figure out\u201d when the stakes are high?<\/p>\n<\/div>\n

      \n

      Most importantly: What am I not communicating that could cost someone everything?<\/p>\n<\/div>\n

      \n

      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.<\/p>\n<\/div>\n

      \n

      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.<\/p>\n<\/div>\n

      \n

      Don’t let that happen on your watch.<\/p>\n<\/div>\n

      \n

      Because the most dangerous words in any industry aren’t “I don’t know.” They’re “I didn’t tell you.”<\/span><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

       <\/p>\n","protected":false},"author":98,"menu_order":1,"template":"","meta":{"pb_show_title":"on","pb_short_title":"","pb_subtitle":"","pb_authors":[],"pb_section_license":""},"chapter-type":[],"contributor":[],"license":[],"class_list":["post-276","chapter","type-chapter","status-publish","hentry"],"part":188,"_links":{"self":[{"href":"https:\/\/opentextbooks.concordia.ca\/practical-guide-to-technical-writing\/wp-json\/pressbooks\/v2\/chapters\/276","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/opentextbooks.concordia.ca\/practical-guide-to-technical-writing\/wp-json\/pressbooks\/v2\/chapters"}],"about":[{"href":"https:\/\/opentextbooks.concordia.ca\/practical-guide-to-technical-writing\/wp-json\/wp\/v2\/types\/chapter"}],"author":[{"embeddable":true,"href":"https:\/\/opentextbooks.concordia.ca\/practical-guide-to-technical-writing\/wp-json\/wp\/v2\/users\/98"}],"version-history":[{"count":61,"href":"https:\/\/opentextbooks.concordia.ca\/practical-guide-to-technical-writing\/wp-json\/pressbooks\/v2\/chapters\/276\/revisions"}],"predecessor-version":[{"id":1517,"href":"https:\/\/opentextbooks.concordia.ca\/practical-guide-to-technical-writing\/wp-json\/pressbooks\/v2\/chapters\/276\/revisions\/1517"}],"part":[{"href":"https:\/\/opentextbooks.concordia.ca\/practical-guide-to-technical-writing\/wp-json\/pressbooks\/v2\/parts\/188"}],"metadata":[{"href":"https:\/\/opentextbooks.concordia.ca\/practical-guide-to-technical-writing\/wp-json\/pressbooks\/v2\/chapters\/276\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/opentextbooks.concordia.ca\/practical-guide-to-technical-writing\/wp-json\/wp\/v2\/media?parent=276"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/opentextbooks.concordia.ca\/practical-guide-to-technical-writing\/wp-json\/pressbooks\/v2\/chapter-type?post=276"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/opentextbooks.concordia.ca\/practical-guide-to-technical-writing\/wp-json\/wp\/v2\/contributor?post=276"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/opentextbooks.concordia.ca\/practical-guide-to-technical-writing\/wp-json\/wp\/v2\/license?post=276"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}