One thing we know is that responding to a conference call for papers Call for Papers can be intimidating. Sometimes it’s not clear what’s being asked for, whether your talk would be suitable, and, if you’re a first-time speaker, whether you’re ready to give a talk.

As part of our call for papers for Afrotech Fest 2019, we’ve prepared a blog series to shine as much light on the CFP process as possible. We’ll be highlighting amazing conference speakers who have things to share, as well as guidance on responding to CFPs, particularly our call for submissions, which is open now.

In our two-part interview, we spoke with Nadia Odunayo, who has given talks at RailsConf, Bath Ruby, EuRuKo, GORUCO and a number of other conferences and meetups. Nadia is more than familiar with speaking, reviewing calls for papers and supporting speakers. She’s also the founder of speakerline.io, which highlights speakers’ proposals to help demystify the CFP process.

In part one, Nadia discusses how she got into conference speaking and how she readies herself for a talk.

Who are you and what do you do?

I’m Nadia Odunayo, CTO at CodeNewbie. We build tools and produce content to help support people as they learn how to code. I’ve been a regular conference speaker for the past few years and I’ve been on a few proposal review committees as well. Before running startups, I learnt to code at the Makers Academy software bootcamp in London and then spent a year and a half as a software engineer at Pivotal Labs.

What was your first experience completing a conference call for papers?

I applied to speak at RailsConf in 2015. I had given a lightning talk at a PasS meetup in the Pivotal office and my boss, JB Steadman, came to watch. He really enjoyed the talk and said I should consider developing a longer version that I could then give at conferences. I needed some more encouragement but I was eventually convinced to give it a go.

Writing the first draft of the proposal was so hard. I’d never given a full length technical talk, and because the talk I had in mind involved a mathematical problem, I had to work through that first before I knew what the conclusion of my talk would be.

Luckily, I had JB and other people in the Pivotal office who gave me a lot of support as I wrote the proposal, including reviewing multiple iterations, and I ended up being invited to speak at RailsConf.

What was your talk on and how did you know you were ready?

My talk was called ‘Playing Games In The Clouds’ and it was about how we could use game theory, a branch of Economics focused on strategic interactions, to help us better understand distributed systems. In the story I told, I had a group of computers as the characters, and I used game theory to explain to the audience how we might design computer networks to be as efficient as possible.

I did a huge number of run-throughs of the talk, starting with multiple one-on-one sessions, and then small groups of around five people, before finally doing a public talk hosted at Pivotal a week before the actual conference. This meant that I got a lot of feedback as the talk developed so that by the time I was giving that public lunchtime talk, I had confidence that the central narrative of my talk was strong and it was now just down to me finessing little bits and pieces and practising my delivery.

I think a lot of people always feel as if they’re not quite ready up until the point of giving the talk, but if you book in a lot of these feedback sessions and start them off as early as possible in the talk development process, you’re likely to have a very strong talk by presentation day. One thing you’ll learn as time goes on is who in your network is good at giving helpful and direct feedback. You need people who know what they’re talking about and won’t be afraid to tell you to rework a central theme of your talk because it doesn’t make sense, even on the day before you’re due to give it at a meetup — this did happen to me once!

What does your talk preparation look like?

As I’m thinking up ideas and writing a proposal, I tend to keep my notes and ideas related to that specific talk in one place, usually in Evernote. So, the first step is reviewing these notes and the proposal, and writing out a talk skeleton. This is a high-level overview of what I’m going to cover. Then I flesh it out with more detail with what I call a semi-script: it’s not what I’m going to say word-for-word, but it does lay out exactly what sort of thing I’ll be saying and when.

At this point, it’s time to get started with some slides. Either I’ll go straight into Keynote, or I’ll sketch out what the slides will look like and then create them. The first draft of my slides hasn’t had too much thought with respect to design and features many incomplete slides with placeholders on them explaining what will go where. After the first draft of slides, I do a quick click-through whilst saying out loud summaries of what I’m saying on each slide. This is a great way to check that everything flows well enough and I’m on the right track before I invest more time in my slides.

At this point, I’ll start reaching out to one or two people who I want to have quick session with to show them an early draft of my talk. Say I’m writing a 30 minute talk, the talk I’ll give them will last 15 minutes. That’s how quickly I’m flicking through things — at this stage, I’m looking for something like: ‘you’re on the right track’, or ‘I think this part needs re-thinking’.

After I’ve done a couple one-on-one calls, I then flesh out the second draft of slides. By the end of this, all slides should be complete, with speaker notes, and the design should be decent. I’ll then do one or two more one-on-ones before putting together my first small audience of five or so people. I’ll take the feedback from that session and put together another talk preview for another five people.

By this point, the feedback I typically have either gives me confidence that I can go ahead and do a slightly larger audience — say 20-30 people — or I need to speak to a few subject matter experts about any sticky points. At this stage, I’ll also seek design feedback on my slides — this is such an important part of the process that is neglected by a lot of speakers.

A week or two before the actual event, I’ll have booked a meetup speaking gig. This is my last time giving the talk to a decent-sized audience before the conference itself. After that session, I incorporate the last of the feedback and just focus on refining my delivery from then on.

What do you were wish you were told before you first considered speaking at a conference?

There’s a lot of room for creativity in speaking topics! I spent a lot of time thinking that I’d enjoy speaking but not knowing what to talk about. I would have never submitted my Game Theory talk to RailsConf if I hadn’t had encouragement from my boss and someone on the committee at RailsConf confirming that the topic was something that Rails developers would want to hear about.

If I’d known how much flexibility I had in topic, especially at language-specific conferences, then I might have put together a proposal sooner. I wrote about this recently in a blog post called ‘So you want to speak at tech conferences but you have nothing to talk about…’.

Keep an eye out for part two of our interview with Nadia. Until then, you can find out more about what Nadia is up to on Twitter and at www.nadiaodunayo.com.