On speaking
For those of you who don't yet know me, I'd like to start off with some credentials.
Over the last couple of years I've been doing a lot of public speaking. I've presented at many international conferences across the globe.
In 2024 alone I spoke at the following conferences:
- PyCon Namibia (Keynote)
- DjangoCon US (Keynote)
- EuroPython
- PyCon Italia (Keynote)
- Esc@pe conf
- PyCascades
- PyConZA
- GDG Devfest Johannesburg
- PyLadiesCon
I'm going to speak at a few more this year.
This might seem like a bit of a brag-roll 👆 Blowing my own horn can make me feel pretty uncomfortable. The reason I included this list is because I would like to validate the advice I'm giving here.
I've put a lot of effort into getting good at this stuff. I want to share some of what works for me. It might work for you too.
Applying to talk
Before you do a conference talk, you need to apply to talk, and your application needs to be accepted.
The problem here is that the skills required in applying to talk at a conference are quite different from the skills required for delivering the talk.
Here are a few tips for this phase:
(Disclaimer: some of these tips might be hard to use if you are applying to talk in a language you are not fully comfortable with. Try your best and use what works for you.)
(Note: a lot of the advice in this section is fairly generic writing advice. It's useful for writing proposals, emails, and many other things)
Proposals directory
Don't simply write your proposals, submit them, and forget about them.
Keep them. Revisit them. Polish them and combine them over time.
I make use of Obsidian for this, but any document structure will do the trick.
Write like a human
When you write anything at all ever, make sure it would sound good if read aloud. This is a really simple easy thing to do, and it's very powerful.
By reading things aloud you'll see if your punctuation and sentence structure is sensible. You'll get a feel for the rhythm of your words. Yes, the written word has rhythm.
If you read your proposal aloud and it doesn't sound like something you would say then that is also a problem. Many people try to fancy up their words and end up sounding fake and silly.
Write in your own voice.
Don't try to be fancy
I was recently working with PyConZA. I was helping with the opportunity-grant program.
I sent out an email to a bunch of people who applied for grants, I was letting them know that we were short on funds.
One applicant responded with this gem:
Thank you for your response. I do hope for the very best in the acquisition of more sponsors that’ll therefore facilitate my attendance to this prestigious event PyConZA 2024. Kindly keep me posted if anything arises. Warm regards.
What impression does this give you? Does this seem like a professional?
Clearly no. This person seems like they are trying very hard to imitate something that they are not. It comes across very badly.
This is a mistake I've seen a lot in people who are very early in their careers.
Here are a few readings on the topic:
Avoid slop
Slop is the new name for unwanted AI-generated content.
Slop is often very easy to spot. If your proposal contains slop you will definitely be rejected, and the talk reviewers will not think very highly of you.
Put care into writing your proposal yourself! Use your own voice.
That said, I personally use LLMs while I'm writing. But not to write the final result. LLMs can be useful for figuring out nice ways to phrase things, or to spot problems and make suggestions
It's completely fine to use this powerful tool to enhance your own thinking and output. But do not outsource your thinking.
Don't be boastful
I've reviewed many proposals that say things like "in this captivating talk", "prepare to have your mind blown by this excellent blah blah" and similar.
Please don't do that.
The talk proposal isn't there to tell everyone how entertaining and cool you are, or how highly you think of your public speaking skills. It isn't a sales pitch.
Take care
Here are a few more small tips:
- Use a spelling and grammar checker.
- Don't submit a wall of text. Use paragraphs to make your stuff easier to read
- Always proofread
- Use the active voice (Eg: "An application was built" is passive. "We built an application" is active. Active sounds much better)
Empathise with the reviewers
Your talk proposal will be read by humans. These humans will read a lot of proposals.
Try to catch their attention and get to the point quickly. Think about what you need to convey and keep your writing tight and to the point.
Many will skim read your proposal. Try to set these people up for success by making sure they can get the main details quickly.
On topic
Make sure that the talk you are proposing is in line with what the conference is about. If you aren't sure then you can generally reach out to the organisers and ask questions, or chat to people about it online.
Or you can just submit the proposal. If it is off topic then it'll be rejected. That's really not a big deal.
Avoid
If your talk is a sales pitch then that would be bad. A conference talk should add value to the audience. It is not about extracting value.
Your talk should also not recommend anything immoral or illegal.
Multiple proposals
There is no reason to limit your number of talk proposals to one. If you have 3 talk ideas then submit 3 proposals. It's completely fine.
Learn from the best
If you are new to this then spend some time looking at the schedules of different conferences. Read the talk descriptions. You'll be able to see what was accepted and what wasn't. You'll be able to see what the best speakers focus on in their proposals.
What did I miss?
Ok, that was a lot about proposals.
I tried not to say anything too obvious. But I might have missed some stuff.
If you feel like I missed anything important please say something on the socials :)
Want to learn from me?
I'm running some technical workshops and mentorship over at Prelude. These are damn fine learning experiences.
If you or your team are likely to benefit from learning how to use these tools the fast way, join a workshop, or reach out if you want training for your team!
Also, if you know someone who would benefit it would be very helpful if you shared a link and a kind word.
One of the major goals of offering training is to find sustainable ways to spread skills to folks that need help.
❤️ Thanks!
On with the show...
Preparation
When a proposal gets accepted then it's time to prepare the talk itself. There are multiple parts to this and, for me, it's a fairly iterative process.
Foundation: Slides
The first thing I do when it's time to start preparing the talk is I set up my slides. I don't make all the slides up front, this is just the setup:
I like to use Reveal.js for my slides.
Since Reveal allows me to code my slides, it allows me to create a template repo that I can set up how I want. This makes it easy for me to quickly get started on a new slide deck.
I always host my slides on Github Pages so that they are easy to share.
My foundational slides always have a few pieces:
- Slide 1: a bunch of useful links
- Title slide: Yes this is after the "useful links" slide
- About me: There should always be a slide where you introduce yourself
- QR code slide: this is my final slide
The QR code will link people to the hosted version of my slides. They will land on the first slide and will immediately have access to all the useful links. They will then be able to navigate to the other slides if they want to.
Here is an example. This is my keynote presentation from DjangoCon US 2024.
Table of contents
A lot of presenters start off by telling the audience what they will cover, and then they wrap up by saying what they covered. It's a familiar pattern that many recommend.
I don't do that.
A lot of the time it's a bit dry and unexciting. There are situations where it can be useful, but mostly it's not.
If you are applying to talk at a conference then I'm sure you would have watched some talks in the past. Even online. The best talks typically do not start off with a table of contents.
The best talks take the audience on a journey.
Audience attention
Always empathise with your audience.
If you present your audience with a wall of text, do you think they will be listening to you or reading the text? Keep the text to a minimum, and only reveal text as it becomes relevant.
Reveal.js makes it easy to reveal different portions of a slide over time. I use this functionality a lot.
If you are doing a technical talk and you need to show the audience some code, don't show them all the code. Show them the relevant parts. Guide their attention to the things you want them to see.
Narrative
This advice might not work for everyone. My talks are usually about telling a story or making an argument. For me, the narrative flow of a talk is critical.
I'll start off my getting an idea of the major points I want to hit, and in what order. The argument needs to build up, the story should build to a climax.
There will be some fine-grain details and conclusions I'll want to draw, some specific information to share. I work to find places in the main narrative flow where where different pieces of information will fit naturally.
The way I capture these thoughts is in my slides.
Many people write out their talk in a long-form way, like an essay, I do not. I go straight into slides. I start off by capturing the major arc and the major points in the right order.
At this point, the slides will be something like a skeleton. They would be far from polished, and full of todo notes and awkwardly worded headings. That's completely fine.
After this I iterate...
Iteration
I practice and polish my talk all at the same time.
I do not use speaker notes or queue cards. The slides themselves help me remember what to say.
I'll run my slide deck and start from the top and try to tell the story I want to tell by literally talking. I'll say the words, I'll introduce myself and the topic, simulate the whole thing.
The first time I do this, it will be a struggle. There will be things I forgot to write down, I'll notice that my slides are in the wrong order, or that there is a section that just does not fit.
I'll often find that one section is more of a struggle than others and I'll focus in on it and go over it again and again.
I keep note of the problems and fix them along the way.
Then I do it again.
On every practice run my delivery will become smoother and my slides will become better. I'll fix problems and fill in gaps as I go.
After many iterations I'll have a narrative that I'm happy with. The slides will be as they should be. And I'll be able to talk through the slides with no problems and no speaker notes.
The words will not be the same
When I practice a talk then I do not try to say the same words each time. The focus is on the message I want to get across.
Often when I get up on stage and do the final talk, the words that come out of my mouth are new and unpractised. And that is completely fine. I'd go so far as to say it is a good thing.
If I'm losing a crowd then I can tweak what I'm saying or my tone of voice on the fly to pull them back in. Or I can hurry over the parts that bore them.
And if the crowd is especially engaged then I can try to build on ideas in different ways.
This does not happen consciously most of the time. Generally when I am on stage I watch the crowd and the words sortof tumble out of me as I move through the slides.
The ability to adapt on the spot comes from practice.
Timing
Conferences typically run on a tight schedule. Talks need to be of specific durations otherwise the whole schedule gets thrown out of whack. You might be given 20 minutes, 45, or something in between.
Make sure you know how much time you have!
The way I get my timing right is as follows:
Once I have the general shape of my talk nailed down, I divide my talk up into sections. Each section is a natural arc of the story. Reveal.js is cool because it allows you to arrange your slides in rows and columns, I generally put my slides into columns to make it easier to keep track of the different sections.
Then, as I practice, I use a timer. I'll time each section individually and write the times down and add them up.
Here is an example:
me 2:45
everyone is an expert 5:00
normal classroom 3:50
bloom: 6:40
mbl-> master teaching 1:00
filling of a pail: 4:30
growth mindset: 5:00
framework: 3:30
assess 7:00
protege effect 1:38
guild 3:27
Earlier on I mentioned that every time I practice it's a little different, the words are not the same. So every time I practice the timing will be a little different too.
This is alright.
I practice each section a few times over to get a feel for how long it is. The time will vary by a few seconds here or there but, as I practice, the variations become smaller.
Sometimes, at this point, I need make hard decisions about what parts of the talk I need to trim down or throw away completely. There is often too much to say.
I also find that practising with a timer helps me be spot which parts of the talk need more practice. If I'm focusing on time and stumbling over my words then it means I'm not ready yet.
Spread the practice out
I generally start preparing for a talk ages in advance. I do not leave it until the last minute.
The practice I do will be very spread out. I'll practice the talk twice one week, once the next, and so on until I get closer to the conference. I fit it in where I can.
The fact that I'm spacing out the practice instead of cramming it in makes the practice more effective. I'm using a learning technique called "spaced repetition".
I even space out individual practice sessions. I hardly ever practice the whole talk in one go. I'll practice a section or two then I'll go get a cup of tea, come back and make some edits, then practice it again or move onto the next one and so forth. Stepping away from a learning task from time to time is actually very helpful, it allows you to process the information in different ways.
Pre-talk rituals
On the day of the talk, I'll do a few things:
- practice one last time (and probably make a few last second changes to the slides)
- try to stay away from foods the mess with my attention span (yeah, this is a thing for me)
- avoid excessive caffeine
- try get some morning exercise (even something small like star jumps in my room can do a lot of good)
I'll aim to show up to my talking slot early. Probably earlier than required. This is partially due to being nervous. If I can sit in silence I'll do that.
Game time
When it comes time to talk, a lot happens on reflex. A few pieces of advice I can give are:
- use your slides to queue what you are going to say next, but don't stare at them
- focus on the crowd. Pay attention to their body language. They should be silent and watching you. If they are fidgeting you are losing them
- remember to breath
- use your own timer. I usually use a timer on my cellphone so I can see if I'm moving too slow or fast. I leave the cellphone on the podium next to my laptop
- use expressive body language
This last point is a big one for me. Body language matters a lot.
If there is a podium or lectern then don't simply stand behind it. I intentionally walk away from the lectern so that the audience can see all of me.
I make a point of maintaining an open, confident posture. I make a point of gesturing with my hands.
I also make a point of varying my tone of voice and sentence length. I'll pause for dramatic effect, and let the slides complement my words in different ways. This all comes from practice.
Questions?
Generally there will be time for questions at the end of the talk. I love questions.
There are 2 pieces of advice I can give on this section.
- It's alright to say "I don't know"
Sometimes people will ask you about stuff you don't know about. It's really not a big deal to say "I haven't heard of that", "I haven't figured that part out yet" or some variation.
- Be prepared for weird questions
Some people will ask very confusing questions. The questions might be strangely worded. Or they might just be strangely strange.
It's alright to ask people to clarify or reword their questions.
And if you take a stab at answering a weird question and you are not 100% sure if you actually answered the question or not, you can always check. You can give the best answer you can and then follow it up with "Did that answer your question?"
Resources
I used to suck at public speaking. Really. It was bad.
Here are a few books that helped me a lot:
- Talk Like TED: The 9 Public-Speaking Secrets of the World's Top Minds - Carmine Gallo
- On Writing: A Memoir of the Craft - Stephen King
- Bird by Bird: Some Instructions on Writing and Life - Anne Lamott
Yeah, 2 out of 3 of those books are about writing, and not speaking. But there is a lot of overlap.
There are certain mindsets that come into play when writing. I apply those mindsets to preparing talks.
The end
I hope this was helpful! I invite you to share it with anyone who could benefit!
Do you want to support this work?
If you find this useful, there are many ways to support the work I do:
- Join some of my technical training
- Ask me about tech education consulting and teacher training
- Donate to the Guild of Educators
- Share this article with someone who would find it useful