How To Get On This Stage (And What To Do When You Get There) - Mark Smith

Hello everybody, my name is Mark Smith, although I'm known as GG2K pretty much everywhere online. And this is my talk, how to get on the stage and what to do when you get here. So early last year I submitted this talk to DjangoCon Europe and I was very excited about getting to visit Porto. I love Portugal. I took this photo in Lisbon a couple of years ago and I learned to surf in Portugal last year. And then COVID-19 hit. So I'm still at home in Edinburgh. And not only that, I'm giving a talk called How to Get on This Stage and What to Do When You Get Here. And there's no stage, and there's no here. Um but and I'll be using the word stage a lot during this talk, but Almost everything that I say applies equally

to the world of virtual conferencing and doing these things over Zoom and other video conferencing platforms. So this is my fourth DjangoCon Europe and my eighth Django conference altogether. But I'm not really a Django developer. But I love the community and I really wanted to speak, and I do know something about public speaking. I'm a developer advocate for MongoDB, which means my job is to educate and inspire developers with what they can do with MongoDB and to speak as the voice of the developer when talking to engineers within MongoDB. And normally, when there isn't a worldwide pandemic problem, I'd be speaking about different technical topics at one or two conferences a month. And I'm not an amazing speaker, but public speaking over the last few years has changed my life

I've traveled all around the world and I've given talks in many places and I've met so many people from this community. And it's always nice to be part of that community and to be able to give something back. And in the past few years, I've been hosting the lightning talks at EuroPython and PyCon UK, and my predecessors uh used to fill the time by telling jokes. In the case of Harry Percival um telling one joke across all of the gaps between all of the lightning talks over two or three days. But I don't know any jokes Um and I looked some up online and they weren't very funny. And I thought, well, what am I going to talk about in these gaps while people are setting up their laptops in between these five-minute talks? And I thought, well, public speaking has been such a great thing for me that I could encourage people to give a lightning talk.

Really the whole purpose of lightning talks is to encourage new speakers to speak, which hopefully leads to them submitting talks to the call for proposals at a later conference and giving full-length talks on things that maybe only they know. So I thought I would turn some of my little lightning talk pet talks into a full-length talk with some structure, and that's what this is. So, giving a talk at a conference like DjangoCon Europe can be broken down into approximately five stages. The first is that you submit a proposal, and that proposal will be accepted. And at which point you then write your talk and build your slide deck if you're using one.

And then you practice. And you practice and you practice. And I will come back to this. And then you perform, you give your talk, you step onto the stage and behind the lectern, and um you explain or expound or inspire. a group of developers about things that you know or things you've experienced. And then finally you get to bask in the glory of a job well done and the admiration of your peers. But before you start this first step of submitting a proposal to a call for proposals , there are a couple more steps. And the first one is you need to decide to give a talk. I don't think anybody has ever submitted a proposal to a conference without first deciding that they want to give a talk. And I'm not going to cover this right now.

I'm going to come back to it. I'm just going to assume at the moment that you're going to be so inspired by this talk that you've already decided that you want to give a talk. So once you've decided you want to give a talk, you need to work out what you're going to talk about. And this in many ways is the difficult thing because it relies on inspiration. And inspiration is not one of those things you can necessarily control, but you can help it along. So I recommend keeping a notebook of some kind. It can be a physical notebook or it can be a text file or a Google Doc or some notes application that you already have on your phone. And just every time you come down come up with an idea of a talk that you could give at a conference, write it down. Make sure that you don't lose it. Even if they're bad ideas, keep a list of every idea that you come up with

Think about the things that you know or the things that you've experienced that maybe aren't so widespread that you could explain or describe to an audience of people. Talk to your coworkers and friends, maybe even ask them what you're good at and the kind of things that you should be communicating to an audience. Watch other talks, go to meetups, talk to people, learn from other speakers, and copy techniques if you want to. If you see a talk that isn't very good or perhaps doesn't explain something in a way that was helpful to you, maybe take that topic and write your own talk on that topic that is better for people maybe with your experience or your background. You can take a blog post, either one of your blog posts or somebody else's blog posts, and you can turn that into a talk. Again, be careful of plagiarism.

You're not supposed to just take somebody else's content, although there's always the potential that if you ask uh somebody who wrote a blog post nicely, they may be quite happy for you to write a talk around their topic and then maybe you just credit them in your talk and say where the original inspiration came from. Some of my talks have actually come from rants or raves in the pub, so just talking about people building things the right way or the wrong way. um or the latest blog post that I've written in the pub and then you start to realize that what you're essentially doing in an exchange with your friends is describing a talk that you could get give at a conference. So make sure you get all these ideas down on paper And then when it becomes time that your conference opens up its call for proposals, at which point they will be broadcasting on Twitter and other mediums that they are accepting proposals for their conference, then hopefully you have a good list and you can filter it down to the ones that are

