I am trying something new with this talk. Instead of transcribing the video whenever it comes out, I decided to provide a rough version of the talk with images of the slides. I am hoping this will be easier for people to read through and reference later. I'd love to hear if this is helpful to you, so I can decide if I should continue this in the future.

This talk was given at Open Source Bridge 2014. You can find a full version of the slides on speakerdeck.

The Talk

Speaker Support of Awesomeness with Julie Pagano presented at OSBridge 2014

This talk is about supporting new speakers. It focuses on tech conferences, but also includes some related topics.

This talk is for two main groups:

New speakers or people who I can convince to become new speakers.
Consumers of talks

Consumers? Event organizers, attendees, people at home

Consumers are:

Event organizers who want people to come speak at their conferences.
Attendees who spend their time and money to come to conferences, presumably in part to get something out of the talks.
People at home who watch recordings of talks after an event.

In this talk, I will cover three main things:

Why should we support new speakers?
How do we go about supporting new speakers?
Tips and tricks for new speakers to help them level up their first conference talk.

Let's start with the "why?" Why should we support new speakers?

Why should we care as consumers of talks?

Because we want awesome talks.

Awesome talks:

Expand your knowledge.
Challenge your preconceptions.
Ultimately leave you feeling inspired and more excited than you were before.

What's not awesome?

The same people.

Giving the same talks.

On the same topics.

In the same way.

At the same conferences.

year, after year, after year with calendars for 2012-2014

Year, after year, after year.

Even with great speakers, it can get boring

Even with great speakers, this can get boring. You've already heard about what excites them and you know all of their jokes. Maybe you've literally heard this talk three times already.

Even with awesome speakers who are able to change things up and keep it interesting, this can be a problem because sometimes they want to take a break.

Believe it or not, people have lives outside of speaking at conferences. They have families, jobs, and hobbies they want to spend time on. Supporting new speakers ensures that there is a good pipeline of people to fill in when they take that break.

Unfortunately, they're not all great speakers. Many of us have been to those talks where it seemed like the speaker didn't prepare, or they got hammered the night before and are too hung over to give a great talk.

This led me to theorize a "speaker law of inertia." A person who speaks will continue to speak unless acted upon by an outside force.

I want us to be that outside force.

Because new speakers shake up the status quo.

The status quo is homogeneous...

...and homogeneous is boring.

Diversity is more interesting.

We get diversity of passions. My favorite conference talks are from people who are passionate about what they're talking about. They put a lot of effort into it, they're excited about what they're talking about, and it shows. These are often the talks that leave you feeling inspired. New speakers allow us to hear about new passions instead of the same passions from the same people over and over again.

We also get diversity of ideas. New people will bring new ideas. Even when we hear about the same old topics, new people can bring different perspectives that help us learn something new or challenge our preconceptions.

Diversity of experiences is another thing we get from new speakers. Someone who has worked in the field looks at things differently than someone just getting started as an apprentice. Someone who works for a giant company looks at things differently from someone who works as a freelancer. Et cetera, et cetera. Hearing from people with these different experiences can be really valuable.

Diversity of backgrounds is also important. This can mean a couple different things.

One is getting people who don't come from a traditional computer science background. One of my favorite early speaker talks was from a woman named Nell Shamrell who spoke at Madison Ruby a few years back. She gave a great talk that combined her past experience in theater with her current work as a programmer. It wasn't a talk you'd hear from your usual conference speaker, but it was awesome and inspiring.

Diversity of backgrounds can also mean things like gender, race, and other demographics. The software and technologies we develop are used by a wide diversity of demographics. Unfortunately, the people who develop them are not that diverse. Speakers at our conferences are even less diverse. It can be great to get speakers who understand the demographics of those users and the technology. We can learn a lot from them.

Let's not forget the elephant in the room...

...diversity of speaker lineups.

I put together a dramatization to help people understand this one.

Any resemblance to real events or persons, living or dead, is purely coincidental.

"VanillaTechConf is excited to announce the speaker lineup for 2014."

Check out this sweet speaker lineup. We've got some great diversity here. We have a dude with a top hat and monocle.

The internet gets a hold of this and says, "We are disappointed in the homogeneous speaker lineup."

The conference says, "We tried, but we couldn't find any other speakers."

The internet responds and says, "NOT GOOD ENOUGH!"

Then everyone starts arguing about it, and everyone gets upset.

It doesn't have to be this way.

Supporting new speakers can help.

Part of the problem is that there aren't a lot of diverse speakers available because very little work is done to foster new speakers. Supporting new speakers could help fill that pipeline.

On the other side of things, conferences often do a very poor job of supporting speakers getting involved in their events, especially new speakers. If they did a better job of this, they would be able to connect with the diverse speakers that currently exist and find new ones.

This two-pronged approach for supporting speakers could help us avoid repeats of this problem in the future.

Don't worry. This isn't a unicorn talk. I won't spend the whole time talking about diversity.

Let's move on to talking about why you should become a speaker.

Because public speaking is good for you!

...with exceptions. For some people because of health or personal reasons, speaking is a bad idea for them. Please do not try to force people to speak.

However, for the rest of you, if you're even a little bit interested, I think you should give it a try.

Public speaking can help improve confidence. For most people, public speaking is a difficult thing, so when you're able to do it, you feel good about that. After speaking, people often will give you positive feedback, which can help with confidence.

Public speaking also helps with confidence in other areas. After speaking in front of hundreds of strangers, a lot of other things seem way less scary. Before I started speaking, I was a pretty quiet person -- unlikely to speak up. After speaking in front of hundreds of people, all this other stuff seemed less scary. I felt more comfortable speaking up at work and asking questions. Public speaking kind of changes your level set of what's scary.

Speaking at conferences gives you the chance promote your ideas. Have a new open source project you want people to contribute to or use? Want to promote a new technique or tool? Want to get people talking about something that's important to you? This is a great chance to do that.

You will have an audience at the conference who listens to your ideas. If you do a good job, they will leave feeling inspired and share what they heard with others. Most conferences record their talks, so you also get a chance to excite the people at home afterwards.

Public speaking gives you a great chance to promote yourself. We don't like to talk about this, but who you know can be just as important as what you know.

When you speak at conferences, people start to get to know who you are. They learn your name and your face. They know about areas you are knowledgeable in based on what you talk about. This comes in handy when you want support from people in contributing to or promoting your open source projects. It's also great when you're looking for a new job.

Public speaking also gives you a great chance to meet new people. When I first started going to conferences, I found it really awkward to have to walk up to strangers and talk to them. As a speaker, I don't have to worry about this. People come up and want to talk to me and chat about my ideas. This takes a lot of stress off of me to initiate things. I've met a lot of awesome people this way.

Another reason you may be interested in speaking is being the change you want to see. When I first started attending conferences about four years ago, I was really frustrated to see almost no people who looked like me speaking or in leadership positions at conferences. For a while, I just complained about it, which is totally valid, but doesn't get much done. Eventually, I realized that I could help change at least one data point. I had ideas, and maybe I could speak.

This may not appeal to everyone, but for me it was really valuable. It helped to know that I was making sure someone who looked like me was on stage.

After I gave the opening keynote at Open Source Bridge this year, I saw a woman tweet how excited she was to see someone who looked like her keynoting. That really validated that this is important.

Before you start looking for excuses, I want to cover some of those too.

A common one I hear is "I'm not a big name."

You don't have to be a big name to speak. If you did it would lead to a chicken and the egg problem. Many people become big names because they speak a lot. If you required being a big name to speak, you can see the problem that would create.

Being a big name is not needed for conferences with a CFP.

CFP stands for "call for proposals." Conferences that select speakers this way, focus on selecting speakers based on proposals they submit. A proposal explains things like what you want to talk about, why it would be a good fit for the conference, and why people will be excited to hear it. In these cases, the proposal is often the big selling point, not your name.

Another one I hear is "I'm not an expert." This can be valid in some cases, but a lot of the time people are overthinking what they need to be an expert on.

Filled circle that says 'what you think you need to know'

What you think you need to know is the entire world around the topic you are going to discuss. However, the reality is that you're going to talk for thirty minutes or maybe an hour max. It's unlikely you can cover the whole world of expertise on any topic in computing in that short amount of time.

Partially filled circle that says 'what you actually need to know'

What you actually need to know are the topics you are going to focus on and some closely related items. It's ok if you don't know everything vaguely related to the topic. It's ok if someone comes up after your talk and asks you a tangential question, and you say, "Sorry, I don't know." Most speakers don't know absolutely everything about the world around the topic they're discussing.

Another thing that's important to keep in mind is that you are an expert on your experiences. Some great talks are about how a person or their team used a language or library to solve a problem. Talks like that don't require you to be an expert on the language or library or even the problem space. You need to be an expert on your experiences. What you did. What went well. What went wrong. What you learned. Et cetera. As someone who went through that process, you are, in fact, an expert on it.

Experts aren't always the best for the job.

It's important to keep in mind that experts aren't always the best people for the job.

Line showing experts on the far right and highlighted

Experts are all the way over here. They know a lot.

Line showing beginners on the far left and experts on the far right with the beginners highlighted.

However, many conference talks are targeted at beginners. An introduction to a language or tool. A how-to. A tips and tricks. Experts often know all of the content necessary for these, but they're so far divorced from being beginners that it can be difficult for them to make it accessible to that audience.

Line showing beginners on the far left and experts on the far right with a point in the center highlighted.

The people in the middle, the intermediates, are often the best for this. They know plenty to present to beginners, but they also remember what it's like to be a beginner. As a result, they are often better at presenting information in a way that is easy for beginners to digest.

I don't have anything interesting to say.

"I don't have anything interesting to say" is another excuse I hear.

'This is my skeptical face' with a photo of BMO from Adventure Time making a skeptical face.

My response to that is usually "This is my skeptical face."

I'm sure some of you are terribly boring, but in most cases, I think this is the impostor syndrome talking.

Getting help from others can help a lot with this one. I'll talk a little bit about that later.

Lastly, "I'm afraid of public speaking." This one is the most valid, but I want to tell you a secret. Most people are afraid of public speaking, myself included. Even many really experienced, awesome speakers still get nervous.

When I first started speaking, I was incredibly nervous. Anxiety attack level nervous. I didn't eat before my talks because I was afraid of throwing up nervous. I did it anyway, and it has gotten a little easier every time I do it. I still get nervous, but it's much more manageable than it was when I started two years ago, and it's totally worth it because of all the positives I mentioned.

If you're afraid of public speaking, I recommend at least giving it a try once or twice. If you really hate it, you never have to do it again. However, you may find that you're like me. You get a taste for it, and it's worth the nervousness.

Let's move on to the how. How do we support new speakers?

We need to give and get support, and we need to do it actively. If you're a new speaker, you need to say, "I'm interested in speaking, and I need help." If you're in a position to help new speakers, you need to say, "I want to help new speakers. Here I am." If these groups quietly sit alone waiting for someone to find them, they never connect with each other, and support never happens.

Let's start with event organizers. As people who need speakers for their events, they should absolutely be involved in supporting new speakers.

Field of Dreams Conference call for speakers. If you build it, they will come.

Unfortunately, a lot of conferences take a "Field of Dreams" approach to their call for proposals. They assume that "if you build it, they will come." Unfortunately, this doesn't work.

Field of Dreams Conference call for speakers. NOPE.

This approach tends to lead to the sort of homogeneous speaker lineups I mentioned earlier. When you don't do much outreach or support, you reach a limited audience. That audience is often the network of the organizers, and if the organizers are a homogenous group, the network they reach is also likely to be homogeneous.

Conference organizers need to put more work into active outreach and support. This will get more people interested in speaking at their events, and a more diverse group of people.

PyCon is a great example of a conference that has been working on this. They had 1/3 women speakers and 1/3 women attendees this year. I doubt the correlation of those two numbers is a coincidence.

It's notable how they reached those demographics. They did a lot of very active outreach to get more people to submit to their call for proposals. They were contacting people and saying things like, "I would love to see you submit to PyCon's CFP. I think you would be a great speaker." Not only did they ask people to submit, but many offered to help with proposals for speakers who were not as familiar with the process. This wasn't about quotas. It was about doing active work to reach more people and encourage them to get involved.

It is also notable that this outreach led to a great conference lineup. Many of my favorite talks came from people who got involved because of outreach. My favorite talk at the conference was from Julie Lavoie and talked about analyzing rap lyrics with python. She mentioned later at the conference that she submitted because of outreach and got help with her proposal.

Here's a tweet from Jessica McKellar about this.

"Hello from your @PyCon Diversity Outreach Chair. % PyCon talks by women: (2011: 1%), (2012: 7%), (2013: 15%), (2014: 33%). Outreach works."

