Speaker Support of Awesomeness
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.
Table of Contents
- New speakers or people who I can convince to become new speakers.
- Consumers of talks
- 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.
- 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.
Because we want awesome talks.
- Expand your knowledge.
- Challenge your preconceptions.
- Ultimately leave you feeling inspired and more excited than you were before.
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.
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.
I put together a dramatization to help people understand this one.
Any resemblance to real events or persons, living or dead, is purely coincidental.
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.
...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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
This is especially important with code on slides, but that is often where people forget this.
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.
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.
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.
You can also use comments as a sort of guide to help the audience follow along with your 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.
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.
You should be mindful of the contrast between the text and background on your slides. High contrast is more likely to have good results.
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 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.)
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.
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.
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.
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.
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...
...but be careful not to overdo it. Otherwise it gets to be a bit too much and suddenly it's BEES, BEES, EVERYWHERE BEES!
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.
The character that is helping him prepare says, "Memorize what's important. The rest you make your own."
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.
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.
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.
- 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
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)
PyCon isn’t the only conference doing outreach to support new speakers. Here are some others I know about:
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)
- 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/