Want to speak at tech conferences? Here’s everything you need to know to get on stage

If you’ve ever looked at a conference or meetup speaker lineup and thought, “Hey, I could do that!” and then thought, “but wait…how do I get started?” then this is for you.

Giving talks at tech events is a goal for many technologists, for good reason: it’s a great way to meet people who share similar interests, raise your profile in a specific community, and sharpen your storytelling and technical skills.

My colleagues and I put together this introduction to speaking for our internal folks at CircleCI, and realized that many of the tips and guidelines would likely be useful for a broader audience. With that, let’s hop into our guide to speaking.

Step 1: Start with a goal

You should have a clear idea of the goals you are trying to achieve by speaking. Are they:

• Sharing your passion for a specific technology
• Helping others learn from your mistakes
• Building your personal brand
• Recruiting folks to come and work on your team
• Getting sales leads
• Getting company brand exposure at a big industry event
• Driving awareness of your solution to your target audience

Talks take a lot of time and energy. Practiced speakers often estimate 40 hours of prep for every hour of speaking time. Make sure you know what you hope to get out of it.

Step 2: Pick an event to submit to

Once you have a goal in mind, it’s time to find venues and events that might be interested in having you. While marquee tech events like re:Invent and the TNW Conference might be the ultimate goal, it’s a good idea to start with local meetups and smaller conferences at first. 

I’ve found Papercall.io and Meetup.com are both great resources for finding smaller events that might be interested in what you have to say.

Step 3: Write a proposal

After you’ve identified an event you want to speak at, it’s time to hone your talk idea into a proposal. Here are some tips for writing good proposals:

• Look at what was accepted last year. The talks from a conferences’s previous years are a cheat-sheet to what the organizers are interested in. Don’t attempt to repeat topics or content, but do look at the level of technical expertise and storytelling they expect from speakers.
• Read the submission form. If there are multiple pages, click through and pull out all the questions you will have to answer into a doc. There’s nothing worse than going to submit right before a deadline and realizing there are a bunch of extra, mandatory questions you haven’t planned for.
• Give the organizers what they want! If they ask for security stories, submit security stories. They are giving you a topic list because they likely have tracks or content types they want to fill. Don’t expect them to fit a pineapple talk into a vegetable talk display.
• SUBMIT EARLY. Submit at least tw0 weeks early. Why? Everyone applies last minute. Applying early means someone will read your proposal and think about it and then use yours as one they compare other people to. You are more likely to get into a conference when you apply early. For what it’s worth, this is also true for folks who apply early decision to college.
• Submit two talks, max. Submitting more is kind of frustrating for the reviewers, and shows that you have difficulty editing your ideas.
• Do you need a video? This might be hard to find! If you don’t have a recording of talk you’ve given, record an internal tech talk (with permission) or a tutorial video. You can also record yourself rehearsing a talk. Organizers are usually looking for some reference as to a submitter’s speaking style and in most cases these rehearsal videos are adequate.
• WRITE A GOOD HEADLINE. This is 75 percent of the battle, and shouldn’t be an afterthought. I’m not kidding when I tell you to spend most of your time on a headline. A good headline shows you have a concise idea. A headline is what will get people to your talk.

Note that steps 1-3 here (identifying your goal, picking an event, writing a proposal) are in somewhat arbitrary order. You might have a great success story you want to share, so you look for relevant events that might be interested in that story. Or your boss says, “I need you to submit for GitHub Universe” and you work backwards from that goal.

Step 4a: You got turned down. Now what?

If your proposal was denied, take heart: at big events, this is the most likely outcome. For example, KubeCon EU this year received 7x the number of talks they had room for. The competition is fierce!

If you didn’t get any feedback, consider reaching out to the organizers to ask for feedback. Be polite! But feedback from conference organizers can be gold.

Here’s an example of what to write:

Hi [Speaking organizer’s name],

Reaching out regarding my speaking submission [TITLE] for [CONFERENCE]. I understand there were many exceptional talks submitted this year, and I’m excited to see the lineup/excited about the lineup that was released, particularly [XYZ TALK ON THE SCHEDULE]. I’m looking forward to attending your event! 

If you have any feedback (however brief) that you might be able to share about why my talk was not accepted, I would find it really useful. I’m working on writing better submissions and finding more opportunities to present, and any insight you can share would greatly help me with these goals. Please don’t hesitate to reach out if there’s anything I can do in support of this event.

Thanks for your feedback!

If they don’t write back, don’t follow up — let it go. When the talk lineup is released, compare your submission to what was accepted and try to come up with a few reasons why you think you weren’t successful.

