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 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.