Secrets to great technical presentations

 
RECENT POSTS
WINDOWS AZURE BLOG RSS
http://blogs.msdn.com/b/windowsazure/archive/tags/windows+azure//
WORLD MAPS
MSDN Blogs > Bruno Terkaly - Developer Evangelist - bterkaly@microsoft.com > Secrets to great technical presentations

Secrets to great technical presentations

Rate This
27 Jul 2012 4:42 PM
  • Comments 2
From time to time I get asked how someone might deliver a session successfully for 1 hour.
001
  1. I get the opportunity to see many, many presentations. I attend and host many user groups.
  2. I consider presentations to be more of an art form than anything else.
  3. The presenter must wear many hats.
    1. A presenter is part politician, part psychologist, part technologist, part actor, part comedian (but not everyone),
  4. It is amazing to me how the skill of the presenter can vary as much as it does. I'm sure many of you have seen audiences like the "nerd" photo above.
  5. You can never be all things to all people, but you can be a lot of things to a lot of people, which is really the goal. Authenticity is critical, however. If you are satisfying half the typical audience, you need to expand the view of yourself.
  6. Regardless, there are basic guidelines that all presenters can follow for better success.
  7. Some have suggested the great presenters are born, not created. While some of that may be true, I believe you can take a mediocre presenter and make him or her great.
  8. I was an on-the-road instructor for many years, out of town at least 70% of the time as a field engineer.  I have taught many languages, SDKs, Frameworks, APIs, runtimes, Operating Systems and have been in the technical field for over twenty years.  If you've traveled as much as I have, you'll enjoy Johnny Cash's "I've been everywhere, man." http://www.youtube.com/watch?v=ov4epAJRPMw.
  9. I think the secret of my success as a presenter is always to question how it can be better – if I'm the best that I can be. I'm very consistent in my quality. Although there are times a presentation may really stand out as awesome, there have been some cases of mediocre performance. (And maybe once or twice I have totally embarrassed myself.)
    1. There have been many evenings, where I have stayed up late to perfect my PowerPoint deck, due to audience feedback or to things I have just noticed myself after having just delivering the content to a live audience.
    2. Sometimes excellent questions come up from audience members, and those should be incorporated into your presentation.  Evaluations and feedback absolutely must be taken into consideration.  You are never really done.
  10. I want to be 95 years old saying, "I was a good presenter when I was 85, but now that I'm 95 I've learned some more tricks to being better."
  11. This post is going back to my roots, but it is also about the present. If this post is well articulated, you will be able to deliver technical content to a live audience.
  12. In a future post, I'll walk through a concrete example of a technical presentation.
  13. This post is specifically about how someone might conduct an introductory lesson on using some technology.
The 3 Parts to Great Presentations
002
  1. Part 1
    • What makes an effective presentation?
    • It is about understanding the value proposition of your presentation and the audience you are addressing.
    • In a nutshell, cater to your "audience needs". When I talk about needs, it is much more than a technical feature list.
      • A great presenter can motivate and "empower an audience" to be confident, inspired.
      • A great presenter inspires an attendee to walk away with a desire to try the presented technology.
    • The problem is often not knowing your audience or being able to adapt to it.
      • As an example I had done a couple of presentations at Cloud Intelligence Conferences.
      • The first audience that attended was developers and I gave a very code-centric presentation.
        • The "audience loved it". It got a higher score than even the reception in terms of audience satisfaction.
      • A year later, expecting the same audience, I did a similar talk. But it bombed. None of the attendees were developers.
        • I wasn't ready to change gears.
          • I should have spoken more high level about cost, competitive advantages, the unique power of the Azure platform in terms of capabilities and features.
    • A presenter needs to be careful about being overly optimistic about the value proposition.
      • I generally state some limitations. This makes me appear balanced.
    • In a nutshell, the presenter needs to ask themselves a few questions:
      • What is the reason someone should care about my presentation?
      • Who is in my audience and what are their specific needs?
  2. Part 2
    • Content is everything. It is almost everything. A great chef can make a meal out of what is in the refrigerator. Well, I'm the type of chef that needs to work on it for a while.  I must work hard to prepare. I must rehearse. I'm dumb and it takes me a while to prepare properly.
    • But when I'm up there, I'm on fire. My demos just work. Unfortunately, audiences are always disappointed if demos don't work when you give them. Whoops, I just jinxed myself. I'm getting too confident. Humility is your friend. Don't forget that. An audience never likes arrogance.
    • There are many questions you can ask yourself. Here are some high level questions I ask myself:
      • How much PowerPoint?
      • How much code?
      • Other media?
    • Two person presentations can really rock and roll.
      • My friend Ricardo Villalobos and I have done a few presentations together. They were very popular because of the interaction Ricardo and I had on stage.
    • The presenter "needs to know his/her audience" and to what extent certain topics should be covered.
      • These types of attendees are different - Developers, Testers, CxO, Architect, Entrepreneur. They each have their own idea about what they want to see:
        • Economics (i.e., financially efficient cloud architectures)
        • Tooling, IDEs, SDKs
        • Competitive Advantage
        • Architectural Flexibility
        • Time to market
        • Enterprise/Integration, Mobile and Tablet Support
        • Adherence to Open Standards
        • etc
    • There are many aspects to the concept of content and the presenter and how those two pieces effectively fit together. I'll give you some specific guidelines I follow a little later in this post.
      • As a Developer Evangelist working at Microsoft, my job revolves around PowerPoint and live code demos, typically with Visual Studio, but including other IDEs.
  3. Part 3
    • The presenter should clearly define how events will take place. I like to indicate:
      • How many slides and how much code will get covered.
      • The presenter should think about throwing in tidbits about value proposition during the code demos.
      • What time we will finish and whether there will be time for questions, hand-labs, and giveaways
    • Anticipate that if there are any hands-on labs involved, that unprepared attendees won't physically be able to do all the labs, but they will be able to review the PowerPoint and hands-on lab guide.
      • Labs can usually be tripled in length of time if the presenter is to give EVERYONE a chance to complete.
      • An important part of setting expectations is being realistic. Avoid disappointing attendees by overpromising. Highlight the value of the available content for later follow-through.