Unless you’re Elon Musk, you probably have a 25 percent success rate, if that. Don’t feel bad! If you are always accepted, you’re not applying to big enough venues, or you are Kelsey Hightower.

Step 4b: You’ve been accepted! Now what?

Congratulations, your talk was accepted!

Cue the anxiety: now you need a presentation. One way to do this is to write an outline of the talk contents, and then fill in the outline by writing the voiceover track. Writing a talk out with a script helps me to evaluate the flow, and make sure all the key points are being hit. It’s also helpful for timing the talk.

Here’s one example of how to do this. Write your outline, and then set up a document where you write your talk track and what you think the visuals might be.

For example:

• Slide 11: Headline: 3 things to remember about bunnies
• Possible Visual: 3 bunnies with text over their heads
• Voiceover: If you only take away 3 things from this talk, here’s what I want you to remember: 1. Bunnies are cute. 2. Bunnies are fluffy. 3. Bunnies love carrots.

Everyone has a different way that they like to outline, but try not to get caught up in slide design or formatting until you have your narrative down. A good narrative can stand on its own with really minimal slide design. Try not to think about the visuals too closely until you have the words outlined so you can check the flow before you get too deep in a slide rabbit hole.

How should you structure your talk?

While there are infinite ways to structure a talk, there are some classic formats that might help you think about how you want to tell your story.

1. Persuasive Arguments

The first is a persuasive format that you can use for presentations, writing, or really, anytime you need to convince someone of something. It’s really simple, and it’s a nice framework for organizing your thoughts:

• What’s the problem?
• Why is it a problem?
• What’s the solution?
• Why is your solution the best possible solution?

Here’s an example of this format in practice:

• What’s the problem?
  • Our internet connection is too slow.
• Why is it a problem?
  • Slow internet takes developers out of flow, so they are less productive than they could be. Waiting for files to download or a page to load is pure downtime — there’s nothing else an engineer can meaningfully be doing during that time. Since employee cost is our highest cost, anything we can do to help our teams be more productive is worth it. We should invest in the best tools and equipment if we believe they will make a difference. Finally, slow internet frustrates our team. They want to be building, not waiting.
• What’s the solution?
  • There are a few things we could do. We could do nothing and accept this as the cost of doing business. We could add a new fiber connection to our office. Or we could use drones to hover our routers near the ceiling, thus boosting the signal throughout the office.
• Why is your solution the best possible solution?
  • Doing nothing will cause our competitors to eclipse us and our team to quit in frustration. Fiber would speed up our connections, but it’s not available in our building and we can’t control when it will be. Buying drones to fly routers in our office will boost our signal using existing equipment, at low cost, while also entertaining our colleagues and signaling that we are an innovative, exciting workplace. We may have some issues with office safety and damaged equipment over time, but the increased productivity gains should be worth the occasional office drone collision.

One thing to watch out for with a persuasive argument format is making sure it doesn’t unintentionally turn into a demo or sales pitch.

If you’re intending to include some live demos in your talk you should allude to this in your submission abstract. Here are some examples of verbiage that indicate intentions for live demos in talk submissions:

• “In this talk Emma will demonstrate how developers can easily configure and use Docker containers in their CI/CD pipeline.”
• At the end of this presentation attendees should have a firm understanding of how to test node.js applications from within their CI/CD pipelines using cypress.io within the CircleCI platform.

A product demo or a sales pitch is the fastest way to never get invited back to speak at a conference again.

2. What I learned

“What I Learned” is the most common talk type, and can be applied to anything from a technical deep dive to a high-level strategy session. It’s great for storytelling and builds empathy through open conversation and honesty. You’ll often see this type of talk titled something like, “5 Things You Should Do..” or “Why We Run…” or “How to Know When…”

Here’s a typical “What I learned” outline:

• Introduction of yourself and your company
• Set up the situation: where were you as a team? What was happening?
• What happened that made you realize you needed a change?
• What did you try?
• What worked?
• What do you do now?
• If you implement this, you should do these things and not those things.

Caveats about this format:

• You don’t want to be so general or obvious here that the audience thinks, DUH, during your talk
• You don’t want to be so specific that the audience can’t understand how anything you are talking about could apply to them

This may sound obvious, but it’s a really tricky balance to hit. Sharing the right amount of context, adding humor and levity, and being transparent about your thought process and decision making helps.

This format is also great with some different flavors:

• “Conventional Wisdom Says X, But Here’s Why That Doesn’t Work For Us” aka “Here’s Why We Made this Wild Decision and Why it May or May Not Work for You!”
• “7 Times We Were Wrong and What We Learned”
• “Everything I Thought I Knew about X was a Lie!”

