In Chapter 1 we made three claims: (1) technical presentation is challenging, (2) you’re going to need to do it, and (3) you should learn to do it well. The rest of the book is concerned with doing it well. We also suggested you view technical presentations as projects that can be tackled using the same engineering design principles you have become accustomed to and comfortable with. As we probably needn’t remind you, these principles have been wildly successful, producing space shuttles, nuclear power plants, and global positioning systems. We think they can be just as successful in producing technical presentations. So, we’ll start by reviewing the basic principles of engineering design, and then see if we can’t make our case for applying them to “engineer” a presentation.
2.1 Quick Review of Some Design Concepts
The engineering design process is often depicted as a flow diagram. Figure 2.1 shows its main stages, which are1
1. Understand the goal.
2. Conduct research.
3. Generate possible solutions.
4. Choose a solution and implement it.
5. Evaluate, and improve if necessary.
We believe these steps can be adapted to virtually any formal presentation task, and can be your guide when preparing for a substantial speaking engagement.
FIGURE 2.1
Flowchart representation of the typical engineering design process.
Mark, a graduate student in mechanical engineering, has finished writing his thesis. It’s now time for Mark to defend it in front of his committee and, possibly, an additional audience of invited guests. As the days pass, Mark begins to wonder how he will perform under this much pressure. If he can’t summarize and defend his results successfully, the four long years he invested in his research will be at risk.
Suppose some important aspect of your future hinges on a single technical presentation. How can you increase your chances of success? We’ll address this question throughout the book. The key is to place this task in an appropriate mental framework, and we choose as that framework the standard engineering design process.
Dr. Stratton, Mark’s thesis advisor, reminds Mark of all the hard work that he has put in up to this point. How could he let worries over giving a presentation cancel out so many years of effort? He also reminds Mark that he is beginning a professional life in which formal public speaking is a key component that cannot be avoided. “You’re an engineer,” says Professor Stratton, “remember that the word engineer is derived from the Latin word for ingenuity. You’ll figure it out, just like you figured everything else out.” This switches Mark into an engineering mode: “I have a definite problem to solve here. That problem involves standing up and speaking, but it’s still a problem and I can solve it just like I solve other engineering problems.” He starts to think about how to apply his knowledge of problem solving to help with his presentation. “How could I design a presentation strategy to solve my problem?”
Mark is on the verge of an epiphany. In fact, it’s the same epiphany that Steve from Chapter 1 had regarding technical presentations. By using familiar engineering design concepts, he can clear any major technical hurdle, including his thesis defense.
After reviewing the design concepts cited above, Mark responds by drafting a plan as follows.
1. Understand the goal. Mark has 30 minutes to present his principal research results, followed by an undetermined period in which he may have to field some tough questions from his examination committee. His professional future hinges on making a proper impression on this audience.
2. Conduct research. Mark must clearly understand the problem he faces. He must keep two crucial terms in mind: presentation and defense. Of the many interesting results he obtained over the last four years, which ones are the most significant? Will all of the members of his committee understand why they are significant? (One member of the committee is a mathematician, not an engineer.) At what level of detail should he present the information? How many diagrams should he show, and how many equations? Should he read every symbol in each equation, or merely point to the equation as though it is self-explanatory? Should he display snippets of computer code? Where should he start: with fundamental concepts, or with the crown jewel of his final results? In short, how long is 30 minutes in this sort of situation, and how is it used to one’s best advantage? Mark still has contact information for a few former students who recently defended their theses successfully. Should he call them for advice? Are there any books or good websites with information on all this?
3. Generate possible solutions. While Mark can safely settle on just one approach to his presentation, he understands he will have to develop a set of alternative approaches to the question-and-answer phase. Depending on their moods that day (and, of course, on how well Mark performs in the presentation phase), the audience may turn out to be friendly or somewhat hostile. Furthermore, it is possible that some razor-sharp outsiders may attend and ask unforeseen questions. Rather than planning to generate workable responses to just one scenario, Mark follows the standard design process and plans to generate multiple potential responses and modes of response.
4. Choose a solution and implement it. Evaluate, and improve if necessary. For Mark, this choice will have to be made partially in real time. This is one aspect in which speaking before a live audience differs from writing. He can settle into a well-planned presentation, but he must be ready for a number of possibilities during the question-and-answer phase.
Mark will have to prepare slides, rehearse, solicit feedback from others, evaluate their comments, rehearse again, try to obtain feedback again, and so on. Some feedback will come during the talk itself; in this case Mark will have to re-evaluate and refine “on the fly.”
By adapting Figure 2.1 to his purposes, Mark has generated a basic but essentially complete roadmap for himself. He knows that by following it he can successfully defend his thesis, and for the first time feels confident about speaking in public. Mark thinks of all the hard work he has put in during graduate school. He senses that he might finally hear those magic words, “Congratulations, Mark. You passed!”
As an engineer, you can adapt your speaking tasks along these same lines. Whether you’re preparing a briefing for your manager, a senior project presentation, or even a dissertation defense, a design-based approach will help you prepare, control nervousness, and actually enjoy giving your talk. So let’s delve more deeply into some of the fundamental aspects of the design process.
Top-Down and Bottom-Up Approaches to Design
Given a design task, we may decompose it into subtasks and then break down those subtasks, continuing until we are satisfied with the level of decomposition. This idea is the basis of the top-down design approach (Figure 2.2).
FIGURE 2.2
Notion of top-down design. Left: Top-level view of system to be designed. Right: Breakdown of required system into subsystems, shown as blocks a, b, c, d here. In the analysis phase, each subsystem is further decomposed until the concrete design stages are reached. During the synthesis phase, the completed subsystems are assembled into the required system. The basic idea is divide and conquer.
For example, an engineer might dissect an air conditioning system into a compressor, a blower, an accumulator, an evaporator, and a condenser. The compressor in turn could be decomposed into a crankshaft, connecting rod, piston, discharge valve, and discharge line. Lower level subsystems are then designed and assembled into subsystems at the next higher level until the whole system is complete. This approach — analysis followed by synthesis — is strongly advocated as an engineering design approach and can be easily applied to the design of significant formal presentations.
Mark decides to take a top-down approach with the presentation phase of his defense. He begins by realizing that he will need a short introductory statement, the main body of the presentation, and at least a brief concluding statement before the questions begin. He ponders the various possible ways to introduce himself and his research area, looking for something efficient but not terse or off-putting to a mixed technical audience. Estimating that 25 minutes will remain for the meat of his presentation, he turns to the principal result of his research, a new relation pertaining to turbulent fluid flow near an irregular boundary. Estimating that it will take 5 minutes to state the result and its immediate corollaries, Mark realizes he can allocate 20 minutes to background material that supports the main theorem. Continuing to decompose this available time into five-minute segments, Mark sees that he can cover just four of the most important background topics.
In contrast, consider the less focused approach of the “idea engineer” who is hired to come up with new concepts, gadgets, or procedures. He might fool around with an electronic circuit with no particular end goal in mind, and find that he can make it do something unexpected. He couples the new circuit into a system he has designed previously and improves the efficiency of the system dramatically. He can now put the system to use in situations where cost would have been prohibitive, and through this sequence of unguided events completely revolutionize the industry. The design process described here does not fit the top-down category but is a design approach nonetheless. While bottom-up design is less conventional than the top-down paradigm discussed above, it allows more room for creative adaptation and often leads to major breakthroughs (and an equal number of complete flops). Many people, including speakers and writers, prefer to work in bottom-up mode. When you find yourself stuck early in the planning of a major speaking task, try shifting into low gear and dumping your material into an electronic document so you can play with it. Move things around, reword them, insert dummy placeholders, etc., until organization begins to emerge. Small successes can lead to larger successes, and don’t be surprised if a sensible presentation evolves.
Mark realizes he cannot “plan” the question-and-answer portion of his defense. What he can do is try to anticipate the most difficult questions that are likely to arise. Switching to bottom-up mode, Mark begins to collect answers to potential questions as he thinks of them. Several days later, he has accumulated a file full of efficient (and sometimes even evasive) answers. He composes several extra slides that anticipate the questions, and appends these to the end of his presentation in case they are needed.
As we see, a full design process can take the form of a hybrid approach with both top-down and bottom-up elements. Engineering is about what works.
A crucial element of both approaches is iterative improvement. Iterative means repetitive; it refers to an approach where successive attempts are made, each one building on the previous one. You start with your chosen solution and take successive cuts at improving it until it meets the standards for completion (recall Figure 2.1). This is how you should approach the preparation of your technical presentation. You will also use iterative improvement to polish your delivery through rehearsal.
Notion of Concurrent Design
Imagine an engineering team charged with developing a new entry in a successful product line. They work very hard for several months on a specific design, only to learn that it cannot meet industry standards for post-consumer disposal. This is a risk of the sequential design approach. First the engineers work in isolation and only later get input and advice from other professionals who have an impact on the success of the project. Contrast this with a design team that integrates experts in marketing, manufacturing, disposal, and so on, at the outset of the project. This approach is called concurrent design.
You probably won’t have the luxury of assembling a team of experts to help you prepare for a speaking engagement. Nonetheless, the basic idea of getting information and early feedback certainly applies. If you must speak in an auditorium, for example, it may be wise to practice in a similar room before the big day arrives. Rooms differ widely in their lighting and acoustical properties. A huge room may even require the use of a microphone and sound system. Early awareness of such factors can be quite helpful. You may also seek feedback, rehearsing in front of people in (or close to) the target audience and asking for reactions. Their suggestions, if addressed early in the preparation process, could prevent headaches later on.
Having planned the presentation phase of his defense, Mark rehearses and gets feedback from the other students in his group. Fortunately, one of the students who developed part of Mark’s experimental procedure manages to catch an error in Mark’s explanation. Mark corrects the error and thinks, “Wow, I’m glad I didn’t make that blunder in front of Dr. Stratton!” The next day, Mark rehearses in front of the professor and receives plaudits for an excellent practice presentation. Mark is deemed ready to schedule his defense.
2.2 Framing the Goal of Your Technical Presentation
When engineers speak professionally it is primarily to communicate thoughts and ideas rather than, say, to emote or to entertain. This is not to say that technical speaking must be robotic or sterile; it’s important to have one’s passion for a topic shine through in a presentation. But the primary goal of technical speaking is to inform. We must tell our listeners who, what, where, when, why, and how. In the process, however, we cannot afford to forget the listeners themselves. We must keep the backgrounds, needs, and purposes of the audience firmly in mind at all times. We are speaking to inform, not simply to “talk about” equations and diagrams. On the other hand, we are not aiming for “perfection” (whatever that is). We are simply trying to do a job and do it well. An engineering design process does not produce a perfect product, and a process to prepare you for public speaking will not produce a perfect fifteen-minute talk. Intelligent compromise is basic to all practical engineering activity.
Let’s reiterate. As an engineering professional or student, you cannot avoid technical speaking. Eventually you will need to speak in front of a class, pitch an idea to management, or speak at a conference. Fortunately, you can make your preparation less daunting by applying the engineering design process. Recall that the first step in that process (Figure 2.1) is to thoroughly understand your goal. As a public speaker, your fundamental goal is effective communication. More formally,
Your goal as a technical presenter is to communicate information to an appropriate target audience.
In other words, some body of information currently resides in your mind and must be made available to the minds of the target listeners. There are two main issues here.
1. How does the information reside in your mind? How did it get there, and what forms does it take? Which portions of the body of information exist in your mind as visual impressions (“pictures”), or as abstract concepts, equations, quotations from authorities, etc?
2. Who is the target audience? What are the attributes common to those people at whom you will aim the presentation?
If your knowledge of a topic isn’t clear to you, or if it isn’t clear who you’re trying to communicate with, your chances of producing an effective presentation will be small. Not convinced? Picture an engineer who is to design a circuit to control the movement of a mechanical device, but doesn’t know what the device is. How will he proceed with the design if he doesn’t know what range of motion the device will experience? Is the movement longitudinal or rotational? What weight must be moved? How fast must the movement be? Without this information, the engineer can’t possibly begin to design the system. And without knowledge of your topic and the audience, you can’t begin to design a presentation.
You have probably seen a presentation where the speaker seems to have “thrown together” a bunch of slides full of words, figures, equations, headings, etc., and flashed them past the audience. He may not have even considered the makeup of his listeners, and as a result you probably felt under-served. Perhaps the speaker had only a short time to prepare. Perhaps he thought:
I’ve just got to make it through this presentation and keep my job.
This is an untrained approach to speaking. You should strive for better. Your audience deserves better.
In successful technical speaking, as in successful engineering design, form must match intended function. That all-important match will not likely happen automatically or at random. Remember the goal statement:
Your goal as a technical presenter is to communicate information to an appropriate target audience.
In order to communicate something of technical value to others, you must be clear about what you know and how you know it, understand the characteristics of the intended audience, and consider how to best transfer your knowledge to that specific group of listeners. Let’s examine the first two of these aspects in greater detail.
2.3 How the Information Resides in Your Mind
Engineering information may reside in your mind in a variety of ways. It may take the form of a mental image, like a mechanical drawing, or it may exist as an abstract concept such as “pressure” or “density.” It may be formed from other sense experiences, such as the sound of a failing bearing, or the smell of a chemical, or it may be the purely symbolic mathematical expression f = ma. It might even be best described as a sequence of words, such as in rules of thumb: “smaller loops radiate less,” or “less contact area means less friction.” (Be careful with such phrases, though, since they lead to lazy thinking and are often misleading or even wrong.)
It’s not our purpose here to adventure into psychology, and we’re not worried about how information might be stored in the brain. But it’s important for you to understand how you, yourself, view the essential aspects of a topic if you hope to make a meaningful connection with an audience. Once you understand your relationship with the information you want to present, you can think about how to pass the information across to the listeners. Work hard to maintain an awareness of this relationship throughout the process of planning any presentation.
Example. Melody’s senior project involves filtering noisy radar signals to improve detection rates. She tries to think of a good way to describe the effects of noise to other students, and realizes that she most strongly associates noise with an audio signal. She thinks that perhaps it is easy for students to “hear” noise, even if they don’t have a good mental picture of the generic concept of noise. So, she applies her filters to an audio signal and plays the sound files to her audience. “Think of the radar signal as a sound,” she says. “When there is noise, it’s like an added hiss. When we lowpass filter the sound signal, we get rid of a lot of the hiss.” The audience immediately understands the impact of the filter on the signal, and the demonstration creates a nonverbal analogy in their minds that they can apply to the general concept of noise, just as Melody does.
You’re the expert on the subject of your presentation. If you have found a helpful way to understand some aspect of a topic, then why not pass this along to the audience? If you think a topic is best understood as a sequence of drawings, then use drawings. If it’s best to use equations, use equations (carefully, of course).
Example. A table can be a clear way to present things. Consider this table, which exhibits properties of some types of electrical capacitors:
type |
voltage rating |
series resistance |
RF frequency range |
market share |
ceramic |
high |
low |
high |
46% |
mica |
high |
low |
high |
< 3% |
tantalum electrolytic |
low |
high |
low |
12% |
aluminum electrolytic |
low |
high |
low |
22% |
Would this data be as clear if it were presented as running text on your slides? Compare the table to:
Ceramic capacitors have high voltage ratings, low series resistances, high RF frequency ranges, and a 46% market share. Mica capacitors have high voltage ratings, low series resistances, high RF frequency ranges, and market share of less than 3%. Tantalum electrolytic capacitors have low voltage ratings, high series resistances, low RF frequency ranges, and a 12% market share. Aluminum electrolytic capacitors have low voltage ratings, high series resistances, low RF frequency ranges, and a 22% market share.
Clearly, the data is much easier to access using a table.
Effective speakers put their audiences first. As an engineer, you are speaking to inform — not to bluff, dazzle, impress, or enchant, and certainly not to confuse or frustrate. Think about your potential listener: try to envision him or her.
1. What is the listener’s background? Is he an accomplished expert with education appropriate to the topic? Is he a nontechnical but powerful decision maker who expects you to display fluency and confidence?
2. What are the listener’s purposes? Will she simply want the bottom line regarding the topic? Is she after a much deeper view? Is she evaluating you, or in some other way making a decision affecting your future?
3. What is the listener’s likely level of understanding? Is he an undergraduate student? Is he a member of your doctoral committee? Is he a graduate student outside your technical area?
We can’t overemphasize this fact: the audience is central to all considerations regarding a presentation. Planning a talk without understanding the target audience is like designing a product without understanding the customer.
Example. It’s your job as a speaker to know not only what the audience wants to hear, but what it needs to hear. Zoë spent a long time preparing a talk to her engineering staff on how to implement new design protocols for the high-power systems manufactured by her company. After Zoë outlined the changes, several staff members grumbled, and one brave employee spoke up. “Wow, this is going to make our lives a lot harder. Why the heck do we have to to do this? It seems like this company is always introducing meaningless changes just to make us suffer.” Zoë realized she should have led off her talk with some background on why the changes were needed. Her engineers had spent a great deal of time tweaking the old protocols and had become efficient at implementing the designs; she should have known how sensitive they would be about the changes. “I know this is going to be a lot of trouble,” she said, “but it came from a recent overhaul of government regulations and we really have no choice in the matter.” It took a while to calm her staff down, but eventually they were convinced that they had no choice in the matter.
There are many other useful analogies between technical presentation and engineering design. Consider:
technical presentation |
engineering design project |
audience |
customer |
effective speaking conventions |
engineering standards |
preparation time and effort |
project cost |
brevity and conciseness |
product efficiency |
clarity |
product effectiveness |
rehearsal |
test run |
critique |
customer feedback |
Like any consumer product, your presentation must address your customer’s needs. It must adhere to expected conventions such as those of English grammar. It must economize the listener’s time, energy, and patience. Finally, it must fall within budget in terms of your own time and energy as a busy engineer.
2.5 Other Aspects of Situational Awareness
Technical presentation is complicated. There are other things to consider besides your topic and the listener. Here are additional questions to ask during the planning stages.
1. What is the time limit? Technical presentations run the gamut from ten-minute talks to multi-day seminars. Time length is obviously a crucial parameter to identify at the outset.
Example. Sandra was worried that she wouldn’t be able to fill an entire 20-minute time slot at the regional chemical engineering conference. It took her by surprise when, 22 minutes into her presentation, the session chair nervously pointed at the clock. This threw Sandra off and created a discontinuity in her presentation when she realized she had to skip to a severely abbreviated conclusion statement.
2. How will the audience be positioned? How and where will they be seated (in particular, how far away from the speaker)?
Example. George expected his nifty working demo unit to carry the day at senior project presentations. He didn’t anticipate having to deliver the presentation in a large classroom. George held up his palm-sized box while people in the back row squinted and clearly had no chance of reading the tiny display. After the presentation, George realized he should have created a short video to show on the projection screen instead. Those who were interested in holding the actual demo unit in their hands could have come up after the presentation to do so.
3. What presentation equipment is available? You don’t want to prepare transparencies only to find no overhead projector available. If electronic projection is to be used, be sure you have used the correct software to prepare the presentation. Also check that the version of the software is compatible.
Example. In the middle of his conference presentation, Eric was horrified when the equations he so carefully prepared using the required presentation software appeared as a sequence of strange characters resembling mailboxes, flowers, and computer monitors. It turns out that while he was careful to use the prescribed software, he didn’t use the correct version. He probably took away more from the presentation than the audience by discovering how it feels to wing a technical talk without crucial visual aids.
4. What are the other aspects of the speaking environment? What is the acoustical situation? The lighting situation? Will you be competing with external or internal noise sources? Where will you appear in the speaking program?
Example. Lisa had presented in large rooms before. This one was different, though, and Lisa didn’t understand that until she started speaking. The room was narrow but very deep and, most importantly, carpeted with rows of fabric-covered chairs, thick wallpaper, and a porous drop ceiling. Her words were largely absorbed before reaching past the first few rows, and people sitting in the back struggled to hear. Lisa found herself distracted from her topic, trying to calibrate her vocal volume to the situation. Halfway through her talk, an audience member in the front row boldly asked Lisa why she wasn’t using the microphone that sat over on the podium. Terribly embarrassed, Lisa muddled through the rest of her talk and sat glumly in the back of the room after finishing.
2.6 Checklist: Engineering Your Presentation
□ I understand the goal of my presentation
□ I understand how the relevant information resides in my mind
□ I fully understand the target audience
□ I know the background of the audience
□ I know the purpose of the listeners
□ I know the level of understanding of the listeners
□ I have completed the research necessary to generate solutions to my speaking task
□ I know the time limit
□ I know the limitations of the venue
□ I know how the audience will be positioned
□ I know what presentation equipment will be used
□ I’m aware of the acoustics and lighting
□ I have generated several potential solutions to my speaking task
□ I have evaluated the potential solutions and decided on the one that best meets my needs
1. The generic engineering design process applies to the design of formal technical presentations.
2. You can plan a presentation via the customary divide-and-conquer (top-down) approach with iterative improvement.
3. As engineers, we know that it’s hard to solve a problem without understanding it first.
4. Your goal as a technical speaker is to communicate information to an appropriate target audience. In other words, a presentation is intended to communicate what you know to an interested, reasonably prepared listener.
5. Producing a formal presentation just to meet a deadline or attain some other reward is subject to the old rule of garbage in, garbage out.
6. If given the latitude, pick a topic you’re really interested in. Your enthusiasm will contribute much to the quality of your presentation.
7. It helps to think about what you know, and how you know it, before trying to present it to someone else. Doing so might even help you become a better subject-matter expert.
8. Good technical speech is accurate and appropriate for a particular target audience. It’s essential to consider the target listener’s background, purposes, and maturity level. This is especially the case with mathematical maturity.
9. If you dislike formal speaking but enjoy pleasing your customers as an engineer, then think of each audience member as a customer.
10. Gather pertinent information on the target venue well before the speaking event. Study environmental factors such as acoustics, lighting, temperature, humidity, seating, and outside noise. Test the projection equipment if possible, making sure it works with your own laptop computer.
11. Get feedback early and often. (And, as a professional courtesy, provide feedback to others who seek help preparing for their speaking engagements.)
12. Thinking like an engineer is not just a paradigm for giving a talk; it is also a framework for evaluating the formal talks of others. Engineers must review and critique the information in many oral presentations.
2.1. What types of design constraints do engineers routinely face? List as many as you can.
2.2. Pose a simple problem and generate at least three alternative solutions.
2.3. If an idea dawned on you in a flash of insight, must you still lay it out systematically for the listener? Why or why not?
2.4. Todd just embarrassed himself in his control systems course. His total improvisation approach to the semester oral presentation fell flat and resulted in a low grade. He is disoriented and demoralized. However, Todd still has one week to prepare for a similar presentation in his electromagnetics course. What advice would you give him?
2.5. Choose a topic within your area of knowledge and consider how you’d explain it to a layperson. How would you break it into manageable chunks? Would you have to further decompose some of these chunks to make them understandable to the listener?
2.6. Make a list of signpost words that could serve as headings or subheadings on your own presentation slides. Some possibilities are as follows:
• Approach
• Demonstration
• Explanation
• Limitations
• Purpose
• Review
• Validation
2.7. Organize some technical information in table form. Choose any topic of interest.
2.8. Explore your building or campus and look at the various rooms in which presentations occur. Stand at the podium and see how well your voice projects. Take notes about the available presentation equipment and about how to make yourself heard in each room. Do you find significant differences between rooms?
2.9. Construct a rubric to evaluate how well you have engineered your presentation. You may wish to use the checklist from Section 2.6 as a guide.
1 Also see Engineering Writing by Design: Creating Formal Documents of Lasting Value by Edward J. Rothwell and Michael J. Cloud, Taylor & Francis/CRC, 2014.