best Pick the idea that you like best and fill out the proposal form. If you're looking for ideas, actually the best place to look is the CFP page for the conference that you're applying to. They will almost Always have a section like this. This is actually from the DjangoCon Europe website this year, and they've listed the things they would like to see talks about. Some of those are basically titles for a talk. And I can guarantee, I'm on a couple of program committees, that probably only about half of these were submitted as talk ideas. in the end. People either read the list and decided they couldn't write a talk or didn't want to write a talk on that subject, or they decided everybody else would be writing a talk on that subject, so they didn't want to compete. or they didn't read the list at all. And so

all of these the organizers who really wanted to see these talks, there's no proposals for them. So you're already at an advantage if you submit a talk that matches one of these topics. because it's all it's pre-vetted by the organizers. It matches exactly the kind of thing that they want to see. So you already be somewhere towards the top of the list. Now you need to submit your proposal. And I've been on the program committee, as I say, for a handful of conferences, and the truth is that about half of the proposals you receive are not very good And that doesn't mean then that they're a bad idea, but often people either don't read the instructions properly on how to fill out the form, or for whatever reason, that the proposal is just only half thought. through. So don't submit a low quality proposal.

If you want to be accepted to speak at a conference, submit a high quality proposal. And I'm going to go through some steps you can do to ensure that in a moment. Get someone else to read it through, make sure all the sentences make sense, make sure everything's in the right order, make sure it's coherent so it uh everything builds on the thing previously, so it's not just a grab bag of random thoughts that you've had that you've written down in a text field And make sure that your proposal describes what you're going to talk about. So, we've decided we want to submit a proposal. How do we go about that? Well, the first thing to do is to write an outline. This I usually write this as bullet points in a text file in Markdown. But it could I know other people who do this in uh with mind maps, either physically on paper or in the computer. But I either way you need a hierarchical idea of what you're going to talk about.

So you need your top level points, which I write down as for a 25-minute talk, it would be five to ten bullet points, ideally more towards five. And that means you can talk about that subject for two to five minutes in general. At this point, you probably need to step away from your mind map, maybe get things down in a chronological order. You need to order the things you're going to talk about so they make sense, either as a story or as a series of concepts building upon the previous concepts. It doesn't have to be set in stone. This is just a proposal. The proposal's actually the easy bit. You can change your talk outline a bit. It will usually change while you're writing the talk anyway. But don't change it too much after it's been accepted, because that's rude.

Once you've taken your out once you've written your outline, you take it and you condense it down to a pitch. And these three exclamation marks are here on purpose because this is the exciting bit of your proposal This is usually every CFB is different, but this is usually one to two paragraphs that's designed to excite people about your talk idea too, of both the organizers for accepting your talk in the first place, but also it usually goes in the brochure. So it's um uh to encourage people to actually attend your talk uh or even to attend the conference in the first place. So write one paragraph, answer the questions, what is the talk about? What broad topics will you cover? Why should somebody come to see your talk? If you can make it dramatic, then definitely do so. If you're comparing laying transatlantic telegraph cables

um to dysfunctional software teams, definitely make sure that story is front and center in your pitch. It's a pitch for your talk, not you or your company. Nobody is interested in how great you think you are or how great your company thinks your company is. So make sure that you're actually talking about a technical topic or at least a topic that the audience will be interested in If you've done something good or terrible or interesting, also make sure that story is front and center. This is this is very much, this is your chance to sell your story. I usually take uh I usually write up my pitch in Markdown and then I copy and paste it into an app called Hemingway. Um Hemingway is really good um at just sort of checking grammar and style and making sure that your language is punchy and you're talking about doing things rather than having done things

or maybe considering doing things in the future. So let's look at a CFP form. This is actually the proposal that I wrote for this talk right now And I think it's pretty good. And because it's not a deep dive into a technical topic, I think it works quite well as a case study of a proposal for a conference. So there's a title, which I try to make as exciting as possible. Again, how to get on the stage. I actually think titles sell talks more than a lot of the rest of the content in a proposal So again, like do write down several ideas, try to pitch the pick the punchiest, because this is the thing that often the reviewers will see before clicking through to even decide to review to add a review to your talk. Then I've I selected a 40-minute talk as the format.

