Skip to content

Instantly share code, notes, and snippets.

@mipearson
Created December 14, 2011 23:09
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save mipearson/1479017 to your computer and use it in GitHub Desktop.
Save mipearson/1479017 to your computer and use it in GitHub Desktop.
Prerequisites For Giving a Presentation at a User's Group

Prerequisites For Giving a Presentation at a User's Group

You've decided to get up in front of a bunch of strangers and talk about a topic for thirty to fifty minutes. You're going to convey your unique, personal experience and everybody is going to afterwards feel as if they've learned something new.

For most talks at user groups, this doesn't happen, and it's easily fixable.

You absolutely, no questions asked, need to:

  • Know what you're presenting: rehearse it to yourself, once, out loud. If that's too awkward for you it's going to be more awkward when you're back-pedalling and skipping sections in front of thirty to fifty of your peers. If you have demonstration content, test it from beginning to end, especially the bits that you assume will 'just work'.

  • Think about how your presentation will look through a projector and at a distance. Black on white is safer than white on black because white text "glows" and bleeds together. Big fonts. No videos. If you're working a terminal or an editor, make the font bigger than it has any right to be. If people are reading more than a few lines of code, they're not paying attention to you anyway.

  • Don't depend on working, fast, unrestricted internet access unless you confirm it with the venue first. Many corporates have egress firewalls: the upshot of this is that SSH will not work.

  • This is not show and tell. The internet is full of information that is much quicker and easier to digest than listening to a stranger for thirty minutes. Identify what it is about your experience, product or process that makes it unique and focus on it.

Consider performing a short talk (sometimes called a "lightning talk") if you feel the above isn't appropriate for your content. You can get away with a lot more if you're only trying to hold people's attention for five to ten minutes.

Some people can present on the fly with nothing more than a vague idea and a whiteboard. This will probably not be you on your first presentation to a large group. If you can present on the fly, you may find that ability is limited specifically to people that you're already familiar with, so don't depend on it if working with a new group.

I'm not expecting that only great presenters talk at informal gatherings. That's obviously unreasonable. I'm asking that people stop making basic mistakes that inhibit our ability to retain information or gain value from your presentation.

@saramic
Copy link

saramic commented Dec 15, 2011

another old rule of thumb is "show don't tell" - not to say that this is easy - as a minimum remember that "a picture tells a 1000 words" a screen grab of what you are talking about is probably a good start.

@adamboas
Copy link

Yep, I agree with pretty much all of this. I might also add -
Don't babble or draw things out longer than they need to be. Make certain every slide you present has a message and stay true to that message. If you can't find an important message for a slide then cut it.
Demonstration based proposals are much harder than you imagine and require that you be able to multitask well enough to talk reasonably intelligently while you are coding (some people have trouble doing either). To do it well you need to know what you are going to code backward, just a single run of it while you work it out will not be enough for most people. If you rehearse the demo material repeatedly you will be able to speak much more naturally while you are doing it live.

@bguthrie
Copy link

Sort of disagree, actually. My attitude towards presentations at user groups is that "it's just a user group"--in a good way. It's a place to try stuff out. Often, show & tell is the whole point--it might be the first time someone has tried to show something off to a larger technical audience.

I just don't bring the level of polish and attention to a user group presentation that I do to a conference presentation; I don't have the time, and anyway, I kind of enjoy speaking off the cuff. I enjoy having the opportunity to throw stuff at the wall and see what sticks. Sometimes it works out; sometimes it doesn't. As long as I keep it brief, there are other presentations; and if they suck too, well, there's always next month.

@mipearson
Copy link
Author

@bguthrie: This is what lightning talks are for. Nothing in the above applies if you're only trying to hold people's attention for 5-15 minutes.

I'm keeping this a bit underwraps-ish right now as while it's influenced by last night's melb.js, it's something that's been bugging me about RORO and DevopsMelb since I started returning to user groups earlier this year, and I don't want it to thought of as a direct criticism of last night's talks.

@adamboas
Copy link

To be honest, I don't even like sitting through a 30 minute shit presentation from my friends, but then I have never been renowned for my patience. At a user group many of the people don't know each other, you'd like to think that new comers would be impressed by what they see and want to pass the word and come back themselves. That is really only going to happen if there is a reasonable standard.

That being said, if you are actually planning on circulating this Michael, I would probably change the tone. Possibly you could focus on the fact that it is hard to get up in front of people and awesome that people choose to take that on and share their ideas but that there are things they can do that will make themsleves more comfortable (like rehearsing, etc) and that will also make the presentation much more enjoyable for them as well as viewers. Another approach is to just say how it is going to be. It is fine to do an impromtu-ish chat about something you are working on or thinking about but maybe that could be telegraphed in advance so people could decide if they wanted to come.
Probably the most important thing is that the group be clear about what standard they expect, it probably doesn't really matter what that standard is as long as it is clear and people can decide whether they are up for sitting through talks of the given length and anticipated standard.

@mipearson
Copy link
Author

Yep, you're not the first to suggest changing the tone - I think I will need to.

I really don't want it to be "here's some stuff you can do to make your presentation better", though - it needs to be "If you are presenting for 30 minutes or more and you are an inexperienced speaker, you absolutely need to do these things to not fail."

@saramic
Copy link

saramic commented Dec 15, 2011

how do these people know they fail when none of us are likely to tell them that :) in fact they will get an applause and a positive note on twitter just for having the guts to get up at all so the level will never be raised. - take melb.js and DevopsMelb as examples.

Show don't tell, we are failing on that very account by writing this down as a mix of guide lines #fail on us all

what we need is someone to create a really cool geek video that goes viral on hacker news/twitter/slashdot what have you and everyone sees how some basic prep and key approach can may a presentation kick arse

Scene 1 a guy practices in front of a mirror till he gets it right (I have done this),
Scene 2 audience reading out a very verbose slide in "human microphone style",
Scene 3 people coming away with something that they simply could not get without an in person presnetation
Scene 4 leaving some use full hooks to get people to immediately ask some questions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment