Developer Advocacy Manual (8): Presentation Skills

作者：Christian Heilmann
编译：庄七

Lectures and speeches are a great tool. They allow you to show your audience something that excites you in an engaging way. The audience gives you immediate feedback–much of it in the form of body language. For me, this is one of the most enjoyable parts of being a developer evangelist.

Fact: The start of any great talk is excitement about the subject. If you don’t have that excitement, you might as well not show up. We’ve covered this several times in this manual. In this chapter, I want to talk about another issue with presentations. Mind the length, and more importantly–keep the audience interested.

The information below revolves around conference talks. A talk is your slot in the program, stand-alone. Not those talks that introduce workshops or during company meetings. Much of what I present here applies to those meetings too, but there are some different nuances to consider.

How to Fit Everything in x Minutes

As someone just starting out giving talks, you will panic about the timing of your talk. This is natural and okay. We all do this. People starting out with presentations fall into two categories. Those who rehearse every single second of their talk and get cut off, and those who appear way too fast in their talk.

Fact: We tend to run up stairs rather than walk down them. The reason is that stressful and tiring tasks seem easier when you get through them faster. This is also why your talk will always be faster than you rehearsed it or planned for. When giving a talk on stage, your adrenaline spikes, and for you it’s just that. That’s okay. It makes you human, approachable, and brings the audience to your side. You are doing what we all fear–addressing a group of people, and you are still afraid. This makes you an honest, technical speaker–not a polished perfect actor or politician.

Warning: As you get more into the groove of giving talks, this automatic speeding up can become dangerous. The excitement doesn’t subside–all you do is get used to going fast. This is why, over time, your brand gets bigger and you are tempted to put more and more into your talk. You have the time, so you might as well use it, right? People paid to be there, and more is better, right? Not always…

Less is More

Do not fall into the trap. A great talk makes only a few points, all centered around one central theme. This is why conferences focusing on talks have short sessions. The 16 to 18 minute limit TED imposes on talks isn’t a trick to get more content in. It’s a great limit because it’s the time an audience is alert and able to take things in. It also forces speakers to think more about their talk: making their point in a limited time. This means you will cut out as much fluff and redundancy as possible. And you will pick more compelling messages.

Here’s something to remember: start with one point you want to make. This doesn’t need to be a sound bite (though that helps). It can be many things.

It could be an insight.
It could be the result of your research.
It can be a “here’s where X thing is at the moment”.
It can be “this is what’s new in X product, see how we built this feature”.

Start with your point and then add other content around it. Just like a good story has a build-up, a climax, and an end, so should your talk. Essentially, your focus should be on what is the one thing I want people to remember from my talk? This means you need to try and get into the audience’s heads.

You know what you’re talking about. Try to remember what the major “A-hah” moments were that got you to where you are. That’s your starting point. There’s a reason you are giving this talk. The story you want to tell about your talk’s subject is that reason. Not the subject itself. Sell the story–you don’t have to own all the information. That’s important. There are many speakers who will tell you all the steps to take to achieve a goal. But you’ll remember the ones who inspired you to find out more about the subject in your own way.

Your Talk is Only Important to You

When we are talking about technical talks to an audience at a conference, there are a few things to consider:

Your talk is one of many: If every speaker dazzles the audience with lots of live coding, great tools that make “everything as simple as pressing a button” and profound truths like “X methodology is dead, here’s the new–if experimental thing that will save us”, people will quickly be overwhelmed with information. A talk that illustrates a point well will be refreshing and not seem like it’s stuffed with content to make it appear fuller. You can stand out by focusing on one thing.
Your talk is recorded and distributed: There’s a lot of research that tells us how long educational videos should be, and the general consensus is that shorter is better. People use browser plugins to watch videos faster than they are meant to save time. No one wants to spend a full hour finding out about some new product feature.
People won’t remember the entire talk: You have to use your time to spread out. You want people to remember a couple of things from your talk, to mull over, or tell others about.
People don’t need you for information: They need you to have thought through things. They need you to learn how to leverage resources to apply something or an insight. No one needs you to tell them the obvious or what they can look up online in a few seconds.

As a speaker, your job is to make a topic interesting enough for people to try it themselves. You are just a guide, and people may disperse, or find their own way.

That’s the real art of presenting. Stage time is not show-and-tell time. That’s what video training, workshops, tutorials, or one-on-one training is for. Stage time at a technical event is “here’s why this is something worth your time to look into”. Or “here’s how the state of research helps us” time. Not “I know, I’m excited, and I’ll show you everything I found” time.

This can be hard to avoid, as it’s fun to show off on stage. It feels good to share what you’ve done to achieve something. It’s nice to show how using a certain tool or way of working has made you more effective.

Warning: It’s important to remember that people are not you, and everyone has different learning and working styles. Showing off what works for you and how it makes you better can come across as patronizing or arrogant. Remember, the audience most likely knows their stuff too. And they want to show off what they know. That’s why you get aggressive feedback on social media during and after your talk for being too “self” about your product or your technical knowledge.

Index More Information

The easiest way to delegate information to control time and use the time you have to deliver memorable messages. Instead of explaining everything yourself, point to resources people can check out in their free time. You can do this by referencing things:

Comparison / research sites on the web showing the current state of a technology. These are great because it means your talk stays current. You introduce the audience to a resource that, if they watch your talk recording later, shows the current state. Since many conferences take a long time to edit and publish videos, there will always be a delay between your talk and publication. Instead of showing the current state, point out the journey that’s happening.
In-depth talks covering the same subject you present, as a solution. Let’s say you do a talk about offline applications. You could go into all the browser differences and the state of service workers. Or you could point to an in-depth talk about the subject and explain why the technology is important and what problem it solves. This also shows you are a person who cares about other speakers and conferences. It shows you care about what you do and gives credit to other speakers. It shows you are in the know and ready to teach and learn instead of just telling people what you know.
Test suites. Instead of you telling people something works, show them a place they can test it themselves. This avoids people second-guessing you. All you’re doing is sharing the results you found and your opinion about them. Additionally, you invite them to do the same, find their own results, and compare them to yours. This makes the audience as cool as you, but you are still cooler because they got the resource from you. For example, if they show their boss how slow their website is and how to fix it, they’ll remember you as the person who introduced them to the tool that impressed their boss.
Interactive examples and forked resources: Let them play with and extend your work. Put your code on JSBin, JSFiddle, CodePen, or any other resource. Point to GitHub repos. Make it clear where people can find your work and why you want people to use it. Also ask for feedback. Reusability and availability of code is important. No one wants to follow some live coding recording and try to read the code from the video.
Specs and official standard discussion lists. Trusting that you are a speaker is one thing. Knowing that what you’re talking about gets a lot of expert eyes and consent is a whole different game.
Collection of resources. Provide a list of links to resources you talked about in your talk and have it as one place to find everything. This prevents people from having to write down what you’re talking about as you do the talk. It also allows you to use a short URL and track how many people looked up what you covered. This is a good metric to show your manager.

One concern many people have is not being technical enough. We all hate sales pitches–that’s a given. Talks have many pedagogical benefits as a form compared to coding exercises. That’s why you shouldn’t feel bad about using slides instead of opening a terminal as a tool for your talk. Which brings me to the thing that is most likely to eat into your time budget: code exercises and live demos.

Live Coding?

I’ve discussed this multiple times with other people doing developer advocacy. We consider live coding the most amazing level of being a technical speaker. It shows you’re still a programmer. It shows you walk the walk, not just talk the talk. It means everyone can repeat what you showed.

I’ve seen了不起的 live coding demos. And they always go down a storm with the audience. Some speakers manage to make code a performance and keep it entertaining and exciting. Those are special people, though, or the talk and live code are prepared really well.

When asking the same excited audience hours later what the code was about or how the speaker solved a certain problem, you get a different result. Live coding is exciting, but it also assumes the audience works like you and uses the same tools. Many times I’ve seen the audience reaction go off-track. People on Twitter talk about terminal setups or the code editor the speaker uses instead of listening and thinking about the talk’s subject. By coding on stage, people can get distracted by your environment setup and way of working. This can be a major distraction. Or it can even mean people don’t listen to you at all–after all, you’re not using their environment.

Live coding has many unknowns that can derail your talk and eat into your time allocation. Many things can and will go wrong:

You will be offline. Don’t trust anything the conference organizers or venue owners tell you. The moment you get on stage, the network can go down, the computer can crash, programs can break, and there’s nothing you can do but reboot the machine.
You will add typos when speaking and writing. This is just a natural thing. It’s charming when you acknowledge and immediately fix it, or when someone in the audience spots your problem before you try. But it takes time.
You will forget obvious things. Like your login information. Many times I’ve seen speakers try to connect to a system and fail three logins. Once, I saw a speaker who didn’t realize he was in the name field instead of the password field and typed his password for 2000 people to see. Good luck recovering from that.
Your code will be harder to write or impossible to read. You have to make the font much larger for people to see what you’re doing, which means you have fewer characters to play with in a line. Usually, the projector resolution isn’t your standard resolution. That means your editor’s settings now have to fit a smaller space, and you won’t have all the menus and toolbars.
You can easily show things you don’t want everyone to see. Autocompletion on fields, browser history showing as you type in the URL bar, all these things can be annoying or even outright embarrassing. Many developers I know create a brand-new profile on their machine to avoid this.
Debugging and solving problems takes time. When something goes wrong on stage, you need to acknowledge it and move on. You can’t do this when you’ve shown 10 minutes of code and it doesn’t work. Then you start muttering and focus on the code. Or you get a lot of feedback from the audience in different states. Either way, it breaks the flow of your talk, and time is passing. You lose control of your talk. And that’s one thing to avoid.

A lot of live coding is the “anyone can do this in a minute” pitch, which can feel tiring. As developers, we are constantly promised things that will make our lives easier. We also keep seeing them fail. And we’ve seen so many “minute demo” things we never, ever needed to do in our later work.

Warning: If it feels too easy to do, then it’s either not worth doing or it’s insulting to our work as developers. We are experts, and expert-level tools should enable us to build higher-quality products, not make us redundant. That said, if you are adamant about what you do and the conference is a technical one where people expect things to break during experimentation–then go for it. I’m not here to stop you from being as creative as you can in your own, personal way.

Consider doing a screencast of the code and/or product demo and talking over it. Because a talk should be repeatable and its content reusable. Using a screen recording, you can fast-forward through loading or compiling parts of the video, and you know the length of the exercise. You can focus on coding, and on stage you can focus on doing live commentary. It’s hard to do both because typing things and saying things differently isn’t a natural thing.

Avoid Questions

One of the worst things you can do during a talk is allow questions. I know, earlier in this book I said this is a good thing. But that wasn’t specifically about conference talks. While offering the option of questions seems like a nice service to the audience and makes the conference seem more interactive, it’s not helpful. In a talk that’s part of a workshop, to introduce a section of it, it’s great. In a conference, where you are on stage and have a set time, it does nothing but distract.

You have to hear the question, understand it, and repeat it. This is for the audience, but more importantly, for the recording. In the recording, you will look like a lost person trying to squint to see who is asking the question, listen and understand what the question is. This isn’t a good look and wastes time for people watching your video later.
The questions are either about things you are going to talk about later or about other topics, not directly connected to what you’re speaking about. The former makes you seem smug when you say “Ah, that’s coming up later”. It also makes the time spent asking, understanding, and repeating the question completely wasted. It makes the person asking feel like he’s wasted everyone’s time. The latter means the question disrupts your story and narrative flow, distracting the audience. You lose them, and that’s the main thing to avoid.
It’s too arrogant. Sure, allowing questions during your talk shows you’re not afraid. It shows you know everything about the subject. It also shows you don’t care that much about your talk, or you don’t have a coherent story to tell. You’ve already acknowledged that your time isn’t important and that you’d rather have a discussion with people. Then why not just offer an open Q&A instead of a talk?

Make it clear that there will be time for questions after the talk. Tell people where to find you during the conference and how to contact you. Reassure people again that your talk will have a lot of information, so their question is very likely to be answered. Essentially, letting people know it’s a planned, fixed-length talk makes it easier for them to accept and listen carefully.

Things to Cut

There are things in slides that we consider good style, but upon closer inspection aren’t that useful. They might work for you, but I’ve found cutting them from my talks has no ill effects:

Agenda slides: This tells the audience when to sleep and when to stay awake. You can say what you’re going to cover in a sentence at the start of the talk, there’s no need to keep reminding people where you are at this moment. It feels like a crutch for the speaker, and it gives the impression you’re not telling a story but following a set of instructions.
Corporate information slides: “I work for X, which does…” is not why people are here. Unless your talk is about your company, avoid this at all costs. This includes massive corporate branding of your slides. Don’t do this unless there’s a legal reason for it. This is your time, and your talk will get people excited about your company. The problem with brands is that people have a preconception of them. Don’t let that be an obstacle to your brand.
Long slides about yourself: That’s what the bio on the conference materials is for, and, guess what? No one reads those either.
Current jokes and memes: While having these things is cool now, they can seem dated when people look back at your talk later, and in many ways even more contrived. Worse, when a certain meme or celebrity is adopted by people you don’t want to be associated with, what was funny in the moment can become offensive in the near future.

Filling Out Your Talk

If you’re happy with your talk and you realize there’s nothing left to cut, what can you put in to add value and fill any remaining time? A few things might be important:

Tell people where to find your talk’s slides. Almost no one looks at slides, but everyone wants to see them. This is the first question.
Have a slide that tells people where to meet you and how to contact you. Tell people why you use a certain channel and for what. Tell them where you are most likely and how fast to respond.
Prepare a slide that introduces colleagues or people working at other companies. They are experts in the subject. If you’re busy, people can reach out to these people.
Show where you publish and where your team publishes things. You don’t want to be the only source of truth.
Show resources covering the subject you’re talking about, that need participation. Mailing lists, repositories, unit test libraries, and so on. In other words, show where the audience can be part of it in a simple and helpful way.
Show resources you read to understand the subject. Sharing your sources is appreciated by people, and it gives those sources momentum.

Planning the Talk Summary

Plan your talk around one central theme and the single take-away you want to make. Add more content around it to tell a story. This way, if your preamble uses up too much time, you can still get the essence across. Your time is limited, and the audience won’t listen to every word you say. What makes it worth it for both you and them is to have great content, material that helps keep the pace, and avoid materials that could take a lot of time when they go wrong.

Reprinted with permission from: Developer Relations »