This shows that change doesn't happen overnight, but if you put hard work into it, change can happen. It's also notable that Jessica's title here is "diversity outreach chair." They had an entire role dedicated to making sure that this work happened.

Next are experienced speakers. I want you to make sure that you pay it forward and help new speakers. Even if you only do it for selfish reasons. You also attend conferences, and presumably you want the other talks to be interesting. One day you're going to want to take a break, and it is a good idea to encourage new speakers to fill your place when that happens. There are a bunch of different things you can do.

One of the easiest things is "planting the seed." What I mean by this is telling someone that they can speak and encouraging them to do so. Many people don't even think about speaking or don't think they are qualified to do so. A little encouragement can get them on the right path.

For me, this happened on a speaking support hangout through the DevChix google group. I was interested in speaking, so I thought I'd at least talk to a few people. I got on a call with Sandi Metz and Chiu-Ki Chan, and they helped plant that seed. They told me I should try speaking. That it was worthwhile. They let me brainstorm a few ideas and offered to help later if I needed it. It took about a year after that hangout before I started speaking, but if not for that hangout, I might have never tried at all.

Another thing you can do is provide advice. Write a blog post with advice for speaking. Give a talk about talking like I'm doing right now.

Try mentoring. Find a couple people in your local community and work closely with them to help them become speakers.

Last, but not least, you can start a support group. That's what I did, so I am going to expand on that one.

Tech conf speaker support of awesomeness.

I run a support group called the Tech Conf Speaker Support of Awesomeness. (I know it is a silly name.)

I started this group a little over a year ago when myself and some of my friends were interested in getting involved in speaking at conferences. We weren't sure what to do, and we didn't want to do it completely on our own, so we decided to get together and support each other. We were all over the place, so we communicated via email through a google group and "met" via google hangouts. We meet about once a month and help members of the group with whatever part of the speaker process they need.

I am going to walk through the basic steps of the process we tend to help with in the hopes that this will help others create support groups of their own.

We usually start with brainstorming. Remember when I talked about people thinking they have nothing interesting to speak about? This is where we help with that.

We talk to people about their passions, what they're excited about, their work, open source projects they're involved in, et cetera to try to get a feel for what might be a good topic. Usually we're able to come out of this with two or three ideas that would be a good fit for a conference talk.

Next we help people find events that will be a good fit for their ideas. We look at things like fit for the audience, location, cost, what CFPs are open, and information provided by organizers. We usually come out of this with at least a few events that are a good fit for someone's ideas for talks.

Once someone has an idea for a talk and an event they want to give it at, they need to get accepted to speak. This is where proposal writing comes in, especially for new speakers. Proposals for new speakers are similar to resumes for getting that first job. They help you get your foot in the door, and you should get help to write them.

Getting help with writing a proposal is useful for all speakers, even really experienced ones. For new speakers, it is critical. You want a fresh pair of eyes to catch typos and grammar mistakes. You also want them to give you feed back on the content. Things like, "this title is confusing" or "your proposal is too long" or "I think you could make this more exciting." That feedback can take a mediocre proposal and turn it into a great proposal.

I try to do this for all of my talks. I got help with the proposal for this talk (thanks tef!) that took it from average to a talk that was accepted at Open Source Bridge.

Expectations management is another important thing we do, especially for new speakers. Without properly adjusted expectations, the process can leave people crestfallen.

As our friend Jake the dog from Adventure Time says, "Suckin' at something is the first step to being sorta good at something."

A big part of expectations management is the proposal process. Without good expectations, someone can be devastated by having their talk rejected. The reality is that rejection is completely normal. Even experienced speakers often get their proposals rejected.

I helped organize the proposal selection process for a conference last year. We had about six slots open for talks from the CFP, and we got around 100 submissions. We had to reject a ton of awesome talks because we only had so many slots available. Rejection is often just a matter of numbers, not a value judgment.

It's worth asking people for feedback to see if you can improve a proposal, but rejection doesn't mean you've done anything wrong. I have talks rejected all the time, but it's worth it to keep trying.

Another part of expectations management is managing expectations around your first talk. If you assume your first talk is going to be this amazing TED-style talk with a million hits on the internet, you're setting yourself up for disappointment. Public speaking is a difficult skill, and it takes time to improve. It's important to set reasonable goals.

I was terrified of public speaking when I first started. My goals the first time I spoke were: 1. I will give my whole talk and 2. I will not throw up on anyone. I know that's a really low bar, but I gave my talk, and I didn't throw up on anyone. SUCCESS! I was able to focus on the fact that I succeeded at public speaking and feel like I accomplished something. From there on, I slowly moved up that bar and aimed for improvement.

Once someone gets their talk accepted to a conference, the real work begins. We help with a few different parts of talk preparation. Sometimes we help with things like outlining or slides.

We also give people a chance to practice their talk if they want to. We get on a google hangout, and they give their talk to the group. This is a great way to get some practice with a friendly audience and get some helpful feedback to improve the talk.

Our group also provides general support for one another. Things like providing support when someone has a talk rejected. Or sending some friendly tweets the day before someone gives a talk to cheer them on. Or saying "congratulations" after they've given a successful talk. These things may seem small, but they really help people.

Let's move on to individuals. How can you help yourself get started if you're interested in speaking?

I recommend starting small, especially if you're afraid of public speaking. This ties into the expectations management thing. If you aim too high too fast, you're going to set yourself up for failure. Find opportunities that allow you to slowly work on public speaking and make progress.

Lightning talks are a great place to start with public speaking.

Lightning talks are short talks that are usually about five minutes long. Sometimes they're a little shorter or a little longer. Lightning talks often happen at conferences, user groups, and other events. They're often very easy to sign up for. Sometimes you literally just have to show up.

Lightning talks are great because they're so short. It doesn't take that long to prepare a five minute talk. If you're afraid of public speaking, you only have to talk for five minutes. It's not that long.

Lightning talks are also great because they're very low risk. Even if your talk isn't that great, most people won't remember. It was only five minutes long, and the next person is already speaking. On the positive side, a great lightning talk can be really impactful. I still occasionally get feedback about a lightning talk I gave over a year ago. People still talk about Gary Bernhardt's Wat talk even though it's only five minutes long. A well-received lightning talk can be a sign that you're ready to move on to doing a longer talk.

To summarize, lightning talks are an awesome starting place because they're low risk and brief.

Speaking at work can be another good way to practice. You may be obligated to do it any way, so you might as well get the most out of it.

User groups are another good starting place. They're often looking for speakers, and it's a much smaller audience than a conference.

I did some of my early lightning talks at Pittsburgh Ruby, the local ruby user group.

Toastmasters Internationa. Over 14,350 clubs in 122 countries.

Another great place to start is Toastmasters International. This is an organization dedicated to helping people work on public speaking. It's not about tech, but for many new speakers the issue is the public speaking part, not the technology. These groups are a friendly, nonjudgmental place with great tools to help you practice your public speaking.

Toastmasters has over 14,000 clubs in over 100 countries, so there's a pretty good chance that one exists where you live.

Now that I've convinced you to speak, I want to share some tips and tricks for the new speakers to help you level up your first talk. Surprisingly, I often see some experienced speakers miss some of these, so they can really help you make a first talk look great.

I am going to start with some "don'ts" because what not to do can be just as important as what you should do.

This one may seem obvious, but I still see this mistake fairly often. DON'T ALIENATE YOUR AUDIENCE! It doesn't matter how awesome the rest of your talk is, if you alienate the audience, they're gone. They'll take out their phones and read email or twitter.

I asked a bunch of people what often alienates them in talks, and this is the one that came up the most. "So easy your mom can do it." This alienates people. It's cliché, and it doesn't even make sense. Some people's moms are computer scientists and know more than you about technology.

So easy your mom can do it with a strikethrough.

Just don't say this. It adds no value, and it alienates a lot of people.

Another thing to keep in mind for this is that a conference is not open mic night at the local comedy club. This doesn't mean you can't tell jokes, but remember your audience. If it wouldn't be appropriate at work, you probably shouldn't say it at a conference.

I sometimes see this with new speakers who are nervous. They're so concerned about entertaining the crowd that they try to use cheap jokes. This often backfires. Don't force yourself to be funny, if that's not your strong suit. If you do want to tell jokes, I recommend testing them ahead of time.

The other thing to keep in mind with this one is the worst case scenario. If you tell a really bad joke, it may violate the code of conduct. This will reflect poorly on you and will create a mess that the organizers have to deal with. You really want to avoid that.

