Skip to main content
  1. Posts/

Presenting Best Practices - Part 1

·940 words·5 mins
Chris Ayers
Author
Chris Ayers
I am a father, nerd, gamer, and speaker.

Presenting and speaking are skills that require practice to hone. I was a consultant for many years presenting to clients and customers of all levels and sizes. In addition, I started speaking and presenting at meetups, user groups, and conferences. Over the years, I practiced, I read, and I gave a lot of presentations. I’d like to share some of the learnings and best practices I’ve found in that time. I plan multiple posts, starting with Preparation. I’ll have more on slide design, and presentation tips.

Preparation
#

If you are building a presentation for a conference or work, it is tempting to just dive in and put everything on a few slides. But you need to prepare by understanding the audience and the message. Presentations should support your communication, not BE your communication. It is important to know not only WHAT you want to say, but WHO you are saying it to. It all starts with knowing your audience.

Know Your Audience
#

Who are you presenting to: Engineers, Sales, Managers, C-Suites (CEO, CIO, CTO, CFO)? Each group has a set of unique needs and wants. What questions or areas are they going to be interested in? If it is a diverse audience, you will still need to be able to communicate with all of them. You should always keep your audience in mind when building content and presenting.

Why are they here?
#

Why are they here? What do they think they’re going to get out of this presentation? An engineer might be here for a technical presentation, a salesperson might be here to learn features to sell a product, a manager might be here to help a team stay on track, the C-Suite might be here to understand costs or timelines. Showing value early keeps people engaged. One of the first things you should do is tell your audience what’s in it for them.

Familiarity with the Content
#

How familiar are they with the content? Are these team members you have been collaborating with? Are they new to the topic and here for updates? The level of familiarity will determine the use of terms, acronyms, and jargon. Using jargon with a general audience can cause confusion and create a barrier to communication. If you use jargon, it can be helpful to define it. If people are having difficulty following the terms and jargon, they will lose interest and stop listening.

What is the value?
#

What is the value? Is this a collaboration meeting with Engineers working on an issue or problem? A status report to management on the progress of implementation? What are the attendees looking to get from this presentation? The core message might be the same for different audiences, but how you present that message and the value the audience gets from it might be different.

Know your message
#

So, you know who you are presenting to and a high-level idea of what you are trying to convey. Now you need to know your message in depth. What are the points you are trying to get across?

Intent
#

What is the intent of the presentation? Is it to inform, to persuade, or to instruct the audience? Each of these types of presentations has a different flow, style, and outcome.

Informational
#

For instance, an informational presentation aims to inform the audience about a specific topic. Think of it as a written report presented verbally. In business, these are the most common types of presentations. The goal is to share information, with an emphasis on clear and concise communication. You should limit your presentation to 3-4 key messages. Any more than that can be too much information and overload the audience.

Persuasive
#

A persuasive speech aims to move, motivate, or change the audience. You want the audience to perform a certain action or convince them to adopt the belief or opinion of the speaker. This might be a sales pitch, a recommendation for an architectural approach, or adopting a new practice. Persuasion has been studied by experts and they have observed what works and what doesn’t.

Instructional
#

If it is an instructional presentation, how much detail do you need to put into the presentation? A fun example is this great YouTube video, Exact Instructions Challenge - THIS is why my kids hate me. Josh Darnit, where a father is trying to follow the exact instructions for how to make a peanut butter and jelly sandwich. Finding the right level of detail in the instructions is important and knowing your audience can help.

Level of Content
#

What is the level of content? This can be difficult because it is hard to know what others know. Let’s say you are presenting to beginner engineers. The Curse of Knowledge means that you might struggle, because you intuitively assume that things that are obvious to you are also obvious to the engineers. Finding that right balance is important.

Conclusion
#

I realize this post was light in specifics, but knowing your audience is the #1 best practice for presenting. If you know the audience, the next recommendation is knowing your goal or intent of the presentation. These might seem like basic recommendations, but they can turn an average presenter into a great presenter.

Until Next Time.

Recommendations
#

I would like to give a few recommendations that will go deeper into many of these topics. These books are great additions for thinking about not only content, but how to present it.

Related

Presenting with VS Code - Screencast mode

·243 words·2 mins
I have been starting to speak and present a lot more, and was looking into great tools like Carnac and KeyPosé. But I just found out today about a feature I didn’t know existed inside Visual Studio Code, Screencast mode. This was introduced in January 2019. How did I miss it? To enable and use Screencast mode, Open the command palette, Ctrl + Shift + P. When first enabled, Screencast Mode is not what I wanted. It shows EVERY keypress. It also shows a little higher on the screen that I prefer. It also puts a little red circle everywhere I click the mouse, which is nice. Let’s configure it and see if we can clean up some of that. Open the command palette again (Ctrl + Shift + P) and go to the user settings.

Shared Focus - Using The First Way with DevOps

·366 words·2 mins
A common issue I see when discussing DevOps with teams or organizations is the presence of Organizational Silos. Organizational Silos are made up of all types of people. Sometimes its a job type, like developers, qa, or infrastructure. Sometimes its a department, like accounting, or hr. Whatever the composition of these silos, they usually impact organizational performance and the ability to deliver value to end users. This happens over time, with members of the silo identifying with each other, viewing those not in the silos as outsiders. Depending on the business, the silos can lose trust in the business overall and tighten ranks around their silo. The silos can turn into walled fortresses. When the silos get in the way, the silos are more focused on their own success than the success of the organization.

Some Tools to Help Present Git

·416 words·2 mins
I’m presenting soon on Advanced Git. I feel a lot of Developers and DevOps engineers know enough git to the job, but sometimes that’s it. I want to help people be more comfortable with the git command-line, and help alleviate some fear or hesitation in dealing with git edge cases. While researching things, I came across a few neat tools I’m using to help describe things.

Dependency Injection, Architecture, and Testing

This blog was posted as part of the Third Annual C# Advent. Make sure to check out everyone else’s work when you’re done here Dependency Injection, or DI, is a Software Architecture Design Pattern. DI is something that comes up during discussions on SOLID, IoC (Inversion of Control), testing, and refactoring. I want to speak on each of these briefly because DI touches all of these. But before I really dive into things, I want to define what a dependency is. A dependency is any object that another object requires. So all of those classes, services, and libraries that we use to build our applications are dependencies.

RESTful API Versioning

·505 words·3 mins
I’ve been a developer for a long time, writing APIs and clients to consume them. When an API is around long enough, it needs to change. I’ve versioned APIs in the past using a number of different techniques. Some successful, some painful. Now I realize this discussion is like the VI/Emacs conflict, the Tab/Space wars, and the Spanish Inquisition, but it is a good topic to look at. There are a few main styles when it comes to API versioning: