My thoughts on Connect 14 – What makes a good presentation?

I wanted to write down some thoughts and ideas, notes almost, after watching the IBM Connect 2014 technical presentations.

Ultimately what I want to understand and be able to execute myself is – What makes a good presenter/presentation?

Let’s ignore the content for the moment. Last week I attended sessions where I was interested in the content but the delivery was poor. I also went to presentations where the content didn’t interest me but the presentation kept my attention. Figuring out how to do a good presentation is very important to me. I would love to get feedback (comments below) on what other people think as I want to learn and I expect others do to.

This is a necessary life skill as a consultant /project lead – you need to be able to capture the attention of your audience even if they do not believe they are necessarily interested in what you have to say.

So what makes a bad presentation?

This is much easier to answer and the opposite is not necessarily true.

  • Reading from the slides
    • Absolute #1 presenter sin in my book. It shows a lack of belief/knowledge in what you are talking about. It is very boring to watch you read from a slide when I can do it myself. It demonstrates very quickly there is no point in me being here as I can get the slides later.
  • Too much code on the screen
    • see above
  • Spending too long explaining abstract concepts in a technical manner
    • On the one hand if this is a technical session, I understand, but if lose your audience at any time during your 10 minute rant about how awesome your code is, they are lost and you have failed.
    • see above
  • A bad abstract
    • Too often an unintentional bait and switch can really hurt a presenter. If your abstract claims that you are going to speak about jQuery then don’t spend 10 minutes bashing Dojo. Stick to the topic. Ensure that you talk to your abstract and don’t include large,ย previously declared, sections out of the blue; surprising attendees.
    • Many “non-Best Practices” sessions at Connect have abstracts that are vague and non-committal on the subject matter. What this then means is that attendees come to the session expecting one thing and don’t get it. Bad score – regardless of content if it is not why the attendee came you get a bad grade, people walk out, general feeling in the room is lower, bad scores.
  • No demonstrations
    • What do we all enjoy most about the OGS – demos
    • What do we hate most about the OGS – no demos
    • It applies to all of us as well
  • Don’t insult your audience
    • There is no point in going through something which has been discussed frequently on blogs – one slide – go read these links later, is all you need. We are here to learn about new things and be excited – don’t bore us with things we either know or can be looked up easily. (see know your audience and bad abstract)
    • Explaining to me how you make a REST Service work is not necessary when your talk is about something which consumes the REST service – tell me more about the something advertised and tell me where to go to find out more about REST services.

So what makes a good presentation?

  • Structure
    • Everything you create must have a start, a middle and an end. Presentations are no exception.
    • Use slides to break up the flow based on the agenda. This was one of the best things about the template slide decks for this connect14 – purposeful section slides.
    • There is no reason why you cannot break the session up into many sections. But they must make sense, there must be a segue from one to the next and then must flow well. It also forces you the presenter to stay on the pre-planned path and not deviate too much
  • Leave your audience wanting more
    • If everyone walks out going “huh well I guess that is it then” you fail. If they walk out taking notes from your slides because they want to look up the demos or downloads later – then you have won.
    • You do not have to beat a dead horse to get your point across (see less is more below)
  • Practice
    • The only way you get better is practice, analyze, learn from your mistakes
    • Offer to speak at LUGs – they are almost all technical and with friends – you really can’t go wrong !
  • Know your audience
    • Make sure your abstract makes clear what the audience should expect and what level the talk is aimed at. This will ensure a better reception and better transfer of knowledge.
    • For example: I know a thing or two about XPages but I don’t have the faintest clue about what OSGI plugins. If I attended a session about the Extension Library I would be lost in a heartbeat if the first 15 minutes were spent explaining how the ExtLib OSGI plugin concept worked. If OSGI plugins were not mentioned in the abstract I would be scoring low.
    • Equally don’t insult them all by pitching too low either.
  • Vary your presentation method frequently
    • Don’t do the same thing slide after slide after slide.
      • Use visuals
      • Use metaphors
      • Use humor
      • Use demonstrations inter-dispersed with the rest of the content
  • Talk to the audience don’t lecture them
    • A presentation which feels like a conversation is much easier to comprehend than one which feels like a lecture.
    • It is OK to gloss over something – don’t feel like you have to explain everything. You don’t have time so explain the absolute essentials and then stick to generalizations because you don’t have time otherwise (unless this is a show and tell session)
    • Remember – your audience cannot keep up with you and take copious notes in the session. This is not a lecture. This should excite the audience to the possibilities of learning something new and it is not unreasonable for them to go away and do some research themselves. Give the audience the knowledge and the tools (and even code to download) to help themselves. They cannot possibly leave the session being an expert so don’t try and make them one.
  • Less is more
    • Attendees will be happier to finish a few minutes earlier than have to run to their next session. Don’t overfill the slide deck (see making them want more)