Don't live code. Live coding is an advanced skill. As a new speaker, you're not at an advanced level. There are about a thousand ways live coding can go wrong, and if you're nervous, that's even more likely to happen.

I have only seen live coding go well a few times, and it was always with an experienced speaker who prepared a lot ahead of time. On the other side, I have seen live coding go horribly wrong. It was awkward and stressful for the speaker, and a waste of time for the audience. I strongly discourage this for a new speaker.

The one exception I've seen that works well is recording your live coding ahead of time. You then play the video and pretend to live code and talk over it. This removes most of the potential points of failure and takes a lot of stress off of the speaker.

Don't read us your blog post. What I mean by this is do not stand in front of the audience and read them your slides or your speaker notes. Blog posts and presentations are very different mediums, and they usually don't translate well to one another. If people are just going to read a blog post, they'd probably rather do that. A presentation needs to be something different.

This brings me to slides. People should not be able to reproduce your talk with your slides. If they can, you're very likely just reading them your blog post. If that's the case, why are they wasting 30-40 minutes to listen to you speak?

Instead, you should think of your slides as a prop or backdrop that supports your talk. They should be a helpful supporting element, not a distraction or the main event.

To accomplish this, you should keep your slides simple. Really busy slides tend to distract the audience and take their attention away from the talk.

Keep in mind that your slides are not an eye chart.

Don't use tiny text.

Use big text.

Use huge text.

Use ridiculous massive text, so big that even the people in the very back can read it.

This is especially important with code on slides, but that is often where people forget this.

Large code sample of merge sort in ruby.

People will try to put their entire program on one slide. The text ends up so tiny that nobody can read it, so what's the point of it even being up there? It becomes a distraction.

Code sample of merge sort in ruby broken down to the merge_sort method with syntax highlighting.

Instead, you should focus on the method or block of code you are currently talking about. This allows the audience to focus on that and gives you the space for larger text.

Another thing to note is syntax highlighting. This is great when you are actually coding, but can be distracting in a presentation. The audience isn't sure where to focus because there are colors everywhere.

Code sample of merge sort in ruby broken down to the merge_sort method with black text and the method name highlighted.

Instead, I recommend setting most of the text to a neutral color like black and using color and bolding to help them focus on the part of the code you are talking about.

Code sample of merge sort in ruby broken down to the merge_sort method with comments.

You can also use comments as a sort of guide to help the audience follow along with your code.

Walking through sample of merge sort in ruby broken down to the merge_sort method with comments and code.

You can then use the comments and the colors to walk people through the code as you talk about it. This makes it much easier for them to follow along.

Walking through sample of merge sort in ruby broken down to the merge_sort method with comments and code.

Walking through sample of merge sort in ruby broken down to the merge_sort method with comments and code.

Walking through sample of merge sort in ruby broken down to the merge_sort method with comments and code.

Walking through sample of merge sort in ruby broken down to the merge method with code.

When you're ready to move to the next block or method, you put that on the screen and, again, use coloring to help them follow along.

Walking through sample of merge sort in ruby broken down to the merge method with code.

Walking through sample of merge sort in ruby broken down to the merge method with code.

Walking through sample of merge sort in ruby broken down to the merge method with code.

Walking through sample of merge sort in ruby broken down to the merge method with code.

Walking through sample of merge sort in ruby broken down to the merge method with code.

Don't put important content at the bottom.

Don't put important content at the bottom of your slides. Depending on the setup of the venue, which you probably won't know about ahead of time, people's heads may be in the way.

You should be mindful of the contrast between the text and background on your slides. High contrast is more likely to have good results.

High contrast with grey text on a black background

It is unlikely your slides will look the same on the projector as they do on your computer screen. Crappy projectors often wash things out and can make it hard to read. High contrast slides still look ok even on crappy projectors.

High contrast with red text on a green background

High contrast is also important from an accessibility standpoint. People who are color blind often cannot discern the difference between two colors when they have a similar contrast. For example, red-green color blindness is fairly common. People with color blindness probably can't read this slide. (Also, it's really ugly and looks a bit like Christmas.)

Project results with a pie chart with green representing good and red representing bad.

Color blindness can be especially important in charts and other visual guides on slides. We often use green to mean "good" and red to mean "bad." Without good labeling, this can be a problem for people with color blindness.