3. Data deep dives

Ah, data deep dives. The holy grail of conference talkism! You have data to support your decision making and conclusions? You win. This may also be the hardest format to put together. Some common formats for presentations like this are:

• “1M Build Output Errors Say These Are the 3 Most Important Things”
• “We Analyzed 10,000 Engineering Teams and Here’s What the Best Ones Do”
• “These 3 Things Will Increase Velocity 20%”

It’s great if you can draw some unlikely conclusions, or bring up non-obvious points. If your points are kind of obvious, it’s also fine, but emphasize that. For example:

We all know that eating breakfast is important. But the thing that you might not realize, and that the data shows us, is just how important it is. Eating breakfast will extend your life by 20 years.* It’s such an easy change, that you know is important, that has a really huge impact. 

*No breakfast was harmed in the making of this false claim.

Caveats:

• Make sure you understand the methods used to collect the information and definitions of all terms
• Understand the limitations of the data and what it doesn’t cover
• Think through your audience and their level of fluency in both data AND the subject. Do you need academic level of data with statistical significance? OR do you need some loose correlation and a little hand waving? You should be upfront about how solid your numbers are, but depending on the audience, you’ll have a different standard of proof.

General best practices

The research on learning and knowledge retention is really clear: there are some easy things you can do to help your audience pay attention, and retain information from your talk.

Introduce yourself and share a bit about why you have this information or why you are an authority. This will build some empathy and set up credibility with the audience.

“I’ve been a CTO for 20 years and have led teams of 3 – 300.” or “I just started learning this last year, and there are some strategies I’ve picked up that will save other beginners a lot of time.” or “I’ve been on teams that failed and teams that succeeded, and I want to talk about how my personal experience backs up the research that says that psychological safety is the most important thing on a team. I’m going to share the data and some personal anecdotes to help you bring it back to your team.”

Use signposting: Share an agenda or talk outline, use visual cues or design elements that help the audience know how much you’ve covered and how much is left. This helps people keep their focus on your content, and reduces listener stress.

Share your learning objectives or talk objectives: What should your audience be listening for, and what will you be leaving them with? Give people cues for what to listen for and what they will walk away from your talk knowing. “At the end of this talk, you’ll have 3 strategies for lowering your energy bill in 30 days.” “I’m going to talk to you for 30 minutes about how to move to microservices, and share 7 mistakes we made that you can avoid.”

End your talk by saying thank you, and then moving to Q+A. Don’t hop straight into questions. Why? If you go straight to Q+A, and there aren’t any Qs, it’s awkward. Give people an opportunity to clap or however else presentations are being concluded, then ask for questions.

PRACTICE. You need to practice at least three times. Three times is almost definitely not enough, but it’s the bare minimum. How should you practice?

• Start by practicing by yourself. Record yourself giving the talk and watch it. This can be painful, but it’s exceedingly helpful.
• Ask a friendly audience to listen. Set up a lunch and learn with your coworkers, or ask folks you know to join a remote call practice session. This is a great way to get your pre-talk jitters out.
• Appoint 1-2 people at your practice talks to give you detailed, constructive feedback. Ask for incredibly detailed and specific feedback, to the level of: “Slide 1: you didn’t spend enough time introducing yourself. I got your title, but not why you care about this topic. The transition between slide 2 + 3 needs a little work. Instead of saying, “on to the next point,’’ try, “let’s focus on how you can use this technique to get that result.”

Step 5: Deliver your talk!

Your big day is here! You’ve got this. Remember to speak slowly, but most importantly, remember why you wanted to do this in the first place. What was your goal? Try to bring yourself back to the why behind your talk.

Passion and emotion are at the heart of every good story, no matter the content. Your delivery and personal connection to your material will help drive your message with the audience home, even and especially if you get a bit nervous while delivering your talk.

If you mess up, or miss some lines, or muddle an explanation, it’s ok. Many folks give their talks publicly 10+ times before feeling like they have truly nailed the content.

Step 6: Prosper! And then start over again.

Congratulations, you delivered your talk! Take a moment to bask in the glow of a job well done. Then ask yourself:

• What could I have done better?
• How can I make this more clear for next time?
• Who do I need to thank (organizers, practice buddies, colleagues, attendees) for their time, support, and attention?
• Are there other audiences that might be interested in hearing this, or a flavor of this talk?
• Can I use this talk content for other formats, like a blog post?
• Where should I submit next?

Congratulations on making it to the end of this epic step-by-step guide to speaking!