And I could go on and on. But please comment and tell me what you think is good and or bad as presentation skills – it is good for all of us to learn from each other ๐Ÿ™‚

Advertisements

18 thoughts on “My thoughts on Connect 14 – What makes a good presentation?

  1. Good points (and good bad points). A couple of things I would add:
    1. For S & T or demos, show the end result first. You may get a kick out of the ‘big surprise’ at the end of creating something but your audience will understand things you do better as they have a point of reference.
    2. Explicitly remind the audience what level the presentation is pitched. This gives anyone the chance to leave early and not be baffled/bored later.
    3. Personally I hate slideshare!!! You are correct when you say ‘do not read off the slides’ and that they are summary points but too many times I have left Slideshare scratching my head as I have no context as to what I’m looking at. Presenters should prepare a blog or video (even better) explaining the points (or a copy of the presentation) and list it as a reference at the end. This is not overly difficult and for Connect I’m sure Dave Leedy (NotesIn9) would welcome most content (cheap plug lol) for free deployment on his site.

    • 3. I’ve read a few “How to prevent ‘Death by PowerPoint'” articles. One point they all usually make is that if you can use your deck as documentation, you’ve committed Death by PowerPoint. A corollary is that if you put the deck on slideshare and people find it very useful on its own, you’ve committed Death by Powerpoint.

      In comment #4 below, David wrote ” 400 slides is too many”. Actually 40 is probably too many.

      • Great comment Timothy- I’m stealing that for my next presentation ๐Ÿ™‚ (Death by powerpoint/Slideshare).

        As always there are exceptions to the rule and I once saw JB Rainsburger (‘JUnit Recipes’ author) have at least 400 slides in a presentation. There were no words or code and each was a full sized image that he changed every few seconds. The story was compelling (somewhat because this was a different approach to presenting) and he got a standing ovation.
        In 10 years of presenting at conferences I would NEVER do this lol, but hey, that’s why he makes the big bucks ๐Ÿ™‚ He told me he had done a LOT of prep and practice and I still remember this 7 years after the show…. so there’s a challenge for someone ๐Ÿ˜‰
        The problem with Connect is that IBM require a slide for every code change so I’ve had to submit several hundred before. However, that does not mean they need to be used in the actual presentation (people forget that sometimes). I ended up using only 15 slides out of c.280.

  2. What I appreciate a lot is that presenters upload their presentation ahead of time. If you find 3 sessions of interest at the same time then you can quickly scan if they meet your interest and make a decision on that.

    You as presenter are less faced with the fact that people run away after 5 minutes since they believe they should be sitting in another room. I assume you like to present to people who are really interested in your presentation instead of standing in front of people who are really just killing their time.

    • Thanks Patrick ๐Ÿ™‚

      I think a great abstract goes a long way towards negating the wrong attendees. Writing a good abstract is a whole different article though. I would not post the slides before a presentation but I guess that is personal choice. As Rich said slides on their own without presenter context can be hard to understand.

  3. Nice job, Mark. The inimitable Wes Morgan tweeted a bunch of presentation tips leading up to Connect 14, if I remember correctly, so check out his timeline. Also, it’s “segue” not “segway” I think you mean (Structure, bullet 3).

  4. Great post, Mark.

    As a code monkey, I do want to see code in the sessions on development – probably considerably more than you do. The most important thing there is, it must be in a readable font – very large and black-on-white is my preference. In one session, the audience interrupted to ask the presenter to make his code more readable. He improved that one, then switched screens and it was unreadable again. I’d suggest to presenters that if you love customizing your fonts that when you present you go back to the defaults. I’d then increase size so that no more than 10-15 lines will show on the screen – any more code than that and it’s simply too much detail.

    In regards to links, please don’t explain every link to me. If you have five, tell me about the most important one and trust me to figure out the rest.

    I’d like to emphasize your point on the number of slides. 400 slides is too many and may lead to reading the slides to the audience if you show them all. If you have 400 slides and you don’t show them all, you put too darn many in the deck. One group habitually puts far more slides in their deck than they can cover and it results in a choppy presentation as they jump slides. I’d much rather have them cut down the number of slides so they don’t have to skip.

    Practice, practice, practice. If you put up a slide and look at it to figure out what you’re supposed to say, I’m going to be disappointed and you’re going to waste our precious time.

    Learn to modulate your voice when you speak. Some speakers deliver their talks in a near monotone, with no enthusiasm or emphasis. I’ve fallen asleep in such sessions and avoid those speakers, regardless of content. I’d suggest that if you’re going to present, take a public speaking class. It’s money well spent.

    • Excellent points monkey ๐Ÿ™‚

      At a LUG which is much more technical I think a Code review is more appropriate – at Connect though the audience is too diverse for a significant review.

  5. Good points!

    Apart from having the slides readliy available after the presentation, having an example application ready is a great plus, also. So, if the session is technical, the example app makes perfect sense. Thanks for the Ext JS grid app! ๐Ÿ™‚

    Mat Newman’s first session on IBM Worklight was considered “bad”, since he basically read from the slides. He was going to demo, but since his laptop didn’t work with the presentation machines, it made it difficult for him. By going through the slides, he was still able to give an introduction to Worklight, which was the title to his session, anyways. In your session, what if the website was down that was showing the kewl Ext JS grid app? Or, if you wanted to show it in Designer, and that didn’t work? As a presenter, a “back up plan” is a good thing, too, methinks, in cases such as Mat’s.

    Another caveat is not to be enticed by a fancy titled presentation. For example, the “Uno! Deux! Three!” localization session from your cohorts looked like it was taken mostly from the help. In our case here all internal websites have to be both in English and French, and all public ones in six languages: English, French, Spanish, Russian, Chinese and Arabic. We have translators available in our building for these websites, but since most applications are living, breathing, evolving entities, asking them to update the properties files and rebuilding the code each time is impractical. We’ll find another way to do it, but once we do, I’ll let you guys know. Perhaps a new “Uno! Deux! Three! ั‡ะตั‚ั‹ั€ะต! Liรน” session next year? ๐Ÿ˜‰

    • Yes backup plan – in my Worklight session we had a prerecorded demo just fro that very purpose. In the Ext JS session I ran everything locally off the laptop server. It was also replicated to an external site just in case (the demo.xomino.com site).

      I also forgot to add to the list – don’t code on stage – boring to watch – if you MUST use code snippets then write them before hand in notepad and copy/paste them

      • If you want to see a flustered and angry Mat trying to stay calm and stumbling through a session that should have been great, just watch the replay of Worklight 1 ๐Ÿ˜‰
        Very fair comments Steve, the session was bad. I apologise. Even with the 3rd machine on stage, I should have thought to connect a browser to my demo site and walk through the code samples, that would have – at least – demonstrated how Worklight can interact with DDS. Next year I’ll have recorded demos on video files, just in case … Sorry!

        Marky – The security stuff is all handled within the app, and the credentiials passed to the server on session initiation. There’s a section within the project called “Server”, which contains a custom login form and scripts you can modify to change login, connectivity settings and functions. If I had had an Eclipse IDE I would have shown you where to configure those options. My answer to your question was as bad as the session! ๐Ÿ˜ฆ

  6. Nothing to add, this is just a great summary of “how doing a good/bad presentation” (incl. the comments) – bookmaked it ๐Ÿ˜€
    My point of view is: you can do a good presentation if you gathered experience in doing this, hosting workshops and trainings (where everything can f***ed up when you DO something) and looking what others do good and bad. I think there is no “good or bad”, no “right or wrong”. It depends on the event you’re speaking.

  7. I have done everything from heavy slides, to no slides. Pictures to single word texts. Moving images to flow.

    Each session is unique but being yourself is key to me as an attendee.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s