Powerpoint doesn’t stink. Our presentation skills do. So how do we fix it?
First, you must decide: what do I want this presentation to be? We’ve all seen the brilliant TED talks about new ideas. We’ve all seen the really cool sample presentations from those online presentation sites about someone’s trip around the world. When you’re looking at those talks, though, remember this: they are selected out of millions of talks for their content, and their content fits their format. I’ve seen folks do fairly standard slideshows with Prezy. It doesn’t work. I’ve also seen people do “let me tell you about my trip” presentations with Powerpoint. Again, it doesn’t work.
So, just like network engineering, pick the right tool for the job. Since most of an engineer’s presentations aren’t going to feature exciting trips down the River of Doubt, or even up Doubtin’ Mountain, we’re probably pretty safe to stick with a fairly standard presentation package — slides, warts, and all.
Yes, it’s important to get the flow right. I once stood in for a presenter who’d lost his voice — the material was router architecture (hardware and software), so it’s a topic I know well, so I wasn’t in the least concerned about giving this presentation. When I stood in the room and started looking at the slides, though, I realized — a bare 15 minutes before I was supposed to start speaking — that there was absolutely no rhyme or reason to the order of the slides. Individual topics were scattered throughout over 400 slides (for a 90 minute presentation!). There was no “unifying principle,” such as “begin with a packet being received on this interface, and let’s see how it’s switched all the way to the outbound interface.” Normally, this speaker knew the slide deck well enough to flip between the various sections to tell a story — the slides were a visual aid to a talk he had in his head, rather than an actual talk in visual form. There’s no way I could replicate his talk, as it simply wasn’t in my head the same way.
Almost every presentation I see has some form of this same problem — there is little thought put into a unifying principle. The audience doesn’t move from an idea, or a set of ideas, to a conclusion, they just jump around. Look at virtually any sales slide deck and you’ll see this problem illustrated almost perfectly — product after product, “see you have this problem, that product solves it.” There’s no architecture or idea of a set of business problems driving a narrative.
So focus, really hard, on building a flow. Look at a real outline of what you’re presenting, and try ordering it in different ways. Try and find major headings and subheadings. Don’t just let all the information sit there in a bunch of slides. You want a chain of pearls, where the person can walk from one slide to the next, and understand what is being said — the point that’s being made. You don’t want a random walk, as useful as they are in some situations. Even if you’re not telling a story, you’re telling a story.
Don’t just count on the story in your head, either. People are going to save these slides and look at them later — will they make sense then? Our brns fll a lt of infrmtion in — one of the mst commn prblems with spllng and edtng is that we knw wht we intnded to wrt, so we see that instd of what is actlly on the pg.
Send the presentation to a friend, completely blank on the topic, and ask them to outline the points made. If they don’t get it, you haven’t built the presentation right — plain and simple. Don’t spend time explaining it to them, redo the presentation until they can get it without you saying a word. They might not get the details, but they must be able to get the flow and the point without you telling them what it is.
It’s that important.
At some point you want to be able to see this in your own presentations — but don’t expect it to happen overnight. Like throwing the perfect pitch, or shooting the perfect stage, you must practice right to learn the skill of separating yourself from the material far enough to see the flow without filling in what you meant to say (and didn’t).
Next time, we’ll talk about some other reasons why your presentation stinks, and how to fix it.
“Presentations are just a waste of time.”
“Can’t we do something other than another long, boring, presentation?”
“We should just ban Powerpoint.”
If I had a nickel for every time I’ve heard someone complain about Powerpoint, or presentations, I’d be rich enough to quit work and stop blogging. 🙂 Isn’t it about time we were honest with ourselves, though? Isn’t it about time we told the truth about this particular problem? Blaming Powerpoint for bad presentations is like blaming word processors for badly written books.
The problem isn’t Powerpoint. The problem is the person you see every morning looking at you in the mirror. The problem isn’t the tool, it’s that we stink at organizing and presenting our thoughts in any sort of reasonable way. So let’s talk about how to build a better presentation.
To begin: forget everything you’ve ever read in a book about making elevator pitches, making a presentation that impacts, with dash, flair, or whatever. There is a set of presentations that present as a story, with flair and dash, and there is another set that just doesn’t.
As an example, I was the Routing Protocols SGM for Cisco Live for many years. One thing I noticed is that, within the routing group of presentations, troubleshooting presentations always get better scores than deployment or theory presentations. Across a wide array of speakers, and a wide array of topics, troubleshooting lends itself to “telling a story,” while also diving into details people like to hear — so they tend to score well. Presentations that present information on operation, configuration, or design, tend to score less well, no matter who presents them, and no matter what the specific technology is. So there will be things that will present well, and there are things that won’t. If you were a professional speaker, you could, perhaps, only decide to tell stories that people want to hear, and hence present yourself as the best presenter who’s ever lived. Back in the real world, we don’t often have the choice of what we present — there is material that must be communicated to a wide audience, so we present it.
This doesn’t mean you shouldn’t think seriously about the flow of a presentation — in fact, the flow is probably the most important element of any presentation, no matter what it’s about. It’s often best to build each section of the presentation as a separate subset, then rearrange in every way possible to see what works well. Often getting the flow right is a matter of experience. I can’t tell you how to build a flow that works, I can only tell you what doesn’t (or won’t) work. One thing I can tell you is that the way you write shouldn’t be the way you present. Just as a book must sometimes be changed to make a good movie, any given document will need to be rearranged to make a good presentation.
We’ll cover more about practical ideas when building a presentation next week—but for this week, stop blaming Powerpoint for your horrible presentations. The tool isn’t the problem, any more than C makes bad code, or EIGRP makes bad network designs.
The rest of this series can be found here:
In the first part of this two part series, I talked about why it’s important to learn to write — and to learn to write effectively. But how do you become an effective writer? I started with the importance of reading, particularly difficult and regular reading across a broad array of topics. Is there anything else you do to improve your writing skills? Yes — specifically, get yourself edited, and get some practice.
Hey — I’m a pretty good writer, why do I need to get myself edited? After all, I’ve written nine books, hundreds of articles, tens of research papers, and… But that’s just the point, isn’t it? I wrote several large papers (at least I considered them large at the time) while I was in the Air Force, but they never seemed to have the impact I thought they should have. Weren’t they well written? Weren’t they well organized? Well researched? As it turns out, no, not really. I started on my first white paper just after I’d started in the Cisco TAC, reading through the EIGRP code and writing a paper — for internal use only — based on what I could find. Don and I backed up each assertion by setting breakpoints in the code and watching the actual variables change in real time, and then back checking everything on the wire using various packet capture tools. The paper was eventually published on Cisco’s public web site, and I thought I’d pretty much reached the pinnacle of my writing skills.
Then I started on my first real book, through Pearson Education. I quickly discovered my writing skills just weren’t what I thought they were. The drafts came back looking like a river of red ink. It took me two or three books to get over taking the editing personally. But I learned. I learned where and how to use an image instead of words. I learned how to organize information in way that made sense to people — to pay attention to the flow of the text.
I then took on a fiction book. Again, I thought I was pretty good by this time. Again, I was completely and utterly wrong. I hired a retired English professor to work through the edits. Again, entire rivers of red ink ensued. But I learned — I learned how to meter out information, to slow down, to find ways to describe things, to make things happen, rather than talking about what was happening. I’m still not an accomplished fiction writer, but the rivers of red ink certainly taught me.
Finally, I started working on a degree in theology. Certainly, after all the writing I’ve done, and all the times I’ve been edited, I’m a pretty good writer by now. Yeah, right. The rivers of red ink were even larger, longer, and redder (if that’s possible). But I learned to structure an argument, to think through the counterpoints, the other side, to actually research and think through what other people said, to catalog the options, to really read the entire article around someone making a point in the area in which I was working…
In short, editing has taught me to write. If you’re going to learn to write, you need to put yourself at the mercy of editors who are good, and learn to listen. Don’t take the red ink personally, take it professionally. Take it as a chance to learn.
Finally, get some practice. One of the reasons I actually began blogging, and continue blogging, is not to become famous, or to win friends and influence people, but rather to practice. There are different sorts of writing, each with its own rhythm. But I’ve learned that if I’m going to really learn to write consistently, I must give myself a reason to write consistently. Blogs, if nothing else, consume text. Day in and day out, it’s a challenge to find a topic, stick to it, make a point, and move on.
So there it is. It’s important to learn to write if you’re going to be an effective engineer. For practical advice, I can give three points: read hard stuff, get edited, and get some practice. Am I a perfectly practiced writer at this point? Can I churn out text whenever I feel like it? Certainly not. I still struggle with volume and speed. I still sit and tell myself to focus.
But I think, maybe, I might have finally reached the point of being a pretty good writer. No matter where you are, you should make a commitment to start your journey to good writing skills now. It will make you a better engineer.
Engineers are supposed to be able to gather information, arrange it in a way that makes sense, and then propose a solution that actually solves the problem at hand — right? So why is it I’m almost constantly astounded at the lack of writing skills in the engineering community? Why don’t engineers know how to write, given the almost complete overlap between the way the engineering process is supposed to work, and the way writing is supposed to work?
I suspect there are a number of reasons, probably foremost of which is that engineers don’t think in the logical chains we like to believe. Engineers are too often caught in the modern “search engine world” — find a thesis, search for a few exports to support your belief, and declare the issue decided. We’re sorely lacking the serious interplay between ideas, the pros and cons way of thinking, that exist in many other intellectual pursuits (though honestly, on a decreasing level every day).
If you need some encouragement, let me put it another way: learning to write will not only enhance your thinking skills as an engineer, it will also advance your career. Seriously.
What to do? Well, we can’t change the world, but we can change ourselves. Forthwith, a few ideas on learning to be a better writer.
Read. This might sound stupid, but the best way to learn to write is to read. I’m always astounded when I meet someone who hasn’t read a book in years (and often, they’re proud of it). Stop it! Not reading is nothing to be proud of.
But let me qualify — not just technical stuff. Read philosophy, theology, fiction (and not just science fiction!), history, biographies, and lots of other stuff. Let me give you two reason you need to read a lot.
First, you’re never really going understand language until you’re awash in it, buried in it, absolutely filled to the gills with it. Communication is an art as much as an engineering problem; the only way to really grock it is to do some serious reading.
Second, reading gives us the chance to peer into someone else’s mind (unless you’re a real postmodernists who believes there is no such thing as “the other mind,” or that reading is all about the reader bringing value to the text). The more minds you encounter, the more you’re going to understand people, and the more you understand people, the more you’re going to understand the world around you. Reading is the fastest and easiest way to gain access to another mind.
Read old stuff, too, and not just new stuff. Let’s not get into what C.S. Lewis called chronological snobbery.
Read classics. Read religious stuff. I’ve learned more about logic in studying theology than I ever did in engineering school — really.