And then I've got an abstract, a description, and my notes. So the abstract, again, this is usually the thing that goes in the brochure or at least in a little box on website. And this is I'm going to read this in full. Would you like to give a talk at DjangoCon but don't know where to start? Does the idea of getting on the stage terrify you? Of course it does. Everybody is terrified of public speaking This talk will tell you why you should give a talk and how to go about it. I'll cover submitting a proposal, writing your talk, preparing to speak and actually getting behind the lectern to thunderous applause. And obviously that last bit is has turned out to be a lie because there is no no stage, there's no lecturin and no pause. I'm just imagining it.

It's fine. So I I'm quite proud of this because it starts off with a couple of questions. They're relatively universal. The first one tries to the first sentence tries to hook in people who would like to s already like to speak at DjangoCon but don't know how to do it. Um the second one is more universal. As I say, everybody here is terrified of speaking on stage. It is weirdly addictive though. I do highly recommend it. And then the third sentence starts to bring you in to this talk will tell you certain things. And then the last sentence is really a breakdown just for the people who actually want to know a little bit more detail without going through to the full description. It says writing the talk, preparing to speak, actually speaking. The description is a much longer version of that, and I'll read this in full.

I'm only kidding. So the important thing here is actually the headings. Coming up with an idea, submitting a proposal, this is my outline. This is the out the first thing that I did when proposing when putting together this talk proposal. These are my top level outlines and then for each one if I go back there's one to two sentences for each one just showing that I really can talk about that topic for a few minutes. The introduction at the very start, before the first heading, is basically the same as the abstract with a little bit more detail. And then there's a little sentence at the end to just kind of wrap up the exciting feeling of having given a talk and receiving applause from your peers. And then in the notes. The notes often nobody writes anything in those, but they can be really useful um to get your point across to the organizers.

So something that maybe is even a little bit more too mundane to put in the description. But you you want to make sure the audience, the organizers understand what you're trying to do. So here I've just said, although it's aimed at beginners and to encourage new speakers to speak. It should have enough content in it that it should be useful or maybe just inspirational for more experienced speakers. So now you've submitted your call for proposals, prepare to be rejected. I get rejected all the time. All speakers do. You sometimes get feedback, but you usually don't. There are many reasons that you may be rejected, and some of them are things you can fix, and some of them just aren't. Your proposal may be bad.

It may not have been very well put together. If you follow the tips I just gave you, then that shouldn't be the case. Maybe your talk idea just isn't that engaging. And you might need to go back to the drawing board and either tweak it or perhaps pick a different topic to speak about. Something more subtle is that perhaps there was another proposal on the same topic that was slightly better than yours. And maybe they're just the the speaker is just more of an expert on that subject than you are. And you will probably never know that this happened. But don't you should never feel disheartened when you're rejected. This is something that happens to everybody. Um and uh it yeah, it's it's just part of the the proposal process. Perhaps your topic or proposal was just considered a bad fit for the conference.

Again, if you looked at the CFP page properly and looked at that list, then hopefully you should have a good idea of whether your talk is a good fit. A secret of people on program committees is that they're very busy and they only have a certain amount of time per proposal to actually decide whether it's a good fit or not. Perhaps a quick skim of your proposal didn't excite them enough to read it in more detail. And you've got to know, even though maybe they didn't understand the nuance of what you were trying to say. There's nothing you can do about this except volunteer to help organize a community conference and join the program committee because the more reviewers you have, the more time everybody can spend reviewing the talks. It's also a really good way to learn how to get better at writing proposals for conferences because you're going to see a few of them.

If you're rejected Don't throw away the proposal. You can submit it to other conferences or perhaps even the same conference the next year where it may get accepted. I've known that to happen in a few cases. So, if you've submitted a few proposals to different conferences and eventually you get accepted, your first job is to confirm with the organizers that you can still speak. in most cases, and now you can start working on your talk. Build yourself a timeline that leads up to you either submitting the talk video or giving the talk live on the day. Do not forget about your talk until a week or two before the event. Come up with this type timeline, set yourself a deadline for starting to write the slides, completing the slides, coming up with ideas, all of the different steps of the creative process.

Keep a working document from the beginning, much like trying to come up with ideas, if you can jot down every idea you have. for the content of your talk. When they come to you, then you're going to have more content to put into your slides when it actually comes to building your presentation. So now you write your talk and this is a very difficult thing to to even speak to you about because everybody has a different process for this and a different set of skills. I am not fantastic at design, so I tend to work a lot with kind of default templates and these big title slides that I talk over. Everybody has a different style for presentation. I could just be speaking in front of a photograph of, let's say, somewhere in Portugal right now. I find the titles are quite good for sort of anchoring the general subject area that I'm talking about at a time.