The value proposition depends on the person in the audience.
003
  1. I think it helps for the presenter to assume these four types are in his/her audience. The big question is how much of each.
  2. It always helps to take informal polls by asking attendees to raise their hands to certain questions.
  3. Some situations can be hard to recover from.
    • If you are prepared to give a code oriented demo and there are no developers in the audience, it will be difficult to make the audience happy. It is very, very difficult to change your presentation at the last minute.
  4. There are typically 5 audience types that I encounter:
    • Developer
      • Includes:
        • Working as a full time developer as a:
          • Consultant
          • Employee at a company (any size, including startup)
      • Interests
        • Likes code, probably interested in productive frameworks, support for advanced language constructs. Wants to see some code. Preferably the presenter can speak to specific code snippets, compile them and run them. Projects from the very beginning work best (File/New/Project).
    • Entrepreneur
      • Includes:
        • Individuals in a startup.
          • Founders
          • Venture Capitalists
      • Interests
        • Fast time to market with minimum development investment and the ability to attract talented developers, and minimum upfront investment.
    • CxO
      • Includes:
        • Chief Technology Officers (CTO)
        • Chief Information Officers (CIO)
        • CEO Technology Companies (CEO)
      • Interests
        • Cost effective, competitive advantage, long-term investment. In general, CxOs play a key role is helping technologists understand what the business needs and helping the business understand what the technology can do for them.
          • CTOs concerned with competitive advantage, flexibility, the basis of a company platform. Runs engineering teams and is top architect. Looking for creative and innovative solutions. CTO may be interested in good tools for external products.
          • CIOs are more concerned with infrastructure aligned with business priorities. Also focused on operational efficiencies. Typically focused on internal teams at a company. CIOs want to know about processes, reliable systems.
    • Software Architects
      • Interests
        • Spearheads software development activities. Concerned with full lifecycle of software, all the way from designing the frameworks and writing the code, all the way to testing it, deploying it, and versioning it. Architects are also concerned with the continuous process of managing the life of an application through governance, development and maintenance. Architects often have a business view of the process, looking for efficiencies in software engineering made possible by tools that facilitate and integrate requirements management, architecture, coding, testing, tracking, and release management.
    • Program Manager
      • Interests
        • Manages teams from all different parts of the business to ensure a successful product
        • In technology companies, the program manager ensures that cross-project work efforts are communicating well and sharing common goals. From the business point of view, the program manager may evaluate business feasibility of a certain effort.
        • The program manager is very concerned with the interdependency between the projects, being to communicate the overall vision.
  5. Be sure your audience understands the value proposition of the technology
    • What is the reason someone should care?
    • What types of advantages are there?
