Session’s Are a Specific Length For A Reason

Nothing irks me more when I walk into my session room than the prior presenter still standing up there doing his thing eating into my 15 minutes of prep/setup time. Conferences have fixed length sessions for a reason. So that the audience knows how long the session will be, so that the presenter knows how much material to prepare, and so that the speaker knows how long they have before their session to get setup.

When a presenter runs over their time into the next presenters setup time this shows that the presenter didn’t have a good enough grasp of their session to set the right cadence, and they didn’t have good time management skills to know when they should have skipped some slides so that they’d finish on time.

Vendors are the worst at this at their lunch sessions. Lunch sessions at events like SQL Saturday’s typically don’t have much prep time between the lunch session and next session, so when the vendor runs over they are eating directly into the next presenters time.

Giving a session which runs short isn’t good either. As presenters we like to pad a sessions with 5-10 minutes of questions that we think are going to show up during the session. But when they don’t we need to have enough material to fill the time slot fully. After all that’s what the audience came to see. If you’ve got a 60 minute session slot, and 45 minutes of material and no questions, you’d better have some extra material to fill the extra 15 minutes with. When I was a TechEd Europe this year I wondered up to my session room very early, while the prior speaker should have still been presenting. I figured that I’d stand at the back and catch the last few minutes of his session before I got setup for mine. However when I got there his session was already done, with him standing at the front with a small group of people asking him questions. He finished easily 15 minutes early (I’m guessing).

Time management is hard. Especially when giving a presentation to a group, as you may not have a clock running to tell you how much time you have left. But there’s apps for your phone, or you can use the timer in PowerPoint (as long as you don’t close PowerPoint to do a demo), or a room monitor who can give you a signal at 5,10,15 minutes before you end, etc. There’s lots of ways to fix the problem so that the attendees get the session of the length that they are expecting while still getting the information across to them.


Contact the Author | Contact DCAC

Never Tempt the Demo Gods

Demos are one of the most fun parts of presenting, and one of the riskiest. This is because the demo gods have two options. They can smile upon you and give you a perfect demo, or they can piss all over you and your demo can crash and burn. How you handle those demo failures shows how good of a speaker you really are.

If you are able to recovery from the failure and fix the problem without anyone noticing the problem, you are a master speaker. If you point out the failure, then work around it, you’re pretty good (this is where I usually fall in the demo failure recovery event). If you stumble from the failure and get stuck and can’t continue, you need to practice your demos more (or not use demos if you can get away from it).

There’s a few ways to avoid demo failure. The easiest is to avoid demos. If possible stick to screenshots, they can’t fail you and you don’t have to drop out of the PowerPoint to get to them. Many demos out there don’t really need to be demos. If all you are doing is showing code, and the output I can do that with screenshots. Or at the very least have screenshots handy in a hidden slide so that if the demo fails you can toss them up on the screen to show how it’s supposed to work.

Another way to avoid demo failure, is to not type in the demo. People laugh when I (and others) say to never type in a demo, but we aren’t kidding. When you are on stage presenting you are nervous and odds are you’ll hit a key wrong and get a lovely error on the screen when you shouldn’t. Have all the code you’ll be using pre-written (and tested) so you can just open it and show it, then run it. The same goes for T-SQL scripts, PowerShell scripts, etc. Just open the script, show it, and run it. (And when showing PowerShell scripts don’t use the PowerShell prompt, use the damn ISE so the audience can read the screen.)

My final suggestion is to use something like DemoMate to record the demos ahead of time. This way if there’s a demo failure you can show the recorded version of it working. Now don’t plan on just using DemoMate and never showing an actual demo because that won’t fly with your audience. But if the demo blows up you need a way to get your point across.


Contact the Author | Contact DCAC


Globally Recognized Expertise

As Microsoft MVP’s and Partners as well as VMware experts, we are summoned by companies all over the world to fine-tune and problem-solve the most difficult architecture, infrastructure and network challenges.

And sometimes we’re asked to share what we did, at events like Microsoft’s PASS Summit 2015.

Awards & Certifications

Microsoft Partner   Denny Cherry & Associates Consulting LLC BBB Business Review    Microsoft MVP    Microsoft Certified Master VMWare vExpert
INC 5000 Award for 2020    American Business Awards People's Choice    American Business Awards Gold Award    American Business Awards Silver Award    FT Americas’ Fastest Growing Companies 2020   
Best Full-Service Cloud Technology Consulting Company       Insights Sccess Award    Technology Headlines Award    Golden Bridge Gold Award    CIO Review Top 20 Azure Solutions Providers