This week, I gave a bad talk. Immediately after I had finished I knew that I wasn’t quite happy it, but I figured that perhaps I was just being a little self critical. Then the feedback started to roll in.
It was a bad talk. Now that I’ve had chance to sit and reflect, I think I know why it didn’t work as intended.
It was a talk that I gave because I had an abstract ready, instead of it being one that I really wanted to give
There are lots of other reasons too, but this is definitely the main one. When you’re speaking about something that you’re not passionate about, it shows. Without the passion, I had no direction for the talk and it ended up being two talks, clumsily merged into one.
When writing the talk, I had no idea what level the audience would be at. Initial feedback has told me that I assumed too low – lots of people already knew what I was saying for the technical portion of the talk. Personally, I had assumed that we’d have a room of mid-level developers just getting started in an operations role. I assumed wrong. If possible, ask the organisers what level of people you can expect at the conference. You can never get it 100% right, but you can do better than I did.
Secondly, I couldn’t decide between a soft or a technical talk. I recently watched a talk from last year that focused on the softer side of DevOps, so I decided that I’d go for the technical side… except I spent half of the talk explaining what DevOps is and how to apply it. Just what I’d hoped to avoid. This meant that the technical portion was too small to cover anything in depth, so I kept it very shallow. Next time, I’ll choose to go either technical or non-technical and do it properly.
I thought I could cover both sides in one session as the session was longer than I’m used to. Previous talks I’ve done have been 40 minutes – this one at 60 minutes, 50% longer! Instead of finishing 10 minutes early like some other talks, I chose to go a little deeper (though not deep enough) in some topics. As I only did this for some and not others, it broke the flow of the talk. I wish that I’d skipped those bits and finished a little earlier with a more cohesive talk.
Of course, had I practiced the talk at my local user groups, all of this would have come out before I presented at a conference. Unfortunately, I agreed to too many events, each with their own brand new talk, too close together. At Benelux I taught a tutorial in the morning and gave a talk in the afternoon. Then at FOSDEM the day after I gave a different talk. Working on three talks at once was optimistic at best, idiotic at worst. The tutorial worked out reasonably well (I was happy with the content) and the FOSDEM talk went well (this is what I was practicing at my local user groups), but the DevOps talk suffered because of it. Next time, one event per week, and a maximum of two talks (one old, one new) per event.
I did practice the talk, but just in a mirror. I practiced to make sure it ran to time (and it did, to the minute!). It’s very tough to practice content on yourself. Next time, I’ll make sure that actual people hear it, whether that’s a user group, coworkers or other speakers the day before.
At previous conferences, I’d received some feedback around my presentation style that until now I hadn’t really taken on board. I manage to stay quite calm when speaking, but this has the side effect of making my delivery quite dry and monotonous. This is even more likely if it’s a technical subject. I need to find a way to punctuate the talk and keep it engaging, whilst still keeping myself calm.
During the talk, I noticed some people leaving the room. First one, then two, then three. This was during the permissions section of the talk – a section that I wasn’t really happy with but added to pad out time. As a speaker, this shakes your confidence and it’s very hard to stay focused on the talk. This was only 10 minutes before the end of the talk – if you’re an attendee and you’re that close to the end, please stay still rather than working your way down a whole row of people. It’s very off-putting for the person trying to deliver a talk.
Finally, I received some feedback that I really don’t know how to take.
I’ve had people say that the talk needed to be more technical, and people saying that it needed to be less technical (from this, I’m taking that I need to choose either technical or non-technical and run with it. Don’t try and do both).
Another piece of feedback was that I repeated myself a little much. It was intended to be a reinforcement tool – speak, remind people of the core message, speak, remind them again. I’m not too sure how to incorporate this without the repetition.
Finally, I had someone leave a low rating as I didn’t mention their favourite tool, SaltStack. How do you deal with this as a speaker? We can’t have tried every tool, but we’re expected to lead the way in our tool choices. On one hand I’d like to find a way so that no-one can complain about not hearing the full story, but on the other hand I’d like to dismiss the comment as not constructive. Any ideas?
So, all in all, I failed. Next time I’ll commit to less so that I can focus my effort on fewer things. I’ll make sure that it’s been given at least one user group before taking it to a conference. I’ll delete any abstracts that I have that I’m not excited about delivering any more. I’ll pitch the talk at a slightly higher level – even if people aren’t too familiar with the basics at least they’ll know what to search for.
If you were in the talk, I’d love any more feedback that you may have. I’m not intending on giving this talk again unless I substantially rework it, but feedback is always useful.
PS: On the plus side, the talk that I did really want to deliver and practiced at user groups went down well at FOSDEM
Michael is a polyglot software engineer, committed to reducing complexity in systems and making them more predictable. Working with a variety of languages and tools, he shares his technical expertise to audiences all around the world at user groups and conferences. You can follow @mheap on Twitter