Before you start designing your writing your talk or slide designing your slides, read the code of conduct because you you are now a content provider for the conference and so um Everything you need to do needs to fit well within the code of conduct. Don't break the code of conduct. That's genuinely a terrible thing to do. And now a short segue about bullet points. Bullet points are the default option in many slide packages. If you create a new slide, you get a big text box, it's already got bullet point placeholders in there. They're really quick. It's really quick to just write down some bullet points and hit return and add some more bullet points. They're easy. You don't even really need to know how to use the package. You just need to be able to type a little bit. You don't need to uh be good at design, you don't need to arrange things on the page because the more you type it just it just arranges them for you.

But they are kind of one-dimensional. They don't tell you much other than the words that you put up there. And if you put up all the bullet points at the same time, then people will read ahead. And they won't really be listening to what you're saying. And they're kind of boring. I mean, this is uh uh this isn't the most um exciting slide deck I've ever put together in general, but this is also the most boring slide in the entire presentation. The problem with bullet points is they're notes for you. And most presentation packages already have a notes section and that you can keep up on the speaker display while you're speaking. So I'm reading notes that I wrote for myself. uh right now while you are looking at a slide of bullet points. So I have strong opinions about bullet points, but if you know how to put together a presentation with bullet points and that's what you're comfortable with

Or maybe that's all you have time for, do it anyway. Tell your story, communicate your experiences to an audience. The bullet points can just be there to help you, to give you that comfort in giving your talk. Providing you have exciting content or useful content, your talk will still be hugely, a hugely valuable contribution to the community. So the way I think about useful and interesting is as a graph with these two axes. So we've got interesting at the top and useful on the right And so that gives us some quadrants. And the quadrant you should really be aiming for is this one up the top right. You should be useful and interesting. But don't think for a second that you have to be. If you don't think you're very interesting, it's okay to put together a talk.

That's useless, uh but interesting or useful but boring. Um people come to conferences to learn new things, not necessarily to be entertained. Sometimes it's nice to be entertained by something light-hearted in between two deeply technical talks. Fundamentally, this is how we put together a program that's diverse and works towards different audiences. So both of if you think you're clever but boring, or really interesting but not very clever, still put together those talks. They are still valuable contributions to the community. The thing that you should be avoiding is this quadrant here. Just don't stray into useless and boring. It's that's I don't need to say anything more about that.

If you uh would like help with designing slides, I really recommend these books. There are also websites. Presentation Zen specifically is both a book and a website. These will really help you up your game with slide design, especially if you try are trying to uh wean yourself off uh bullet point dependency. Um The Presentation Zen, especially the website, is a fantastic resource describing different people's presentation styles, how you tell stories, how you create drama, how you tell technical, uh how you uh educate people on technical topics. Um TED talks as a general thing uh um have been hugely inspirational, especially to me in terms of these short talks that often say something quite profound. And the

they emphasize rehearsing and rehearsing and rehearsing. So their speakers are always very polished. And I'm yeah, I I've watched so many of those I I don't think I could even pick a favourite. This third book here, Slidology, is one that I own and I refer to quite a lot. It has a whole sections on slide design in general, how to come up with a speaking style. how to replace bullet points with lots of different diagrams that add extra dimensions to the thing that you're talking about. So I highly recommend that book. So once you've written your presentation, you've put together all your slides, you've added your holiday photos, you're going to see some of my holiday photos. then you can uh you need to start preparing to speak and the this comes down really to one

thing which I'm gonna repeat three times Rehearse, rehearse, rehearse. I put out a question on Twitter a few weeks ago about what people thought the secret was to. to giving good presentations and almost everybody came back with this. There were a couple of people who said if I rehearse a talk then I can't present it because I find it really boring. So I put together my slides and then I just make it up as I go along And I happen to know those people are incredible speakers. So if you can do that, uh fine, but I would very much recommend that you rehearse and rehearse and rehearse. I underestimated this so much when I started. Nowadays, I tend to rehearse my talks around eight to twelve times before anybody else ever gets to see them.

As well as rehearsal, I really recommend giving your talk to a meetup or a group of friends or a group of colleagues beforehand Apart from just finding out whether you speak faster when you're nervous, it will give you accurate timing, hopefully, for how long your talk is actually going to take. I've had talks that I've written and I thought were about the right length go over by 50% sometimes with my first reading in front of other people or come in very short. So giving a talk in front of other people is definitely something that's very valuable, especially if you're a less experienced speaker. So now you've rehearsed and rehearsed and rehearsed, it's time to give the talk. And there's not really anything I can say about this, um, except you'll be nervous, but but if you followed the previous step, You won't be too nervous

