Who is the hero of your technical presentation?

As technical presenters, we often forget the audience even exists. As engineers with a reputation for delivering “data dump” presentations, we focus on our slides, our agenda, our detailed subject matter and our extensive experience. And when it’s all about us, it can’t be about the audience.

Read More

Is Your Technical Presentation Actually a Document?

As engineers, our technical mindset takes us down a path that creates dense, fact-based, detailed “reports” that we call presentations. This happens for several reasons.

First, facts are our comfort zone. As engineers, we swim in deep technical details required to debug problems and design innovative solutions. Unless we have a burning desire or motivation to focus on great communication skills, we stay in our comfort zone, and this is reflected in how we create presentations.

The second reason is psychological. We want people to notice how sharp we really are and display the full orchestra of what is going on in our heads. Meanwhile, the audience is asking, “What’s in it for me?” or “Why should I sit here and listen to you?”

We may indeed impress our audience, and their takeaway is, “Wow, that presenter is really smart.” The unintended consequence is that the audience also thinks, “I am not smart enough to understand this information.” The presentation is a lost opportunity for connecting with, enabling, persuading and engaging the audience.

A third reason may be that you have never been taught how to craft and deliver compelling technical presentations. Typically, high-tech companies do not spend much money on developing the communication skills of their engineers. So engineers continue to create “data dumps” that result in our bad reputation as “death by Powerpoint” presenters.

So, we do what seems natural—overkill with facts, block diagrams, spreadsheets, bits, registers, TLAs (three letter acronyms)—rather than transforming information into meaning. What we really create are documents rather than presentations. 

Look at your current technical presentation. Does it resemble a document or a report that is highly structured, filled with facts (at 10-point type or smaller) and overly complex diagrams that, while accurate, would blow the minds of the audience who don’t have your technical expertise? As one expert once said, “If you are going to create a document, send a PDF and cancel the meeting.”


True presentations fall on a continuum between a document and a movie, which entertains, emotes and draws the audience into an experience. A presentation has both key information as well as emotional elements such as stories, analogies and surprises that help the audience both feel and experience.

But how do you create a presentation instead of a document?  It’s simply a matter of learning a better way. Our “Audience-Focused Technical Presentations” workshop breaks the mold of “data dump” presentations and teaches engineers a new model that transforms their approach to technical presentations. Just like design, debug and engineering skills, the skills taught in this workshop can be learned, practiced and even mastered. 

Imagine going to a technical conference where each presenter is memorable, engaging and provides useful, relevant information. Imagine giving an internal presentation in which your team members understand you well enough to create new ideas and innovations from what they learn. A presentation that is meaningful for the audience will accomplish this. We can teach you how.

How to assess your presentation skills


Most engineers are the best at what they do. Right? Well, when it comes to being subject matter experts, yes. But when it comes to technical presentations, usually not. You might think, “Well, my presentations are fine. After all, my reviews are always at least 4 stars.” Well, smile sheets are usually dead wrong (that’s another blog post). You need a better way of assessing yourself or others.

So, as one engineer asked us, “How do I know if I really need help?” While we could give you a formal rubric for outstanding presentations, it’s actually easier to assess from the opposite or inverse standpoint. 

Let’s start with a simple quiz. Just 20 questions. Think about the last 3-4 presentations you have either given or heard (if you are assessing others). Answer “yes” or “no” to the questions below. Be honest!

Did the presenter…

  • Prior to the presentation, perform a thorough needs analysis by interviewing at least ten people who represented their target audience?
  • Refuse to open Powerpoint (or any other presentation software) until after the research, “big idea,” mind-mapping and storyboarding were complete?
  • Spend at least 15x their allotted time slot (i.e. 15 hours for a one-hour presentation) preparing their presentation?
  • Conduct a practice or beta run of their material in front of a representative audience and then use that feedback to modify their presentation?
  • Leave at least 33% of the allotted presentation time for Q&A? So, for a 60-minute time slot, were 20 minutes allotted for dialogue with the audience?
  • Have fewer than 20 slides for the 40 minutes left to present their topic (one slide per two minutes)?
  • Attempt to get across only one idea per slide?
  • Use more graphics/pictures than words in their presentation or at least a 50-50 mix?
  • Tell at least two stories about their own experience?
  • Use 28-point fonts or larger for all text on all slides?
  • Have no more than two bullets on any single slide?
  • Design into the presentation at least 3 “turning points” where contrast from “what is” to “what could be” is obvious? 
  • Create slides that take less than 3 seconds for the audience to comprehend?
  • Spend the first 5 minutes, in some way, assessing audience needs in a live, dynamic way?
  • Gesture, pause, smile, show enthusiasm and overall demonstrate pleasing delivery skills? 
  • Use at least two forms of media including overhead, whiteboard, flipchart or product demonstrations?
  • Spend at least 90% of their time facing the audience and giving them great eye contact?
  • Project their voice loud enough in the room to not need a microphone?
  • Speak with authority and confidence without excessive use of “uh” or “um”?
  • Use an industry-proven rubric that actually captures the real effectiveness of their training (i.e. NOT a standard “smile sheet”)?

If you answer “no” to three or more of these questions, you need our help. Sure, this is a long list, and it is easy to find three items to say “no” to. But isn’t that good marketing?

Seriously, you can indeed learn how to say “yes” to these 20 questions, and 20 more. Think about the problems you have solved and solutions you have delivered to customers. If you can do that, you can learn to create and deliver great technical presentations. We have worked with hundreds of engineers with great results. No, you don’t have to be an extrovert or “naturally gifted speaker.” In fact, we would rather you be more introverted, skeptical, analytical and logical. We want you to test each process or method we teach with your brain fully engaged (both left and right sides).

Consider signing up for one of our “Technical Presentations” workshops. This informal “inverse” rubric is only a small sampling of “what” we teach, along with “why” and “how.” We embrace the engineering, technical mindset and harness it to help you become a great technical communicator. That is, if you are honest enough to say, “Yes, I need help."


How we help with workshop design

When asked to provide consulting on a technical workshop, we start with a free initial assessment over the phone. This conversation helps us understand the project scope and provide a quote for consulting services. So, don't hesitate to contact us.

To give you a better idea of what consulting on a technical workshop might look like, let's assume you are designing a 2-day workshop with 10 chapters and 10 labs. You have subject matter experts who can create the labs but require assistance in designing the course to meet specific goals.


After the initial needs assessment, we would take your team through the one-day Instructional Design workshop so that everyone involved is on the same page speaking the same language. We would then spend a second day consulting with your team to plan out each chapter and lab and assign actions to create first-pass material. So that’s two days.

Let us assume that creating each chapter and a sketch of the lab takes a month (along with doing day-to-day jobs). We would then re-convene for another consulting day to review materials, tweak processes, address questions or concerns, assess progress and determine how to proceed.

Then, after about another month, depending upon the timeframe and project complexity, we might meet for a fourth consulting day to go over all materials and labs as well as the entire workshop structure. At this point, the client might schedule our Train the Trainer course. We might also assess the entire workshop in a beta class with customers and provide additional help, ideas and suggestions.

We can come alongside your process for as long as needed. However, our goal is to truly transfer essential skills to your organization so that you have the ability to independently create effective technical workshops.