Balance is Key
004
  1. Too much of any one thing is bad. Showing too many slides are too much code for too long a time is a big turnoff to audiences.
  2. Most technical presentations involve some combination of demos and of PowerPoint.
  3. Too much PowerPoint is boring.
  4. Too much code loses the big picture.
  5. A combination is the best approach.
  6. I sometimes make a rule:
    • No more than 5 - 7 slides before showing something else
    • I try to seamlessly travel between my demos and my PowerPoint
    • I have created my own custom tooling to manage code snippets. My custom tooling enables me to run things in the background from the keyboard without the audience seeing any physical evidence on the screen. This minimizes distractions. Nothing is more annoying than seeing someone copy and paste or even worst type been really slowly to the keyboard. Typing text from scratch is OK but only if it's done a little bit.
It's about Content - Ok, the presenter too
005
  1. As stated earlier, content is always a function of the audience and what the audience needs.
  2. The presenter needs to factor in each of these personas.
  3. The developer is usually interested in much of what you see above. Developers like looking at code, at powerful tooling, mobile and cloud technologies. They have some interest in staying relevant. Focus on providing core skills and staying relevant.
  4. The entrepreneur wants to get to market quickly and economically. Venture firms usually expect a cloud story and would find it hard to justify and capital expenditure on hardware. Microsoft offers BizSpark for entrepreneurs that allows them free access to Microsoft technologies.
  5. The CxO is interested in almost all of these things but perhaps takes a more pragmatic business perspective relative to the mad scientist developer types. There are strategy decisions to make, economic predictions on the cost of engineering and IT.
  6. The architect wants an orderly process and is concerned about such ALM-related technologies as version control, debugging, integration, continuous deployment, agile development practices, full fidelity frameworks, SDKs, and tooling and so on.
Setting Expectations
006
  1. Be clear, state your goals:
    • State what you are going to cover up front
    • State what the audience will walk away with
    • State what you expect of the audience
      • Being setup, getting setup
      • What can be learned if computer not setup correctly during lab time
        • There will be attendees that are not close to being setup.
  2. Discuss Schedule for next hour
    • Break into parts (slides, code, hands-on, questions)
  3. Before starting the labs, do the following:
    • Tell the audience that the setup requirements are significant and can take several hours to perform them from scratch.
  4. In general most developers have some of these items already installed
  5. But there will invariably be those that show up with the wrong hardware and missing software.
  6. The presenter should try to bring some USB drives for the biggest downloads that don't require a license.
  7. Throughout the allotted time, the presenter needs to keep track of time and keep the modules flowing on schedule. Note from the diagram above it is down to the minute.
Nobody sits around during lab time
007
  1. This slide is key because it anticipates that there will be attendees that are not setup.
  2. There is work to do and things to learn, even if an attendee is not properly setup. Audience satisfaction will go down if there are a lot people not doing anything because they weren't setup. The presenter or proctor must be a sheep dog, making sure everyone is doing something.
  3. The presenter should know that given time constraints, not all of the modules can be completed. The attendees need to be told what is realistic.
  4. One thing is for sure - there is no excuse for an attendee to be sitting there twirling their thumbs. The presenter should provide some hyperlinks to read, some simple tasks for attendees to pursue, regardless of preparation level. Not using these words, the concept I get across is, "Just because you didn't setup is no excuse, there is work to do, things to learn for EVERYONE."
Incite Action
008
  1. Provide the audience actionable follow-up.
  2. Provide such things as blogs and related web resources.
  3. As a courtesy please provide your contact information.
  4. Invite me to come speak about cloud computing so I can put my money where my mouth is.
  5. Feel free to e-mail me with your recommendations about successful presentations. Tell me what works for you and I will add it. Contact me here: bterkaly@microsoft.com.
   lahxjo2d
 

Comments
  • 30 Jul 2012 7:35 PM

    Your list is the meat of excellent presentations. Like you, I find that the most powerful talks  start with “remember the pain” - that process of walking the audience through the cases and scenarios your talk will help them avoid or resolve. Then, “how are they going to be different” is the final (most important?) part. It’s hard to change someone through a talk, but not impossible. Think differently. Be informed. Realize something. Whatever we can do! Any talk that doesn’t lead with the “pain” doesn’t open the right doors (and minds). And, I think, any talk that doesn’t leave the listener changed was just passing time. // Jerry Nixon (http://jerrynixon.com)

  • Bruno
    30 Jul 2012 10:27 PM

    I agree that appealing to pain is a great way to look at it. Many of us go to technical events hoping to lessen the pain about some aspect of our job, to come back to work to try something new, to move the needle forward. Thanks for reading, Jerry!

Page 1 of 1 (2 items)
Leave a Comment
  • Please add 8 and 7 and type the answer here:
  • Post