If you’ve ever wanted to try speaking at a conference, I’ve got good news for you: not only is it less scary than you might think, but it’s also a great way to learn more about the topic you teach while also helping contribute to our community.
I believe it’s important for our community to find and encourage new voices to come forward and talk about their experiences and ideas, so I’ve put together this article as a consolidated resource to new speakers get started.
In this article you’ll find:
At the same time, I’m also just one person with one very specific background, so I also want to introduce you to a range of other views from folks who are acclaimed speakers in our community.
These people are just as keen to encourage new speakers to come forward, and I’m really grateful they took the time to contribute to this article – thank you to Craig Clayton, Kristina Fox, Ash Furrow, Cate Huston, Ben Scheirman, Ellen Shapiro, Daniel Steinberg, and John Sundell for contributing their time and suggestions!
Please keep in mind that there’s no one ideal route to delivering a great presentation – there are a range of suggestions here, and you need to do works best for you.
If you want to jump ahead to a specific point in the article, here’s your chance:
It won’t surprise anyone that the first step in delivering a talk at an iOS conference is of course finding a conference that suits you. I’ve written previously about some of the great Swift and iOS conferences, but there are dedicated GitHub repositories listing upcoming conferences and when you can submit papers.
If you want to start even smaller – and why not? – consider running a lunchtime event at your company.
If you’re keen to push ahead for one of the well-known events like NSSpain or AltConf, great – go for it! But if you’d rather start smaller, try finding a CocoaHeads group near you. These vary in size from 10 people to a couple of hundred, but they meet regularly, are always looking for new speakers, and are a great way to get feedback on your presentation before you try for a larger event.
If you want to start even smaller – and why not? – consider running a lunchtime event at your company. These are sometimes called “Lunch and Learn” events because your company might sponsor some food, but the goal is simple: have someone (you!) stand up a deliver a short talk about something new they learned recently. You might still get nervous at first, but at least you know your audience well because it’s your colleagues.
Please do everyone a favor and check that the conference has a meaningful code of conduct and a commitment to diversity.
Once you find the right event for you, here are some tips to help you make the most of it:
Many conferences run an open Call For Papers (CFP), which encourages anyone from around the world to submit suggestions for presentations they’d like to deliver. This process requires you to sum up
You probably don’t have your slides ready at this point, so writing a good CFP submission can be a surprisingly tricky affair. There are three parts that folks usually find hard:
Let’s start with the easiest of the three: writing the main text describing your presentation. This is best done in steps, starting with one or two sentences that engage the reader quickly. For example:
Ideally you should be able to end with some clear points that attendees will be able to take away and apply to their own projects or careers.
You can then follow that up with more details about what specifically is covered: are you using specific features of Swift? Are there exciting features of UIKit you’ll be showing off? Do you plan to do live coding?
Ideally you should be able to end with some clear points that attendees will be able to take away and apply to their own projects or careers. For example:
A word of warning in advance: even though it’s great to present new talks all the time, be prepared to repeat talks that you’ve delivered previously. Often someone will hear you deliver a talk at one conference and specifically request it, or you submit three ideas and they choose one you delivered before. This is all OK – they know their attendees, so ultimately you need to trust they are selecting the best mix of talks.
If there’s one tip I can give you here that matters above all else, it’s this: focus your talk on your audience rather than you. Above everyone else, the single person that I admire the admire and have learned from the most is Kathy Sierra, who teaches an important lesson about making great products:
In meetings, phrase everything in terms of the user's personal experience rather than the product. Keep asking, no matter what, "So, how does this help the user kick ass?" and "How does this help the user do what he really wants to do?”
This is equally true for presentations: people aren’t attending your talk because you think you’re awesome, they are attending because you want to help make them more awesome.
Even though I learned this lesson over a decade ago, I still occasionally forget. For example, the original title for my dotSwift talk this year was “I can teach you programming in 15 minutes.” Fortunately, Daniel Steinberg called me out because I focusing on myself rather than the audience.
Once you’ve written the detailed proposal, it’s time for you to distill that down to some sort of title that summarizes your talk in a way that’s likely to make folks want to attend. This isn’t easy, because ideally you want something catchy or unique – or at least strongly suggesting that your talk on Auto Layout stands out somehow from all the other talks on Auto Layout that have come before.
For example, at iOSCon this year I delivered a talk called Nuke It From Orbit: How to Deal With Massive View Controllers Once and For All, and at Next Door I’m delivering a talk called What Star Wars Can Teach Us About Swift.
Here are some other talk titles I’ve seen recently that I think stand out:
All these talks have me asking questions: what haven’t I been told about debugging? Why were applicatives forgotten and how can I use them? What are the nice things that I deserve?
Now for the hardest part of any proposal: you’ll be asked to describe yourself with a speaker biography. This might come easily to some, but most of us find it hard to write these because you need to include enough detail to make it clear you have suitable technical experience while also avoiding bragging.
Here are some bios from well-known speakers to give you some ideas:
There’s no set format for these: you can list the places you’ve worked, you can talk about projects you’ve delivered, and you can even try to be funny. My own speaker bio tries to go down the “try to be funny” approach, but I’ll let you decide for yourself how well it worked:
Paul is the author of Hacking with Swift, Pro Swift, Swift Design Patterns, Server-Side Swift, Hacking with macOS, Hacking with watchOS, Hacking with tvOS, Swift Coding Challenges, and more. Suffice it to say, he quite likes Swift. And coffee. (But mostly Swift.) (And coffee.)
If you’re having a hard time coming up with good presentation ideas, relax – it’s perfectly normal.
To help you get started, I asked other speakers this question: “what makes a great presentation?” Here’s what they had to say…
Bringing a unique style is not easy, but the more you practice and work on it you will start to find what makes you comfortable.
Craig Clayton: Passion and uniqueness. If you have a passion for a topic, then it will show what you are saying. I also think you should bring a unique style to your presentation. Bringing a unique style is not easy, but the more you practice and work on it you will start to find what makes you comfortable.
Kristina Fox: At the end of the day, the audience wants to walk away with something actionable from your talk. That being said, there are two different types of talks that always get me excited:
Talks that really get me thinking about processes and best practices. I love presentations that get a discussion going either at the conference or back at home when I tell my teammates about it. Not only does it help you build a network at the conference, but a diversity of thought helps all teams get better.
A great conference presentation tells a story.
Ash Furrow: A great conference presentation tells a story. Stories stick with people, they're easy to remember, they inspire people to do something. It's not enough for a presentation to say "this is such-and-such programming technique and this is how to use it" because it needs a story to give it meaning.
Consider: "I had this problem. I tried an obvious answer but it didn't work because of this this interesting problem. I found such-and-such programming technique and it was really well-suited to my problem. As a practitioner, it helped me do/become/feel something new. This is how to use such-and-such programming technique."
A great conference presentation tells a story.
Cate Huston: I think a great talk is a talk that only that person can give - something created at the intersection of their passions and experience.
On a practical level, one of the hardest things to balance is the right amount of content for the audience - so that they can leave with a clear takeaway and some meaningful things to think about. It's really tempting to go too deep or too broad!
Distilling your message down to what people really need to hear is key.
Ben Scheirman: Talks that I enjoy are entertaining, informative, and leave the viewer with something to take away. I’m always impressed by live coding talks when done well. This is because you get to see exactly what is going on.
For technical presentations, sometimes the slides can be so abstract it doesn’t tell you: “so how do you actually do this?”. Some of my most well received talks were live coding talks. Of course there is the likely possibility that things won’t go to plan, so par for the course is having the ability recover well. (Always have a backup plan). If you get flustered when things go wrong it will detract from the message you’re trying to leave people with.
Ellen Shapiro: The best conference presentations are about something the presenter really cares about - either because it’s something they’ve experienced or because they’re deeply interested in what they’re talking about.
Daniel Steinberg: A great conference presentation has to change me in some way - big or small. It could be as simple as introducing me to a new idea and as large as making me change the way I spend my time.
I love a talk that tells me the “why” behind something. If it’s a technical talk that provides me with the right way of looking at a technology then I can go to the docs and figure out the “what” and “how”. The talk has shown me why I care and when I do and don’t want to use it.
It’s not enough that you “teach” something if I don’t learn it.
I think a great talk is one that only this particular speaker can give - because of their style, background, or something else that’s special about them. Even though the talk is their talk, it has to be about the audience as well. It’s not enough that you “teach” something if I don’t learn it. A great talk is a connection between the person delivering it and the people receiving it.
A great speaker understands what the journey is you want to take us on. To do this, they must understand where the audience is at the beginning and where we will be at the end. You won’t always be able to achieve it - but it’s good to know the story you’re going to tell us as well as the subtext.
John Sundell: I think a good presentation needs to be a nice mixture between information and entertainment. I don't mean that we all need to turn into stand-up comedians and make jokes all the time, but there needs to be a good pace and a certain level of dynamism in order to capture the audience's attention.
A presentation is very different from something like a blog post, in that everyone needs to follow along at the same pace (unless you're pausing a video recording of it). That means that it becomes super important to re-iterate and to present concepts in a way that's appealing and understandable to people of many different skill levels.
It’s a wonderful feeling getting an email from a conference saying they are accepting your proposal – you’re going to [London/New York/Tokyo], you’re going to get to speak on a topic that you love, and you’re going to get the chance to meet hundreds of like-minded developers who are just as excited as you.
I’m not going to pretend it feels great because it doesn’t, but getting turned down occasionally at least reminds me that I’m doing my best to submit new ideas to new places.
And if you get rejected, that’s OK too – you learned something along the way, and you’ll do better next time. Remember, they aren’t rejecting you, they are rejecting the talk submission: perhaps someone else submitted a similar proposal, perhaps they had a talk on that topic last year, or perhaps it didn’t fit well with the rest of the schedule they have planned.
For reference, I get rejected for conferences several times each year. I’m not going to pretend it feels great because it doesn’t, but getting turned down occasionally at least reminds me that I’m doing my best to submit new ideas to new places.
You might think the next step is to start preparing your slides, but before you do that there is some simple admin you need to take care of: send the organizers a high-res headshot of yourself so they can announce you, agree your travel arrangements, then get some details about their presentation set up.
The kinds of details that matter are:
Getting answers to these will help you feel more comfortable when you’re preparing and presenting. If you can use your own laptop, for example, you’ll know you can add speaker notes and see them clearly on screen in the way you’re used to.
Now for the one part of the process that will always take a long time: preparing your presentation and designing any slides you want to accompany you. This will take longer than you think.
If you intend to use slides – and nearly everyone does – there are some tips I highly recommend.
If you can send over your slides and they stand alone, you should have used a different storytelling format.
First, keep your words short and to the point. The exact number varies depending on who speak to, but most folks would say that having fewer than 15 is about right.
Second, make sure your slides convey something you aren’t saying. There’s a quote from Chris Phin that I think about a lot: “if you can send over your slides and they stand alone, you should have used a different storytelling format.”
Third, don’t allow yourself to wander off topic – you’ve been given the privilege of speaking to an audience who has paid a lot of money to hear you, so stay focused and stick to your topic. As Kathy Sierra once said, “put each slide on trial for its life. Ask it to defend itself. Show no mercy.”
Fourth, although it takes extra work, always strive for real examples in your presentation. Variables like “foo”, “bar”, and “baz” might be fine occasionally, but you can and should do better.
To help guide you in the early days, I asked other speakers this question: “what’s your personal process for building and delivering a presentation?” Here’s what they said…
Craig Clayton: I typically create an outline of everything I would like to cover. Then I break each outline into slides. Once I have my outline, the presentation starts to come together and builds itself.
I like to take a month or so to noodle on the idea and slowly build up an outline of the talk in a note-taking app
Kristina Fox: Depending on how much time I have, I like to take a month or so to noodle on the idea and slowly build up an outline of the talk in a note-taking app (Agenda is my favorite at the moment) before I turn it into slides. I work best when ideas come to me randomly rather than trying to force my brain to be creative with technical topics.
Life experiences help too - the last talk I gave was centered around teaching Xcode shortcuts through an escape room story. I came up with that one after learning that several iOS folks went to do an escape room during WWDC and that prompted me to think about fun puzzles for iOS developers, which led to my underlying storyline.
Slides come pretty quickly after building up my outline. I tend to use my slides as a visual aid and focus most of the content in what I say. The first time I rehearse my talk with my slides, I'll often pause and add speaker notes to each slide as I talk through it. Usually, it'll take between 3-5 full rehearsals to get it all down, along with countless mini-walkthroughs for some of the more tricky sections in the presentation.
Ash Furrow: I have an entire blog post describing my process in detail, but to summarize, there are two steps of me preparing a talk: first I plan it, then I prepare my slides.
When I plan a talk, I start by writing out a profile of my audience. Who are they? What are their backgrounds? What are their hopes/fears/biases/goals? What are they expecting from my talk? Next, I ask myself some questions. What do I want the audience to do as a result of seeing my presentation? What do they need to know to inspire those actions? How do I want them to feel? I then organize my talk around three to five central points. And I always start with a story.
Preparing slides is always the last step for me. It's a personal, creative process. I minimize the amount of text in my slides; the audience can either listen to me, or they can read my slides. But they can't do both at the same time, so which is more important?
Cate Huston: I build my talks on a grid (like a good UI!) - I start with a concept, and then I build out a structure (this is the most useful place for me to work with another person). From there I can start creating slides (which I outsource whenever possible) and flesh out the pieces. You can read more on my process here.
This year and last year I've turned my talks into multi-part series of blog posts, so that's been pretty interesting - and publishing one a week can be helpful to create mini-deadlines for myself. For examples see here and here.
Ben Scheirman: I like to start with a mind map of concepts. I use MindNode for this. It’s just stream of consciousness about a given thought or topic. After a while, I have some rough structure and organization for these thoughts, and I can start by creating an outline.
I want to have a story for the presentation, so this tends to follow a similar structure to writing a story: You have an intro, some supporting chapters, and a conclusion. Once this is fleshed out I’ll start writing some demos to support my topics, and I’ll create some slides.
I’d recommend using Deckset if you (like me) obsess about fonts, colors, and the overall feel of your slides. The important part is the content and flow. Polish comes later.
Ellen Shapiro: I make an outline and then turn it into slides using Deckset. I find using a Markdown-based editor really helpful because it dramatically shortens both this step and any rearranging.
I then write a full script in the presenter notes because between having ADD, a garbage memory, and a tendency to curse like a drunken sailor, I need it. If I don’t, I go wayyyyy off topic, sprinkle cuss words a little too liberally, and start getting things out of order because I’m so amped up with adrenaline.
I use a lot of slides in my talks. I average probably 6 - 8 a minute.
Daniel Steinberg: I used to write my talks right before I delivered them. Now I begin them weeks in advance. Something always emerges where I understand, “oh, this - this is what my talk is about.” Now with conference videos I tend to give talks only once or twice. I used to be in a traveling conference and would get to hone and grow a keynote over the year. It would often end up in quite a different place than where it started.
I use a lot of slides in my talks. I average probably 6 - 8 a minute. Many of these are builds so the audience doesn’t see them as unique slides - but these help to pace me. I like to be able to see my current slide and my next slide so that I know the point I’m going to make. My slides are there for pacing and punctuation. If there are code samples I like those to be on slides with the part I’m talking about highlighted to direct the audience’s attention.
I practice my talks and revise them up to the day that I’m giving them. I recently gave a talk where I thought I had more time on stage than I did. On my way up to give the talk I found out that I had two thirds of the time I thought I had. The mistake was mine - but my point is that with all of my rehearsing and understanding my talk I was able to edit and shorten it as I gave it and hit my mark.
I never talk about how much time I have or how much time is left. I never begin with a long introduction of myself.
I only turn towards my slides deliberately during the talk - other than that I look at the audience. If you turn your back on the audience - it changes their mood.
I try to use a sine wave pattern on different axes. The pace should rise and fall. My energy should rise and fall. My volume should rise and fall. The humor/poignancy should do the same. If you are setting up a laugh, you can do it with another laugh or with a serious moment. The resulting laughs are different - I try to consider the result I want.
There’s that moment on a roller coaster where you dip a bit and think you’ve made it through and then there’s the big drop. I think of that as I set people up and bring them along.
I’m not always successful - heck, I’m probably not often successful - but these are all things I aim for.
I need to start really early in order to be able to iterate and refine the talk over time, and to give me enough time to practice.
John Sundell: My process starts about 2-3 months before I'm going to give a talk, which is when I decide on the topic and make a rough outline of the contents of the talk. I need to start really early in order to be able to iterate and refine the talk over time, and to give me enough time to practice.
I use four apps to create my talks:
At this point you’ve found a great event, had your topic approved, and written some slides you’re happy with. Now it’s time for the big moment: for you to climb onto stage, have a microphone attached to you, and for you to deliver your presentation.
If its your first time, here are my best tips for delivering a great presentation:
Before getting on-stage, I have to do some things to calm myself of nerves. Yes, I get nervous! Who wouldn’t? I feel a lot of pressure to give the best delivery I can.
Finding the confidence to deliver a presentation is a highly personal thing, so I went back to my other speakers one last time and asked this question: “what advice would you give someone who wants to deliver their first talk?” Here’s what they said…
Craig Clayton: Always give a talk you are passionate about and makes you excited. Giving talks you are passionate about really helps you become eager to do the presentation. It is also much easier to come up with content for longer presentations. I find coming up with a presentation can sometimes be very difficult but once you have it make sure you own it.
How you present will dictate how people remember you. I try to pick them something I will use throughout the presentation. For example, in my trySwift 2017 presentation, I broke up my presentation with Betty White references.
Know that at the end of the day, the audience wants you to succeed.
Kristina Fox: BREATHE. Know that at the end of the day, the audience wants you to succeed. Just focus on the message that you're trying to send them home with and most things should fall into place.
That being said, a little practice definitely doesn't hurt. I recommend practicing by either recording a video of yourself and rewatching the playback, or by using an app like Ummo. Ummo records your talk and gives you both real-time feedback and a report card at the end with a transcript, counts for the number of filler words used, information about pacing, and so much more. As someone who has a hard time watching herself on video, this has been one of the most important tools in my arsenal.
Ash Furrow: Don't limit yourself to only presenting about topics you're already really familiar with. Teaching others is an opportunity to learn, too. Presenting a conference or meetup talk is a great excuse to dig a little deeper than you normally might, to really get a foundational understanding of a topic. So I'd encourage you to propose a talk even if your understanding of that topic is still evolving (because the reality is, it always is).
Cate Huston: Firstly: You have something to say! I think a lot of people are waiting to be chosen, but sometimes you need to put your hand up and say "pick me".
By the time I'm ready to get on stage, I've practiced enough hate to my talk a little. It's all part of the process!
Secondly: Get help. Speaking coaching made a huge difference for me personally and I really recommend it. However getting help from friends and colleagues is also great. Chiu-Ki was such a help to me when I started speaking, and I really could not have prepared my most recent talk without the help of my colleague Davide. Don't be afraid to let people in and show your work.
Finally: Practice. By the time I'm ready to get on stage, I've practiced enough hate my talk a little. It's all part of the process!
What helped me immensely was that I knew the material really well, and so when people had questions I found it really easy to answer them.
Ben Scheirman: Just jump in feet first! This was the advice I got, and you’ll know if you like it or hate it. When it comes to public speaking, there’s little substitute for experience, so just know that you’ll continue to get better each time you do it.
For my first real talk, I had an audience of 200+ developers. I was so nervous. I had dry mouth, my hands were shaking. I wasn’t sure I could actually go through with it. What helped me immensely was that I knew the material really well, and so when people had questions I found it really easy to answer them.
After the first few minutes, the audience was responding positively to the presentation (which was full of live coding, by the way!) and this helped to settle my nerves. So if you’re considering doing your first talk, pick a topic you know really well and knock the socks out of your audience!
Ellen Shapiro: Start small. It’s way easier to find out that you do or don’t need presenter notes when you’re talking to a group of 5-10 people than when you’re up in front of a group of 200.
Honestly, the only thing that’s helped me get genuinely better with this is practice. Not just practicing of an individual talk, but giving lots of different talks with lots of different ways that I could (and did!) screw them up. Knowing what’s hard for you as an individual helps you figure out what safety nets you need (like a full script in my case) and what safety nets you don’t.
Daniel Steinberg: The main thing I want you to know before you give your first talk is that your audience wants you to do well. We are rooting for you and we love to see you do well.
Most of the mistakes you think you are making that keep that voice in your head scolding you during your talk… we don’t notice them. If you don’t call them out, we probably don’t see them.
Pick something you’re passionate about. Ask your local CocoaHeads or other small group or folks at work if you can deliver the talk a few weeks before you’re going to give it at the conference.
Why a few weeks? Because then you will have a draft many weeks ahead and you can work on it based on the feedback you get. The main improvement I made in the talks I deliver is that I spend more time and effort on them now.
In addition, people like Paul and me and others would love for you to speak more often about topics you are passionate about. We learn so much from you and would love to help you along the way.
John Sundell: Practice. A lot! I often say that "I'm not a good speaker, I'm a good rehearser". Even if you've never given a talk before, or if you're super nervous about public speaking - you can come off as a confident & natural speaker given the right amount of preparation. Iterate and refine your content and get to know your slides inside and out. That goes a long way to making a really nice presentation.
It’s strange to think that folks spend weeks if not months preparing a talk, fly around the world to attend a conference, then after a mere 30-40 minutes it’s all over. But it’s true: when you’re on stage things can really fly by, partly because you’re hopefully able to deliver your presentation from memory at this point, but partly also because there’s a natural adrenaline rush.
Above all, don’t forget that attendees have paid a lot of money to hear you and the other speakers; it’s important you acknowledge the privilege you’ve been given and don’t just dash off to do some sightseeing.
But even though your talk is done, you’re not finished yet. You might have questions from the audience, there might be social events to attend, and I hope you’ll attend talks from your fellow speakers too – it’s not just common courtesy, but it’s also a great way to keep your own skills topped up with new ideas.
Above all, don’t forget that attendees have paid a lot of money to hear you and the other speakers; it’s important you acknowledge the privilege you’ve been given and don’t just dash off to do some sightseeing.
At App Builders, Carola Nitz said how great it was that we (the speakers) were sitting on the front row of the audience, because it meant we could cheer for speakers on the stage so they saw friendly faces, but also that we could be on-hand for any technical problems.
I responded that it’s also important to mingle with attendees so they can ask questions, and that’s when she dropped some really important advice: “I like to walk around between sessions, because it shows you’re available – if people see you’re free they are more likely to ask questions.”
This is so true. When you’re a speaker at a conference, even if it’s your first time, some attendees worry about disturbing you or aren’t sure if it’s OK to wander up to you to ask questions they have. If you’re open to questions – and hopefully you are! – please do make yourself available in a nice and obvious way, because it will encourage folks to come and say hello.
This has been a long article, but I’ve tried to cover as much of the process as possible and I hope it’s been useful. My goal in writing this has been to encourage new people to present talks in our community, because I love hearing new voices, new experiences, and new perspectives, and I know for a fact I’m not alone.
This article would not have been possible without contributions from some incredible speakers that I admire greatly. They are:
Now the article is ending it’s over to you. I wish you the very best of luck in preparing, pitching, and presenting your experiences, and hope to see you on stage soon!
Paul Hudson is the creator of Hacking with Swift, the most comprehensive series of Swift books in the world. He's also the editor of Swift Developer News, the maintainer of the Swift Knowledge Base, and Mario Kart world champion. OK, so that last part isn't true. If you're curious you can learn more here.