Project results with a pie chart with grey representing good and a slightly darker grey representing bad.

They may end up seeing something equivalent to this. Which part is good and which part is bad? Who knows?!

Supporting imagery can be really useful in your slides. It helps people connect with the point you're making and can help them remember it later.

Now, you may be thinking to yourself, "but, Julie, I'm not a designer. Where am I going to get this imagery?" You're in luck. I have some suggestions for you.

The Noun Project: Creating, Sharing and Celebrating the World's Visual Language

One of my favorites is The Noun Project. Their tagline is "creating, sharing and celebrating they world's visual language."

Screenshot of search for 'presentation' on The Noun Project

You go there and search for a noun and get awesome images that help visualize that noun. They're vector images, so you can easily resize and recolor them to match your slides. They have images for almost everything.

Cat Cuddling example from The Noun Project

They've got cat cuddling.

They've got sharknado.

The majority of the images are licensed as creative commons with attribution, so you can use them for free as long as you provide attribution to the creator. I usually include an attribution slide at the end of my talk.

Another good place to find Creative Commons imagery is flickr.

Screenshot of creative commons search for speaking on flickr

You can do a creative commons search on flickr to find photography that fits your presentation.

Pop culture can also be a good way to add some imagery and get a good natured laugh...

slide with a large number of silly memes on it including: tribbles, doge, BMO dancing, nyan cat, grumpy cat, all the things, xkcd, and Oprah releasing bees.

...but be careful not to overdo it. Otherwise it gets to be a bit too much and suddenly it's BEES, BEES, EVERYWHERE BEES!

Captain Jean-Luc Picard from Star Trek TNG facepalming

That gets to be too much, especially in a long talk. Sometimes these talks are 80% silly memes and 20% content. That's a really bad signal to noise ratio.

The most important advice I can give you about preparing for a talk is to practice. I know this isn't exciting. Sadly, there is no silver bullet. Most people don't naturally speak well. It takes practice, and practice does pay off, just like with many other skills.

I refer to my method for practicing as "the Reservoir Dogs method." In the film Reservoir Dogs, one of the characters has to learn an amusing anecdote and tell it naturally like it is a real story he experienced. His life depends on doing this.

Memorize what's important. The rest you make your own.

The character that is helping him prepare says, "Memorize what's important. The rest you make your own."

Only way to do that keep saying' it and sayin' it and sayin' it

And the "only way to do that is to keep sayin' it and sayin' it and sayin' it."

This is how I prepare for a talk. I memorize what's important, represented in text and imagery on my slides. I practice over and over again filling in the rest until I know the story really well. As a result, the talk is a little different every time I give it, but retains the important core content. This tends to lead to a more natural talk than memorizing something word for word. This method has been really helpful for me with my anxiety about public speaking.

In addition to practicing your talk on your own, you should playtest your talk. What I mean by this is practice it in front of an audience, so you can get feedback. Playtesting gives you a chance to see what works and what doesn't. You see when people laugh at your jokes or when they fall flat. You can talk to the audience afterwards to get feedback. Find out where they were confused and where they wish you'd gone into more detail. This feedback is really useful.

Playtest your talk with an example calendar of when this talk was playtested.

I recommend scheduling your playtest at least a week in advance. Here is an example of the dates when I playtested this talk. This gives you an early deadline to force yourself to finish the talk ahead of time. This also means you have a whole week to adjust your talk based on the feedback you get from your audience. This can help take a talk from average to awesome.

Plan for technical difficulties with a picture of a broken computer.

Last, but not least, make sure you plan for technical difficulties. They will happen. Computers fail. Wifi doesn't work. THE WIFI NEVER WORKS (except for apparently at the conference where I gave this talk). Planning for technical difficulties ahead of time is often the difference between handling them gracefully and panicking.

Please consider becoming a speaker. It has a lot of benefits for you, and the community can benefit from learning from you.

Please support new speakers. We need new voices to add value to our communities, but they need help to get there.

Thank you!

Additional Resources

Posts

I Support Speakers and So Can You
Presentation Skills Considered Harmful by Kathy Sierra
We Are All Awesome
So Why Should I Speak Publicly? by Jessica Ivins
How To Give the Killer Tech Talk — A Pamphlet by Jan Lehnardt
Why Do I Speak at Conferences? by Pamela Fox

