This was the biggest change between the presentations I had to give in high school and the ones in college and above. In high school, the topic was usually given to us, whereas in college and later, I got to choose the topic I was most knowledgeable about. The latter meant I was more passionate, more able to answer audience questions and more able to tailor the delivery to the audience.
One piece of advice I heard was that if you absolutely have to talk about a topic you're not familiar with, talk about being a beginner in that topic. Talk about your perspective as an outsider learning that topic in the first place.
Are you an expert or a beginner relative to your audience? If I'm explaining something technical, I might take a more assertive tone when glossing over details with a novice but speak with more deference to an expert. (e.g. Throw in a few "I think ..." or "My understanding was that ...")
Getting a quick grasp of where the speaker is coming from helps the listener really engage at the right level. Should I double check what the speaker is saying or are they the authority on the matter? Nothing get's eyes rolling faster than someone making blatantly wrong factual errors overconfidently.
Use this ance-data to shape your tone and phrasing.
Think about your slide and presentation style. For example, I have enormous decks for most of my talks (think like 55 slides for 30 minutes) but I burn through them very quickly, usually less than 20 seconds per slide. I came from film editing before moving to software so I approach my Powerpoints like a movie, it's just my nature. Others have really short decks that are information dense so the emphasis is on the talking part of the talk and the slides just provide a reference in the background. Others forego slides in favor of straight-up demos, which is certainly slick if you can pull it off (high risk, high reward) and need little pictorial illustration.
Use the old 5 paragraph essay rules from high school as a starting point for structuring your talk: tell you're audience what you're about to tell them (thesis, topic, core argument) and how you're going to tell them (outline), then tell them (supporting paragraphs), then tell them at the end again what you told them and how you told them (conclusion, restating your intro).
Humor helps, generally. This isn't supposed to be a standup set so definitely don't go overboard, but it can really help. Particularly if you can tie it in with some empathy for your audience. ("We're gonna do this in Perl. I love writing Perl, you just hold shift and smash the number row for awhile.")
And for heaven's sake don't read your slides.
The five paragraph form itself is a beginner's tool: any good essay will deviate.
However, one nugget to borrow from the five paragraph form is the centrality of the thesis statement. Having a thesis for your talk is _crucial_ IMO. It doesn't have to explicitly stated, and it could be as simple as "I'm going to convince you that $FEATURE is awesome," but you need a focal point. You could restate what I'm saying here as honing your elevator pitch for you talk or in any number of different phrasings, but the idea is the same: a short statement that sums up the absolute core idea of your talk and provides a focus for you and your audience. Anything that doesn't fit your thesis is a good candidate for trimming.
http://presentationzen.blogs.com/presentationzen/2006/01/con...
Ideally, you should never need to look at your slides while giving a talk. Every time you turn away from your audience, you lose a little of their attention.
Do a live demo, people love live demo's, but be prepared for when disaster strikes (it will), if possible run your live demo on a physical device with you during the presentation.
Most places allow you to have 2 devices connected, or quickly switch the HDMI cable to the demo machine.
Do not use a linux machine, I know this sounds harsh, but with all the types of beamers/screens out there, a windows or mac machine will just have a much higher success rate. (I learnt this the hard way, in the end I could choose between mirrored 640*480 or full hd on the beamer only, which makes live demos much harder).
Create short slides, the slides are there to guide you and the audience. Try to prevent reading the slides out loud.
Use images and videos, they can tell more then a thousand words.
I often use the STAR approach to tell my story, this helps structure your talk. You don't need to follow star exactly, but if trying to explain something, it often helps to first give a bit of background why you did what you did.
Make sure you let the audience know if and when you will be answering questions, some talks really benefit from interactivity, but if you are short on time, let people know they can ask their questions later (perhaps add a slide at the end with sources and your contact information).
Also, relax, the audience has already decided they want to listen to your presentation.
Yes, as a regular Linux user I've never had major issues with presentations from Linux, but I've seen Mac users stumble many times for this exact reason.
If possible, have multiple output options built into your laptop. I have both HDMI and VGA on my current laptop and this has proved quite useful over the past few years.
It really depends on the topic of the talk. If it's something that can be demonstrated in a quick and straightforward way, do a demo by all means. But I've seen talks where people were forcing a demo into a talk about complicated concepts. There's little value in seeing someone type in a page of code, compile and run. Or seeing something run without understanding what is happening on screen. I would much rather have the speaker spend those minutes discussing the topic.
> Do not use a linux machine
Better advice: make sure you know how to setup an external screen on your laptop and how your presentation software works with it. Try it before hand with an old VGA monitor.
> Create short slides, the slides are there to guide you and the audience. Try to prevent reading the slides out loud.
I would argue that the slides are there for the audience. Ideally, you need to be able to present your talk without seeing your slides. They are not cue cards for the speaker.
Very short slides light on content (e.g. memes, one word or sentence per slide) make for a terrible tech talk in my opinion. Do make your slides informative. They should complement what you are talking about. Show a relevant graph, code snippet, etc. related to what you are talking about. If you can't do that, fall back to a summary of your spoken content in a 3-4 bullet points per slide.
I would argue the exact opposite. I think you should desire to be able to do your talk without seeing your slides, because the goal should be to do the talk without slides at all. You want the audience focused on you and what you're saying, IMO. Slides are a (sometimes) necessary evil just to help keep the talk on track.
STYLE
> [slides] are not cue cards for the speaker
Personally I disagree with this point and have developed a presentation style I'm happy with based on the slides being my cue cards (average 5-10 presentations / year for the last 15 years).
I do NOT read the talk from my slides and can't stand it when speakers do that! But, each slide should jog my memory of everything I need to say at that point. Maybe I'm talking about some stats as background, fine, the slide should be a bar chart of those stats, or a map, or an illustrative photo. Rarely a list of bullet points, though I don't prohibit them altogether and will tend to conclude with a list of bullets to leave in the background as a summary while I take questions. Overall the slides should complement the talk, not be a duplicate. But they serve a second function of reminding me of all the things I need to say.
As a programmer you will appreciate the reason for this: I have cut the number of entities I have to process in my head from three (slides, audience, notes) to two (slides, audience). Keeping track of and having rapport with the audience is essential to me, even if that just means looking at people to see how engaged they are. With notes/memory in the equation I used to get a lot more nervous and not pay enough attention to the audience. Cutting out the notes allows me to focus on communicating better. It's a shared context, the audience can see exactly[1] what I can see.
If you're in sales then I see another tactic used instead, which is to memorize the talk so thoroughly that you don't need notes or presenter view. Fair enough. I'm an academic researcher; while they say all our presentations are a sales pitch on some level or other they clearly aren't expected to be as slick as "sales" sales. My constraints are having limited time to prepare, and wanting to stay natural. I do rehearse but I don't over-rehearse as I find that kills my own interest in the talk as well as taking more time. Usually the minimum for me is two full run throughs, probably stopping the clock multiple times during each to apply edits as I see fit (hopefully only a few edits second time).
HANDLING CONTEXT SWITCHES
The one exception to [1] is context switches. As others have said, finding the perfect words for the introduction to each new topic really helps get the flow going. These can be remembered, written on notes, written on slides, written on slide notes visible in presenter view, whatever.
I'm a big fan of presenter view, not for notes, but purely for the ability to see the next slide and introduce it slightly before the change. It helps to leave each slide knowing what direction you're going in so you're not surprised by the next one. I do worry slightly that I'm dependent on presenter view and turn up early at each venue to make sure I can get it working (not all of them can).
NERVES
Someone said don't drink too much alcohol. Based on my experience as a performing musician this is true :) Same goes for caffeine for the opposite reason, it really heightens the nerves. On the subject of nerves, just accept that some talks seem to go better than others. If you find yourself having a failure of confidence, take a deep breath and keep going. Easier said than done I know, but it always feels worse on the inside than it really looks; I have had people come up to me after talks where I thought I did awfully and tell me how engaging they found it.
AUDIENCE ENGAGEMENT
If you can find a way to further engage the audience without forcing it - quiz questions, polls etc - go for it. Quiz questions can help set context for a new topic. Despite my love of the material I've never really been a lover of talks and can get pretty bored in the audience, so I really appreciate this sort of thing.
Example: on a few of my talks lately I've showed a picture of some protestors up trees by a road, asking who can name the incident. (Protests vs Newbury bypass construction). Followed by more protestors and an airstrip (former US nuclear base Greenham Common). Most of my UK audiences will get these right. Finally I asked what links these two things. They may or may not get the latter: the success of commercial development on Greenham Common, when it ceased to operate as an airbase, was blamed for the failure of transport models to correctly predict the effect of Newbury bypass. Doesn't matter whether anyone guessed the final answer, which is obviously a bit specialist. The point is I've now got people thinking about the many interconnected elements of simulating transport which is a great intro to the topic.
Much of the time, there's a machine already there ready to go. If that's the case, probably best to use it.
Seems to me that these days, the safest way to handle your slides is to have them on the web, with a backup on a USB drive. No need to worry about operating systems or video modes. The site's IT guys already did the work.
There are various shiny frameworks to do this (revealJS.com et al), but even PowerPoint presentations can be viewed in-browser, with OneDrive.
> prevent reading the slides out loud
Good advice.
> Use images and videos, they can tell more then a thousand words.
Indeed. This hints at another good 'rule': avoid wordy slides. Let your talk itself be the wordy bit. The slides just support.
> Also, relax, the audience has already decided they want to listen to your presentation.
Well, not always.
Physicists are so used to looking at plots most of us are really good at interpreting them. But this is a hard-earned skill. If I talk to the general public I have to take great care in keeping plots and graphics really really simple.
I hear the humanities have similar issues with text. So whatever your background is, tailor not just your content and language to the audience but the visual language as well.
https://en.wikipedia.org/wiki/Situation,_task,_action,_resul...
So, if I understand gnur's meaning, you present a situation you were in, what task (or target) you were attempting to achieve, the actions you took, and the results.
"The website suddenly went down as traffic increased. I needed to find out which backend service was becoming overloaded and triggering the failure. I quickly deployed and configured WhizBangMicroservicesAnalyzer, and used it to assess the current status of our various backend microservices. It detected that our caching servers were running out of RAM due to a misconfiguration causing them to hit a corner case. I was able to fix the configuration error and bring the website back online."
two are still too few IMO (I'm not a native speaker but still). I like to do at least ~5, where I can get a feel for the sentences I'll pick for transitions (like some sort of theater play) so should I get stuck somewhere I know how to transition to the next talking point/topic.
>Do not use a linux machine,
eh, my experience with linux machines was mostly positive, what I can recommend though is to have the slides ready (4:3 and 16:9 aspect ratio) in the cloud as a "safety net"
Personally, for me to feel very comfortable in delivering the talk, I practice the whole presentation at least five, six times.
The first couple of those practice runs, I tend to adjust the slides and my talk, to iron out the wrinkles in either my slides, my words or the transitions/logic between the slides.
The latter practice runs are essentially to memorize the whole talk. I typically write out my whole speech in the speaker notes, but after two-three practice runs I don't need to look at them anymore.
The result is a presentation delivery that as an intronerd I'm very comfortable with -- even the jokes have been practiced and perfected -- and one that I could deliver practically verbatim the next day.
I have done a lot of presentations over the years, and to the best of my recollection, every single one has been done using a Linux machine, and this has mostly been a non issue.
I think a better adage might be "get there early so you have time to deal with technical issues, bring any potentially required adapters, and have your presentation on a thumb-drive in case you need to borrow someone else's machine to present in a pinch." I say, "on a thumb drive" as opposed to "in Dropbox" or whatever, because you may rarely find yourself in a position of not having net access in the location of the talk.
https://en.wikipedia.org/wiki/Situation,_task,_action,_resul...
I'm not sure if I agree with that, in my experience they seem to fail or underwhelm about 50% of the time.
1. I simply don't think its true - there have been many talks where I have become interested 10 minutes in.
2. It puts tremendous pressure on the speaker for some kind of fireworks in their first 10 seconds.
Your 10 seconds went badly? Who cares just make sure the next 10 seconds are interesting, or the next.
As far as its actual effectiveness, it doesn't seem meaningful to involk anecdotal data (i.e. "I've seen counter examples") as the parent post isn't stating that you must, but rather it's a generally good idea or a hack.
Given the data around interviewers making pass/reject decisions within the first few minutes of an interview, I would find it surprising if it wasn't true.
The effect is supposedly about lighting up the reptilian brain, and you can drop further limbic system boosts throughout your talk to raise arousal level (heart rate, adrenaline) of your audience, which supposedly keeps their interest high. I learnt this on a demo course, perhaps it's just obvious didactic technique.
I should add it's obviously high stakes but can really make your talk stand out, especially if your talk is within a series of conventionally structured talks.
Last time I went to a conference I was actually a little surprised by the number of people at the talks who where clearly working during the entire thing. Why bother, you most likely pay for the plane ticket, the hotel and the conference it self, and then not pay attention? If you're only interested in one talk, then just go to that one and then leave.
Given that people mostly show up to technical talks of their own free will, I don't think you need to trick them into paying attention. It's fair to assume that they are generally interested and focused on what you have to say.
On another level, sometimes I go to meetups in my area which are technically the same conference presentation as well. There are times when I regret going to the meetup (There's 10-20 people) because of how boring the speaker is or how overly technical it becomes, but I don't want to be rude and leave the area cause it'd reflect poorly. Its not like a convention where leaving is okay, everyone in the area knows each other.
If I feel like the speaker is just lazy then I'll get up and go somewhere else.
Note that this only works above a certain size: if it's happening in a conference room I will at least pretend to take notes on paper instead of reading email / HN / bugs / etc.
I'm not really sure whether this makes me more considerate, or more duplicitous, or maybe both.
Nearly all of the interesting things at conferences happen between the talk sessions. Usually, at a bar. Usually, at about 11 o’clock at night. The reason is a lot of people go to conferences has everything to do with networking, and politics. Sometimes, they actually go to talks too.
For topics I'm familiar with, however, I find most talks too simple so I might as well get work done while vaguely listening. Ideally the talk would get more complex, but it usually doesn't.
(Fun fact, the first conference I went to had like five coffee breaks per day, and I got a coffee at every break and complained to someone at dinner that there was too much coffee and not enough talking. They explained it to me quickly enough!)
- Ask yourself what is your real goal of the talk. Are you trying to teach people something? Or are you making a live-action advertisement for a product/service (or for yourself)? Optimize your talk ruthlessly for that goal.
- If you're doing a talk in front of a small audience (say, 30 or less people), and you're going to discuss details of code or charts presented on slides, then put all those code snippets and charts you want to discuss in a single document and give everyone a printout. A printed document has much higher resolution and quality than a slide (especially for the people sitting in the back), and will allow them to look back (or forward) at an important figure if you're currently showing another slide. Paper is cheap and quite ecological, so don't worry about that.
When I first started, I got practically physically ill while giving a speech, and I was very, very nervous. I realized I either had to learn to give speeches smoothly or I would essentially partially cripple my whole career. The first time IBM asked me to give a speech in New York one evening, I decided I was going to give a really good speech, a speech that was wanted, not a technical one but a broad one, and at the end if they liked it, I'd quietly say, ``Any time you want one I'll come in and give you one.'' As a result, I got a great deal of practice giving speeches to a limited audience and I got over being afraid. Furthermore, I could also then study what methods were effective and what were ineffective.
While going to meetings I had already been studying why some papers are remembered and most are not. The technical person wants to give a highly limited technical talk. Most of the time the audience wants a broad general talk and wants much more survey and background than the speaker is willing to give. As a result, many talks are ineffective. The speaker names a topic and suddenly plunges into the details he's solved. Few people in the audience may follow. You should paint a general picture to say why it's important, and then slowly give a sketch of what was done. Then a larger number of people will say, ``Yes, Joe has done that,'' or ``Mary has done that; I really see where it is; yes, Mary really gave a good talk; I understand what Mary has done.'' The tendency is to give a highly restricted, safe talk; this is usually ineffective. Furthermore, many talks are filled with far too much information. So I say this idea of selling is obvious.
1. Don't start your talk by apologizing. "Well, first I need to apologize. I'm insanely jet lagged, and so I'm not sure how coherent this is going to be." "First, I'd like to apologize. This is actually a revised version of a talk I gave in 2009." "Let me start with an apology. I have a terrible head cold."
Just stop. If the talk is incoherent, you'll just have to do your best on the spot. If you're tired, too bad. If you think people might have trouble hearing you, say so. But don't apologize. People do this because they're nervous, not because the audience has been insulted or aggrieved in some way, and while it might seem like a friendly gesture, it's more likely to communicate that you're unprepared. Or nervous. And it's a cliche.
2. Do not ever go over time. In fact, go under time. As Edward Tufte once said, "No one ever left a presentation wishing it had gone on for another 45 minutes" (or something like that; you get the point).
3. Do not read your goddamn slides to the audience. Please. That is not "giving a talk." You can maybe do that if it's a long quote, but don't read the bullet points that everyone can clearly see right in front of them. Expand on them, provide counterpoints to them, whatever, but do not read them. If you're thinking of your slides (when you're creating them) as "what I'm going say," you're probably doing it wrong.
4. Use a laser pointer sparingly or not at all. Use it only to make a precise gesture necessary to point something out very specifically on a chart or map, and then shut the thing off. Making dizzying circles around every bullet point is incredibly annoying.
5. "Never mind the mic. Can everyone here me? I'm just going to speak loud." Unless you're very experienced with this (professional teacher, actor, or something like that), you probably don't know how to project your voice for twenty minutes. Get the mic fixed and use it. If the mic can't be fixed, speak way louder than you think you have to (without shouting). This is a learned skill, and most people don't know how to do it (but think they do). If the venue is large enough to require amplification, it's there for a reason.
6. Speak at a moderate pace. People speak fast when they're nervous. The proper pace will feel a bit slow to you, but perfectly natural to the audience. Check yourself periodically. Write it down on your notes. Slow down.
7. If some parts of the information you're trying to communicate are very dense or there's some useful data that will help to contextualize your presentation, create a handout. Do not try to cram it all into a slide.
8. Take some time to try to imagine every conceivable question you might get in the Q&A. You won't hit them all, and things do come out of left field, but you don't want to be caught totally off guard. Just review any common misconceptions or objections to what you're saying, and give some thought to how you're going to respond. Some people just want to comment. Thank them, briefly offer a comment if appropriate, and move on.
9. If you feel the need to ask a question like, "Does everyone know what a frubazzle is?" don't. If the question is warranted, then you can be absolutely sure that someone in the audience doesn't know what that is. Just say, "Some of you may not be familiar with the term, 'frubazzle.' A frubazzle is a . . ."
10. Commit to getting better and better at it. When I gave my first talk (in grad school), I thought, "It's going to be really embarrassing when I faint dead away in front of all these people," and I made a lot of mistakes. Today, I have only the slightest pang of nerves when I step up, and it goes away immediately. When you hear a good talk, try to figure what made it good. How did the speaker behave? How were the slides set up? Did they do anything that you can incorporate into your own presentation "style?" Public speaking is an ancient art, and you need to treat it as you would the art of writing or the art of coding: with care and study.
Remember to pause and speak slower. It gives the impression you are really considering what you are about to say next and allows you a break.
Don't drink alcohol before the talk (unless you need a shot to calm your nerves) and do have a bottle of water available as your mouth will most likely become dry.
Lastly relax. The audience is unlikely to call you out unless you make a total hash of it and they usually want you to succeed.
Great insight, and I've found that to be true. Most of the time, they selected your talk based on their interest in the contents (and less so on your delivery), and so they want to learn a thing or two. They will be graceful towards your presentation (style, delivery, slides) if at the end they got what they came for: you sharing data, knowledge, insights or wisdom. You don't want that too difficult for them, so you should work hard on improving your presentation delivery, but sharing knowledge is appreciated over sharing jokes or just well-designed slides.
Usually the first part of the story of a tech talk explains what the problem is. Many tech talks fail because the audience either doesn't understand the problem, or doesn't believe your problem needs solving. Think carefully who your audience are, and ensure you explain the problem in enough detail that you connect with your audience.
The middle part of a tech talk then is usually spent on explaining your solution to the problem. If you've explained the problem well, that the outline of the solution will basically work should be reasonably self-evident. Many tech talks fail here, because they dive too deep into the details too fast. Again, know your audience, so you know how deep to dive. You can never fit all the details you have in your head into a talk, so think carefully about what the most important features of your solution are, and focus on those. Keep less important details for backup slides you can turn to if asked.
The third part is usually evidence that your solution works. Often this involves graphs. Again, focus on only the most important results - more than about three graphs and your audience will switch off. Explain the experiment, and explain what the axes represent. Way too many people don't spend enough time on this, so no matter how good the data, no-one understood.
Finally, your conclusions. What did you learn? How complete is it? What are its limitations? You're not entirely doing a sales job, and your audience are wise enough to know that your system will have limitations. You should be the one to explain them, rather than have them come out in questions (when they'll start to doubt eveything else you told them). Finally, what future directions do you think should be taken?
Of course, different talks have different shapes. Find what works for you. Sometimes you need to iterate between problem - solution - new problem - revised solution, etc.
When you present, know your first few sentences by heart, because you'll be nervous. After that, it matters less, you'll have settled into the talk, and you'll appear less stilted if you're not reciting a script. Most importantly, turn your excitement dial to 11. If the audience feel you're not excited by the work, why would they be?
Don't spent 10 minutes on the introduction. A very common mistake is people step too slowly through the setup material. Just lay out the problem and GO. In fact, even throughout the talk, assume the audience is smart and can fill in the obvious blanks.
You know when you were a kid, and you had that one funny relative who'd always tell great stories? Be that relative.
Some people are good at wrapping tech talks into interesting stories. But they are very rare in my experience. If you don't have a story to tell, don't force it. Don't try to present everything as this grand idea that's related to everything you've done since childhood. It gets old really fast.
I've seen students take a course in speaking where they hammer into them this "three act structure". Invariably, the talks they give would be much better if they would just stick to the technology.
Briefly, rather than using topic titles ("Experimental Setup", "Results"), use assertions ("Sampling occurred over 5 days", "Sunlight causes significant degradation") as titles. Then the bulk of the slide is some information, preferably graphical, that supports the assertion. Reading the titles in order should give you a strong sense of the presentation content.
I strongly recommend "The Craft of Scientific Presentations" by Michael Alley, which covers the assertion-evidence approach, and a host of other practical topics.
Even if you don't go all the way to using the assertion-evidence style, titles are a great place to summarize the main point of the slide. So rather than "Results (3)", use the space for something more descriptive like "Velocity vs time during reentry".
Before creating a single slide, write down sentence by sentence, word by word, what story you want to tell. You can use tools to get a very rough metric of how long your written text will translate being spoken. Stop when you reach your talk length.
Once you are done, you can start creating slides. Choose what you like the best and what fits your story. Few slides, many slides (e.g. Pecha Kucha), no slides.
I would never do live coding but show small videos instead. I have seen live coding fail more often than being a great success. But if you want to do so, have a fallback video at hands.
Now your rehearsal: Not 1 full, not 2 full rehearsals, do as much as you can! For my last and very first talk for a conference I did like 20 full rehearsals, 5 of them in front of people, some in the living room, some in front of the mirror. I bet this can be less in the future but it got me super confident. Rehearsal matters! Don't be lazy and you will be amazed how confident you can go into your talk.
When you black out during your talk, don't panic because you have a full script which you could theoretically read word for word. That always calms me down.
Good luck and have fun.
It has all the same difficulties as a regular talk, but with some added handicaps:
- no ability to make eye contact with your audience and feel the room
- no way to talk over small errors, if you get stuck on a bug it can take you 10 minutes to find your way back out
- very difficult to keep the audience’s attention since all they see is a wall of text
- talking and typing at the same time is really hard, you get to enjoy stammering your way through fumble fingers
In short: only try a live coding talk after you have a lot of presentation experience.
I find it helpful to go train the whole talk with a metronome (at a slowish tempo) to have an upper bound on how much time the talk will take.
If you write slides with bulletpoints and read them, then er, just, don't.
Another point I found out _after_ I presented is to better avoid any caffeinated drinks -- apparently it makes your mouth dryer. Adding a bit of nervousness makes matters worse and you end up having to drink a sip of water every few minutes.
Start with a bang. Have a controversial opinion? Lead with it. The slide with your name probably shouldn't be the first one, unless the conference makes you start that way. This goes back to point one -- telling a good story. You know how most movies start with something really exciting in the first few minutes? This is called the "inciting event" and is what drives the narrative. Your talk should have that too.
I also recommend a fantastic book on the topic by head of TED conferences, Chris Anderson - "The Official TED Guide to Public Speaking". It helped me immensely when I was preparing to my first big public speaking event.
I also like to record myself because sometimes I find a good way to explain something, which I want to remember and explain the same way during my talk. It also helps with pacing. Am I too slow or too fast?
Talk clearly, look at your audience, if it's hard to hear what you're saying at all then there is no point.
Make it clear what the problem you're solving is, why solving it would be nice, why obvious solutions aren't good enough, then work towards a big payoff at the end. Show that your tech solves the problem, and does it very neatly!
When explaining stuff, use examples.
2) Read "The presentation secrets of Steve Jobs" ... its not really about Steve Jobs so much as its about how to be a great presenter.
3) building or writing a talk is significantly less important than the delivery... which means that more of your time should be spent on how to deliver the speech (recording I find is the best way to practice)
4) Pick a single thing and do it well, do not attempt to put too much into a talk or tackle something massively complex.
5) Make sure that everyone is walking away with something they can actually use. This doesn't require it be a hard skill... "Soft" or philosophical utilities are just as good
6) Have Fun and be funny... Speakers have a tendency to want to show off the size of their intellect, and the level their competency- having a speech be entertaining is way way more important.
7) DO NOT READ FROM YOUR SLIDES. know your shit. slides are supplementary
Extra Credit. Here's a collection of some fantastic technical speeches:
* https://vimeo.com/9270320 * https://www.destroyallsoftware.com/talks/wat * https://youtu.be/o_TH-Y78tt4 * https://www.youtube.com/watch?v=csyL9EC0S0c * https://youtu.be/a-BOSpxYJ9M * https://youtu.be/kb-m2fasdDY
I start by figuring out what I want my audience to take a way from the talk. Then I break it up in keywords and then I build my presentation.
Once that is done I practice once or twice, by my self, talking to the computer while I rearrange, add or delete from the presentation to make it what I want it to be.
Once this is done I practice, going through the entire presentation until I’m able to give it on the fly if I was woken up at 4am. I don’t practice it word for word though, but when you’ve talked about a subject enough times, you can do it again.
The practice but is really, really important. Especially if you’re not used to giving speeches. At first I thought that if I just practiced in my head, I’d be fine, because I knew what I wanted to say. Hah, not so. The first time I gave a presentation I was a stuttering incoherent mess, because I hadn’t practiced by saying the words out loud. I knew exactly what I wanted to say, I just couldn’t.
Now, many years later, I don’t have to practice as much because I’ve gotten better verbally. So yo can definitely be the type of person who doesn’t need to practice out loud. But I had to do more than a thousand presentations to get to a point where I could comfortably skip practicing on short presentations and only doing it once or twice on long ones.
As for questions afterwards, take your time to think about your answer, and if you don’t know the answer, then be honest and always, always be polite and affirmative. If you make people feel like they asked a good question, even when you think it wasn’t, then they and everyone around them will like you better. This too gets better with practice, but it’s obviously not something you can practice on your own.
Humor is typically a good thing, it relies a lot in timing and it sometimes falls flat. Just never do it at someone’s expense.
For each slide, think about what the audience take-away is. They should learn something from what you say for each slide.
Mingle and introduce yourself to a few people before your talk but don't tell them you are a speaker. Before you get on stage see if you can find them in the audience and pretend you are talking to them and not a huge audience. If you can't find some known faces, pick one from the first few rows. Helps with the nerves.
Until you get good at speaking, you need a lot of rehearsal for each talk. Present once in front of a willing friend and then after making corrections, get a few volunteers at work to be an audience. As many rehearsals as possible.
Slow down. Pause. People need a little time to digest each idea. Your material is new to them.
Like everything in life, the only way to become good is to make mistakes. With speaking you do that in front of a lot of people. It helps if you can laugh at yourself and be forgiving. The audience will often treat you the way you treat yourself.
1. Don't read the slides to your audience. Generally speaking, the audience can read.
So what are slides for then? Well, if it's a text only slide, I treat them as being there to be reminders of what I'm supposed to talk about now. And that's it. The content is what I say, not what's on the slide. So there doesn't actually need to be much on the slide at all. Just a couple of bullets to reflect the high points of the conversation. Now graphics are a different story.
There are exceptions, of course. I've been known to do a slide with a massive list of "things" in 10 point font, with like 30 items on it... but when I do that, it's to make a point - a point like "there are a fuck-ton of options for X" or whatever.
The other thing I try to do, is put links and pointers to other resources somewhere in the deck, so that sharing it with the audience actually provides some value. If you adopt the "very information sparse" slide format, then the slides don't really provide much value to the audience after the fact. Whether that's an issue or not is kinda up to you.
Version control your slides. This is particularly useful if you end up giving the same talk more than once as you can tweak things and improve it.
It's a tech talk, not a stand-up comedy routine. Light jokes and colorful anecdotes help with connecting to the content but the substance should stand on it's own.
Depending on your alcohol tolerance 1-2 drinks can be remarkably effective at smoothing out your delivery.
I find a small intro on the format of the presentation to be helpful at setting expectations. The talk descriptions are often very short and it's hard to gauge what's actually going to be covered with a lot of "Deep dive into XYZ" barely getting your ankles wet with real code. It's appreciated (as an audience member) to know in advance what you'll be getting.
The lead up from call for papers to actual conferences is usually 4-6+ months. Assuming you submit a talk without any content prepared yet and spend the first two months procrastinating, that leads 2-3 months for put together your outline and slides.
> For tech talks where you need to present results, sometimes results dont arrive until the morning of.
That's a specific case and hardly the norm. Plus you likely know the direction of the results without know the final 7 decimal points. The latter you fill in as it comes.
> Secondly, there should be a measure of proaction - gauge the audience and adjust the talk accordingly. In fact, I'd go the complete opposite, keep adjusting your slides until you're comfortable. But yes, do time yourself.
Definitely play the audience but if you haven't practiced your content you have to spend more time coming up with phrasing rather than shifting over, or dedicating more time to, a section.
> Generally IMO a minute per slide is a good ballpark. This means your slide is not too empty or too full, and you can talk about the material in the slide without reading the slide out.
I vary widely from 20 seconds per slide for a quick succession of minor points to 3-4 minutes when there's a code sample to talk through.
This is also why practice is so important as you get a feeling for where you can spend more time if you have it and where you can cut out if you don't.
Another thing is, tech talks tend to be as dry as the Sahara desert. So try to make your talk interesting. Do not just focus on getting the information across, but make it fun to listen.
Practice your talk without slides. This has two benefits: You concentrate on the content, so your stuff by heart at the end. And you don't depend on the slides, in case something goes wrong.
Lastly, prepare for 4:3 - even if they say you get a 16:9 beamer, chances are it's not. And prepare for offline, your Laptop being broken and in case you are doing a live demo: Have a video of it as a backup.
These tips are all just from my experience and may not apply to you, but maybe it's helpful. :)
Also... nothing can quite prepare you for how shot your nerves can be. It definitely pays to run it through many times as you can with a timer so that you are at least confident in your pacing.
Other than that it's quite fun.
It can be pretty handy to you to include your twitter handle in the top right corner so you get some follows throughout the presentation from people who were interested. At the end link off to 'you can find the slides for this presentation here bit.ly/soloyolo' etc.
It's SO easy to assume knowledge. When I talk about python, I now give a quick intro to the command prompt. I started out assuming everyone knew how to use the command prompt. A lot of times, you forget that the stuff you "just use" may be new to the listeners.
get there very early and check that the tech is sorted.
have a short list of explicit goals - feel free to write them out.
practice at least once, for real, out loud. If no one will help, present the talk to a stuffed bear.
do not read your slides to the audience.
expect live demos to fail - have a practiced contingency plan.
no lewd illustrations and don't put people down - you are in a position of responsibility.
at the end, sum up.
* start by telling everyone what you're going to tell them, then tell them, then tell them what you just told them;
* know your material well enough that when your computer stops working you can carry on seamlessly;
* rehearse in front of a mirror or record and watch yourself;
* if you're talking too quickly, take a quiet breath and make sure you pronounce the last letter of each word that you speak;
* switch your slide to black or white when you're making a very important point, and have them focus on you instead of the screen -- use `b` key for black and `w` key for white, works with most presentational software I've used;
* …and smile
[quote]
First, most important rule: Before you start drawing any slides at all, write your talk as a short essay.
This is the number one mistake that presenters make, and it is partly a tool fault, because PowerPoint, OpenOffice, even Tech Talk PSE, all open up on an initial blank slide, inviting you to write a title and some bullet points. If you start that way, you will end up using the program as a kind of clumsy outlining tool, and then reading that outline to your audience. That's boring and a waste of time for you and your audience. (It would be quicker for them just to download the talk and read it at home).
A good talk, with a sound essay behind it, well thought out diagrams and figures, and interesting demonstrations, takes many hours to prepare. How many hours? I would suggest thinking about how many hours of effort your audience are putting in. Even just 20 people sitting there for half an hour is 10 man-hours of attention, and that is a very small talk, and doesn't include all the extra time and hassle that it took to get them all in one place.
[/quote]
[1] https://en.wikipedia.org/wiki/Tech_Talk_PSE
[2] http://git.annexia.org/?p=techtalk-pse.git;a=blob;f=techtalk...
I gave a talk a year ago about Continuous Delivery, despite being a bog-standard developer that has had to do it on a couple of occasions. I had some general rules that I could carry across from one company to another, so my talk was around these general paths to happiness, and discussing the tools I have used, alongside a generous Q&A.
The questions were all fairly straightforward, and a number of people came up to me at the end to share the same sentiments - they were developers that had been roped into doing sysadmin stuff, and that they found the talk and answers to be very useful.
I have a theory that people often go to talks not to learn something new from an expert on the subject, but for a structured developer chat around an approach on a subject that seems to work for someone in a given context. If they've attended, they're interested in the subject, so as long as what you say is on-subject and clear it's difficult to give a bad talk. From there, it's mostly around delivery, which comes with practice and preparation.
So you want to say something. Say it.
Don't start your 20 minute talk by spending two minutes going over an outline of it, saying that you'll first present the problem, then review past work, then blah, blah, blah. I HOPE that the thing you want to say isn't "I've spent a lot of time organizing my talk like this..."
Don't start your talk with a funny anecdote about the driver of the taxi you took from the airport. I hope that THAT isn't what you want to talk about either.
Do start by describing the problem you're solving (you are solving some sort of problem, I assume...?). But only to the point where the audience can grasp what you're trying to do. Review past work only if the focus of your work is something like "I fixed the problem that the XYZ algorithm unnecessarily recomputes A...". You can mention how past work relates to yours at the end of the talk. It will make more sense then.
Get as quickly as you can to WHAT YOU ACTUALLY ACCOMPLISHED. I hope that's what you want to talk about.
Alice Goldfuss' recent talk on containers[1] is a really good example of what I'm talking about - she spends a good amount of time talking about what containers are, and why and when it would appropriate to use them, but she spends an equal or greater amount of time preparing the audience for what challenges they will encounter when implementing containers and talks about when you're probably better off without.
If you're having an interactive part, be aware that it is hard to estimate the time this part will take. If you have a hard deadline, be ready to skip some parts (this is a good idea in general as things may always
It's probably best if you are so familiar with the topic that you don't really need slides in the first place. On the other hand, take care to connect with your audience and take their background into consideration.
Know the language and culture of your audience. If it's a mixture of people who don't speak English (or whatever language) as their first language, take care to avoid colourful metaphors that make sense to a native speaker but which confuse non-native speakers. I've confused people with expressions like "inside baseball" or reference to "Goldilocks values" (not too much, not too little). Good metaphors are valuable. Metaphors that depend on too much cultural context are unhelpful.
Although slides often don't contain much information that needs to be read in full detail, I find code examples to be better readable in a dark font on a lighter background.
Sometimes the conference gives some advice regarding the slides (dark text on light backgrounds or vice versa), since they'll know / set the room lighting conditions.
- Plan for the worst-case scenario, e.g. your computer dying. All my presentations are available on GitHub Pages[0] (using RevealJS), so all I need is a random laptop.
- Use a bright color theme on a beamer to improve readability (slides, console, editor/IDE). Dark schemes are nice, but they are inappropriate for most presentations. Bonus: when using HTML slides, you can design both a bright and dark theme and switch depending on the light conditions.
- Don't put too much on your slides.
- Don't put too much on your slides
See if you can do without any bullet list. Now you are forced to talk from your experience in a natural form. You'll be fine.
More serious:
- don't go into the trap of too much introduction and theory before getting to the actual matter. E.g. when doing a talk on GPU image processing don't spend 30 minutes on how a GPU works.
- Know your audience experience with the matter if possible (see above)
- If possible, do demos. If have demos, consider if it makes sense to run them _before_ the tech slides. They tend to make more sense after seeing a live demo.
- If you have demos, rehearse them. Make sure you get the timing right.
- leave room for questions.
Way too many times I’m sitting in the audience, the person at the front is exchanging smiles with the programme committee who all know each other, but I have no idea who they are and what drives their viewpoint.
Keep in mind who you’re talking to and what they’ll bring home from your talk.
Will they use it on their job? Then it’ll need operational details. It’s just something cool you did? Make sure it’s a good story with villains (problems) henchmen (bugs) and it stays relatable all the way to the victory. Is somerhing that pushes the envelope of what’s known? Make sure to establish the state of the art and guide the audience through the wonder of the discovery process.
This way I don't overspend time on tools, but on content.
Hope this helps
- Right before the talk: get to the room well ahead of time and make sure there are no setup issues with the laptop, audio, projector, etc. I've seen a number of speakers fail to do this basic thing and it dampens their flow, confidence, etc. The audience might even get distracted and the whole show goes awry.
- Prepare and practice the intro speech, don't wing it: if you have a good opening, you'll feel confident and the momentum will carry you through the rest of the talk.
I find that talking it through a few times with someone will help you figure out which parts of your explanation are unclear and need rephrasing.
Also, don't take it too seriously - technical talks are already often dry - don't be afraid to insert some memes and jokes to keep the audience engaged!
You can always put slides and examples online and refer to them, especially if in another country where people might not keep up with your native language.
Smile a lot!
1. After you tell me what you're going to talk about, tell me why I should be listening to _you_. Why are you an authority on this topic? Unless you're famous, I don't know you.
2. The talk should contain 50% or less of your knowledge on the topic. You want to keep some info "in your back pocket" to ad lib with.
Interesting. I never do this, and probably never will. My viewpoint is that you've already made the decision to attend the talk, so me spending time reciting my bio is just redundant and a waste of time.
It takes at least ten seconds for people to formulate a question well enough to ask it in front of everybody. Have some patience. Bonus points for having something low-key to fill the awkward silence.
http://blog.voxgig.com/2018/07/13/welcome-voxgig-newsletter-...
[1] https://gist.github.com/snare/7f0c4708bf4ea8133204c21e8ba64d...
- Understand what are your takeaways for the audience. Remember it's about the content, keep in mind main areas/topics to cover.
- who's your audience ?, there are a few conferences where going very technical (low level) matters, most of them want to focus on how X works, how to solve Y, etc.
- "Start with why". Yeah, it should sound familiar, check this 5 minutes video: https://www.youtube.com/watch?v=IPYeCltXpxw .
- Note that likely in the first 3-5 minutes the audience will have a > 90% focus on what are you talking about, make sure to take advantage of that time with a good "why" (see above) for engagement.
- Share your presentation slides with a colleague and wait for "honest" feedback.
- Storytelling. Humans engage in stories. Prepare yours.
- Rehearse. Rehearse. Rehearse. And when you are done, rehearse again fixing everything that was not perfect.
I'm in the physical sciences and routinely give fairly math-heavy presentations.
It's easy to think that an audience of Phd's and professors know all prerequisites and just need the hard facts in a rapid succession.
On the contrary over time I found that my audience typically appreciates when I start from the very beginning (in my case meaning advanced undergraduate level or so), and working up to the actual problem setting.
Although my audience is very much expected to know that material they A) get primed for the topic and have a chance to feel good about 'I know this' and B) understand my view of the topic so that we have a common language.
With that I'm ready to frame the technical problem and explain my work.
The last time I did this I actually spent 10 out of 20 minutes on the first part, and the talk was very well received and generated an 'invited paper' request for a journal.
No one has ever complained that my talks are 'too basic'.
EDIT: Btw, the metric I use to measure success is amount of generated questions & engagements in and after the talk. If the moderator has to cut off Q&A for the next speaker you win. If people hunt you down to talk more you win.
- Add as little text to your slides as you can
- Accept that you will get nervous. We all do, being nervous is not a problem, the fear of it is.
- Remember, the audience wants you to succeed
Then sketch an outline of presenting that information, just a rough order of what to touch on. I find that I naturally outline so that each entry is about five minutes, but I don't know if that's just me or a common tendency.
Then I get a timer, stand up, and start talking to myself. I'll take an outline entry, and try to tell an imaginary audience about it. Typically I realize that I have some questions I need to answer for myself, or I run over five minutes. Think about how to drop stuff, look up what you need, note down what bits of verbiage came out that flowed well to reinforce them for yourself, and do it again. I often get frustrated after two or three times on one item, and go do another one, then come back to it and do it some more. During this whole process pretend the perfect slide to go with your text is up next to you so you can point.
After some cycles, this will converge. You will know what you want to say, and you will know what needs to be on the slides. Now set the timer for the full talk length and give the whole talk like this, still with pretend slides. You'll probably find places where you need transitional material, and it will probably run long despite the fact that the pieces add up to fit. Adjust. Do it again. This is also a good time to figure out and memorize the first couple sentences of each section, which will let you transition easily if you lose your place.
At this point you know your talk. Now go sketch your slides out on paper, and give your talk pointing to the paper. Once you think you have what you need figured out on paper, then go turn them into a PowerPoint, PDF, whatever.
Now practice it with the slides. Practice starting from a section using those memorized sentences. Memorize your sequence of outline items with those sentences attached.
Then do a run-through the day before. The day of, I spend five minutes thinking through my outline and section starting sentences, take a deep breath, and talk as inhumanly slow as you can. Even if you don't have stage fright (I don't), you will have adrenaline, and you need to slow down.
2. Describe your approach to solving it.
In general, have something to say, know your stuff, and the rest will flow naturally.
Preparing: 1) Give yourself enough time to write and practice the talk. If you can get ~1 month, that (for me atleast) is more than enough time.
2) Say the words out loud when practicing. You may use different words or slightly improvise during the talk, which is totally fine. Just let yourself hear some version of it a few times (out loud) before presenting. In my experience this helps to avoid stutters, and keeps you in your place.
3) Watch talks of people online that you enjoy or by people that inspire you. We all have our own "style" when it comes to public speaking. You will never be able to straight up copy someone. But watch and take mental notes as you do.
4) (If you are preparing slides), keep them simple! It is YOU who is presenting the talk. Not a wall with a projector. Treat your slides mostly as an accessory. They can help illustrate a point perhaps, or outline the key subjects. Short and simple.
Presenting: 1) If you can, make sure you have a bottle of water handy when you go up.
2) When I approach the stand, platform or stage, I like to do so with confidence. This really does depend on the setting. But for example, as I walk up, sometimes I'll take my jacket off. Or do something that otherwise makes me feel like I'm owning the space. This makes me feel much more comfortable and puts me off to a good start. Even if you're not a confident person, walk up as if you are or do something simply to make you feel more comfortable.
3) Don't be afraid to use the space you have been given. This goes both for actually walking around, and using your arms to assist your words. Hands out of pockets. Use them.
4) Pauses are a good thing! Whether it's just to take a sip of water, or just a pause for the sake of pausing. This both gives you a few moments to collect your thoughts and also a few moments for the audience to digest what you have just been saying.
5) Slowww it down. It's almost too easy sometimes to rush talks when it comes down to actually presenting one. Take your time. They came to see you! So make it worth their while.
6) This is slightly tricky in some cases, but try to calibrate yourself towards the audience. For example, in my case, I've found people seem to pay more attention if I've just said something slightly amusing. If you can get away with it, go for it! It's a hard one to explain, but the bottom line is, try to get the crowd on the same page. I'll perhaps think of a better way of explaining this one and reply to this comment.
A fake example: If you're giving a talk on your new Linux shell that 's way better than Bash, you don't need to spend the first two-thirds of your talk explaining what Bash is and what its weaknesses are. Your audience probably knows what Bash is and knows enough to be interested in an alternative. Don't bore them out of the room.
TL;DR: Show first, tell second.
