Jeremy Davis
Jeremy Davis
Sitecore, C# and web development
Article printed from:

Community advice for (conference) speakers

Published 01 October 2018
Updated 23 March 2020

So Sitecore Sitecore Symposium** is very nearly upon us again. And this year (for the first time!) I'll be presenting a session. [Unless it gets moved again: Day 2 (Tuesday 9th), 16:15 in Swan 2 – "Measure if you want to go faster" – A developer's introduction to improving performance by measuring your code** ]

When this year's speakers first found out that their talk abstracts had been accepted, there was a bit of discussion on the Sitecore Slack about things speakers might want to know or do. And I've been meaning to write this up for a while, because there were quite a few things I saw that were worth sharing to help anyone else who's looking forward to their first opportunity to speak...


Prepare Mike Shaw brought up the concept of the 6Ps: "Prior Planning Prevents Piss-Poor Performance". That was a phrase I first heard from the British Army many years ago – and it's a great (if slightly NSFW) reminder that whenever you're presenting anything, preparation is everything. You should have given your talk many times before you actually stand up in front of an audience...

I find that standing up and rehearsing my text properly gives me much better insight into how the text flows than just sitting and reading the notes on my slides. Phrases that are easy to read, are sometimes harder to say. So practicing the text can help the wording improve as well as your delivery.


Presenter Mike Edwards made a collection of great points about when you actually get up to speak. The first was that just reading from a script is a bad idea, as you end up giving a very stilted delivery. I'd add that you tend to lose eye contact with your audience if you do that – and eye contact is important for engaging delivery.

Secondly, having a set of points your speech needs to hit per-slide can be very useful to guide you – it's surprisingly easy to wander off topic without some notes. And thirdly Mike pointed out that when you're up on stage, pausing always seems much longer than it really is.

I would argue, however, that what's important here is not what you have written down in front of you, it's how you look and sound. There's nothing wrong with having the precise wording of a talk as "speaker notes" in Powerpoint – just as long as your delivery is not staring down at the notes, mumbling. If you feel more comfortable knowing all the words are there, but still manage to look up and have eye-contact with your audience, then I think that's perfectly fine. If fact, sometimes that "safety net" can make you feel much more comfortable about your talk.

Jeff L'Heureux mentioned you might want to exaggerate your body language, because in a bigger room some of the audience will be further away than you might be used to. But at the same time, you need to be careful that your movements don't become distracting to your audience. I know I have to think quite hard to avoid pacing about a lot when I speak. But jangling the keys in your pocket, or fiddling with your slide clicker can quickly become irritating to an audience. Moving is good – but you need to work on making it look natural, and not nervous. Which is just another aspect of preparation...

And Mike Edwards jokingly points out that there's always one smart-alec in the audience with a difficult question for you. (I'm betting it's probably Mike Reynolds at Symposium 😉) He suggested that you can often turn a difficult question around with "so how would you do it?" if you're really stuck...

Working the room

Work the room Speaking isn't all about what you have to say – interacting with your audience can help make a presentation better. Mike Edwards suggested that greeting people as they come in can help break the ice, and you can tell your audience to come and site down near the front if you're worried that the room might not fill. Jeff L'Heureux‘s said that putting gifts on some of the front seats can be a neat trick to persuade people to come down the front, if you're worried about everybody hiding at the back...


Demo Fail When you're doing technical presentations, you often need to demo things. And they're risky – we've all seen a demo go wrong on stage, haven't we?

Mike Shaw made the excellent point that your audience doesn't know what's supposed to happen, so you have more leeway than you think when you hit problems. You just have to have prepared well enough to be able to work through the issue.

The big debate here was whether you should do your demos live, or pre-recorded. Opinions vary. As they probably should, because I think this depends on your personal approach to presentations and the material you're presenting.

I'm very much on the "just record it if you can" side of that fence: First, it helps you keep to time because it will run at a predicatble speed that you can set when you're rehearsing. You can speed bits up, edit bits out or put in pauses to help your words fit around what's happening on screen in a way that's not easy to do if you're compiling and running code live on stage. The second thing is that, of course, your demos can't go wrong on stage if they're recorded. And thirdly, I find it really difficult to talk and type at the same time – so freeing myself from the need to type helps me deliver more content in my allotted slot by getting rid of any pauses in my talk caused by typing.

Akshay Sura wondered if you should admit to having a recorded demo – to which I'd say there's certainly no reason to pretend you're doing it live if you're not. Because that never ends well...

Lets pray to the demo gods

Jeff L'Heureux suggested a three level "fall back" approach of planning to do your demo live, but if it fails having a recording to fall back to. And if you're really paranoid that the recording might fail, having pictures to talk through if the video isn't working for A/V reasons. Though that sounds like three times the preparation work to me...

Meanwhile Pete Navarra reminded us all to make appropriate sacrifices to our chosen demo gods and trust our code to work on stage...


I can't speak for others, but I'm not too proud to admit that I get nervous standing up in front of an audience. And I say that as someone who's done a pile of user groups, and has performed a few plays and musicals in his time too. I think the nerves are normal. The best way to keep them under control is practice, I find – Be confident in your material.

And remember that the audience probably wanted to be there. People rarelu turn up to user groups and conferences because someone forced them to. They're interested in what you have to say, and they want you to succeed.

If you do find yourself with shaky hands, best not to pick up your bottle of water until you've calmed down a bit 😉

Non-Sitecore people do it too...

I also spoke to a friend of mine who's a long-time Microsoft MVP in the SharePoint space. He had a few interesting comments to make as well:

  • Beyond about 40 people watching, you have to give up on personal connection with the audience, because you have a sea of faces. But still engage them by scanning the room for eye contact with all areas (rather than individuals), asking for feedback via polls (hands up if you have...)
  • Is there a green room for speakers? Spend time in it. It is 100% where the important conversations are taking place
  • Make sure you go to your room before you speak and get the techies to test your connections – you will probably have to set up while the previous speaker is taking questions
  • Make sure you have a couple of water bottles on stage – still, not fizzy. Nothing worse than burping into a microphone
  • You can practice the session by recording it and then do voice to text dictation to get an easy blog post / article out of it

Are you thinking about speaking?

Excellent! There are always user groups looking for content – and there are plenty of sessions at events like SUGCON** and Symposium that need filling. And in my experience, these are great audiences to present to – we're all interested in the same stuff, and they're polite and forgiving if things don't go quite to plan.

So get working on that talk – I look forward to hearing what you have to say...

Expired links

** Some links in this page have expired. The originals are listed here, but they may no longer point to the correct content:
  1. Sitecore Symposium
  2. Day 2 (Tuesday 9th), 16:15 in Swan 2 – "Measure if you want to go faster" – A developer's introduction to improving performance by measuring your code
↑ Back to top