Talks About Talking

Conference Submissions and Presentations by Matthew McCullough - video - slides

Presentation Tools

Many beginners may be unsure what to use to create a presentation. Below are some tools I’ve used before. I don’t think there’s a “right” tool. Pick the one that is easy for you to use and meets your needs.

Keynote (Mac only)
PowerPoint (Windows and OSX)
Google Drive Presentation (browser)
Reveal.js (browser)

About PyCon

Other Conferences

PyCon isn’t the only conference doing outreach to support new speakers. Here are some others I know about:

Imagery Resources

Places to find imagery for your talks:

Talks I Mentioned

Behind the Curtain - Nell Shamrell at Madison Ruby 2012 - video
Analyzing Rap Lyrics with Python - Julie Lavoie at PyCon 2014 - video

My Speaking Timeline

Throughout the talk, I mention that people should start small and can progress over time. I thought it might be interesting to share a timeline of my progression as a speaker over time, but it didn’t fit in the time for the talk. I’m leaving it here in case it interests you.

You can find links to slides and videos from these talks on my speaking page.

April 2012 - Lightning talk at work retreat (first talk)
July 2012 - Lightning talk at PghRb
August 2012 - Lightning talk at Steel City Ruby
January 2013 - Speaking support group created
February 2013 - Lightning talk at PghRb
June 2013 - Conference speaker at Pittsburgh TechFest (first conference talk)
August 2013 - Conference speaker (alternate) at Steel City Ruby
September 2013 - Conference speaker at Nickel City Ruby
April 2014 - Conference speaker at PyCon
June 2014 - Keynote speaker at OSBridge (first keynote)

Attribution

Presentation designed by XOXO from the Noun Project - http://thenounproject.com/term/presentation/23951/
Happy designed by Julien Deveaux from the Noun Project - http://thenounproject.com/term/happy/43940/
Neutral designed by Julien Deveaux from the Noun Project - http://thenounproject.com/term/neutral/43949/
Calendar designed by Daniel Llamas Soto from the Noun Project - http://thenounproject.com/term/calendar/38232/
Happy designed by Julien Deveaux from the Noun Project - http://thenounproject.com/term/happy/43961/
Man designed by Simon Child from the Noun Project - http://thenounproject.com/term/man/22453/
Man designed by Simon Child from the Noun Project - http://thenounproject.com/term/man/22486/
Man designed by Simon Child from the Noun Project - http://thenounproject.com/term/man/22466/
Man designed by Joshua McMahan from the Noun Project - http://thenounproject.com/term/man/13856/
Man designed by Simon Child from the Noun Project - http://thenounproject.com/term/man/22473/
Man designed by Simon Child from the Noun Project - http://thenounproject.com/term/man/22956/
Neutral designed by Julien Deveaux from the Noun Project - http://thenounproject.com/term/neutral/43968/
Sick designed by Julien Deveaux from the Noun Project - http://thenounproject.com/term/sick/43969/
Angry designed by Julien Deveaux from the Noun Project - http://thenounproject.com/term/angry/43964/
Surprised designed by Julien Deveaux from the Noun Project - http://thenounproject.com/term/surprised/43962/
Surprised designed by Julien Deveaux from the Noun Project - http://thenounproject.com/term/surprised/43962/
Dialog designed by Reed Enger from the Noun Project - http://thenounproject.com/term/dialog/6070/
Thought designed by Adam Zubin from the Noun Project - http://thenounproject.com/term/thought/35709/
Chicken and Egg from Wikimedia Commons - http://commons.wikimedia.org/wiki/File:%E0%B9%84%E0%B8%82%E0%B9%88%E0%B9%84%E0%B8%81%E0%B9%88.jpg
Baseball Field designed by Erik Wagner from the Noun Project - http://thenounproject.com/term/baseball-field/25079/
Chat designed by Mister Pixel from the Noun Project - http://thenounproject.com/term/chat/36835/
Brainstorm designed by Bastien Ho from the Noun Project - http://thenounproject.com/term/brainstorm/20036/
Lightning Bolt designed by daisy binks from the Noun Project - http://thenounproject.com/term/lightning-bolt/9601/
Microphone designed by Eric Bird from the Noun Project - http://thenounproject.com/term/microphone/28757/