because you know how it how your talk goes. You're not going to be trying to squeeze it into time that it doesn't fit into. You know if you've given it to a smaller group beforehand, you know the bits that people will laugh at um or be educated by or things that they have questions had questions about that you've fixed in your presentation. So preparation is really the key. Once you get up on the stage, you're allowed to be nervous. Everybody is nervous. But you will also be practiced and your speech or your talk will be excellent. At the end of the talk, there's a Q<unk>A section, and this is probably the scariest bit, especially if you're less experienced, where there will be five to ten minutes where people will be allowed to ask you questions live that you don't get a chance to prepare for.

But there's a big secret. You don't have to take questions. If you tell the room chair before you start speaking that you won't be taking questions, then they shouldn't get it start handing a microphone round at the end or asking the audience to submit questions to you. But question and answer can be a really rewarding part of the talk for people. It helps the audience drill down into parts of the talk that maybe they didn't understand correctly or aren't sure that they understand correctly. But where non-questions, if somebody stands up and makes a statement, thank them and move on as quickly as possible. They're not supposed to do that, but for some reason people do anyway. If you got asked a question and you don't know the answer, don't make something up. Say you'll talk afterwards or you need time to think about it.

You don't need to be an expert in everything to give a talk at a conference. Now, obviously, everything's changed in the age of COVID-19. I used to pack my Viking helmet into my bag along with my Django girls t-shirt, and then I used to get on a plane to Schiphol and fly somewhere in the world. where I would be told I looked great and take a selfie in the bathroom. Um, and then I would stand up on the stage, possibly wearing a kilt, because I live in Scotland. Um and this is and you hear your the rumbles of laughter or applause as you give your talk. Um and all of this has gone away and I kinda miss it. Instead we get this. But there are still big pros to actually this new world with virtual conferences. They are cheaper, they're easier to get to, so much more accessible for vast parts of the world, which is wonderful for our community overall.

And the conferences are still happening. That's the best thing. We're still able to have conferences, even though we're all remote. The thing for you as uh maybe a beginning speaker is that many um allow or even insist on pre-recorded talks, which is wonderful because it means you get to do your rehearsals while recording them and then when you get do one that you think is good enough You submit that as your pre-recorded talk. There's no live giving a talk nerves. You get as many chances as you want to to give the talk, the way that you want to. The cons I find are it's really difficult to be expressive in front of a camera. I tend to resort to a monotone when I'm not thinking about it explicitly Um and it's really difficult to simulate that community feel and the positive feedback from the audience.

The Django and Python community is one of the most wonderful uh in the world. They are warm and encouraging uh and they're I I've never had a bad experience with a with a Python audience. So once you've given your talk and you've answered some questions, potentially you can bask in the glory of a job well done and the admiration of your peers. And now I'd like to take a a step behind uh in front of the um lectern for a moment. I've described how much work it takes to speak at a conference, and you're about to see some talks given by volunteers prepared in their own time purely because they want to tell you something. So please be effusive with your praise, quiet with your criticism, and keep any challenges you have to yourself.

During the Q<unk>A session, ask questions which help encourage the speaker to expand on the topic that they were already talking about. Don't use them to show how clever you are. Don't ask a speaker who's just spoken about X if they've also heard of Y. Don't use them to show yeah the Uh don't uh ask them to go back a few slides and explain something in more detail that you didn't quite understand. If you didn't understand it, then probably other people didn't either. And if you want to ask anything that wasn't directly covered in the talk, ask afterwards, in a private chat or a private discussion. So, to circle around to my original question, why might you want to give a talk? And the answer is: be part of this community. This conference exists because the community organizes it and because the community provides the content. It's good to give back.

If you've ever learned anything useful in a talk, you can be on the other side of that imparting your knowledge to other people. It's a conversation starter. People will come up to talk to you because they know something that you know. So they you have a shared topic of conversation. It's a challenge. Learning to public speak is difficult. And so it's a life skill. It's something that makes you a more rounded person. You can also learn subjects by speaking on them. If you pick a subject you don't know in detail and you learn it in detail in order to give a talk, that's actually made you a better developer. And writing a talk is a good opportunity to learn something really well. It's great for your CV or resume. And one day when this new normal is all over, hopefully, we'll get to travel again. And I get to meet you all in person and get to come and watch the talk that you give.

Thank you very much. Any questions?