Should you apologize when something goes wrong during a presentation, like the wrong graph on screen or a piece of audio that will not play? No. Fix it silently if you can, or acknowledge it in one line and move straight on. Apologizing draws more attention to the problem than the problem itself ever would have. This is a narrow, specific situation, your own technical or production mistake mid-talk, and it has a specific fix.
Why this matters (and what most executives get wrong)
A common mid-presentation reflex is to say some version of I'm sorry, this was supposed to look different, I meant to fix that, it was hard to make it readable. Every one of those apologies does the same thing: it tells the room, out loud, that you knew about a flaw and did not fix it before you stood up. The audience's honest reaction to that is not sympathy, it is a quiet why didn't you fix that.
What most executives get wrong is treating the apology as the polite, professional response. It is the opposite. The problem itself, a wrong graph, a squeal of feedback, a slide that did not load, usually passes in a few seconds if you do not dwell on it. The apology is what stretches those few seconds into a much longer, more visible moment, because now you are narrating the mistake instead of just moving past it.
Apologizing does not undo the mistake. It just puts a spotlight on it and holds the light there while you explain.
The 2-step way to handle a mid-presentation glitch
Step 1: If you can fix it in the moment, fix it and keep talking
If a slide is unreadable or something is broken, correct it if you can while continuing to speak, rather than stopping everything to explain what went wrong first. Action, not narration, is the fastest way through it.
Step 2: If you cannot fix it, turn it off and move on
If the technology itself is the problem, whether that is a loud feedback squeal or a video that will not play, cut it. Push the button, black out the slide, or simply skip to the next thing without calling attention to what just happened. You are allowed a brief, light acknowledgment once, but not a repeated or extended apology.
The mistake most executives make
The mistake is apologizing repeatedly for something that has already passed, or apologizing preemptively for something that has not even gone wrong yet. Every apology is a small confession that something in your preparation was not handled, and stacking several of them across a single talk starts to define the presentation more than the actual content does. Keep the audience's attention pointed forward, on what you are saying next, rather than backward, on what just went wrong.
If something genuinely warrants a brief acknowledgment, a loud noise, an obvious glitch everyone in the room already noticed, you get to name it once, briefly, and move on. What you do not get to do is apologize for it again five minutes later, or apologize a second time for something unrelated later in the same talk.
Case study: the video camera that squealed mid-demo
When training clients, I use a video camera. One time when switching camera modes, the video camera I using produced a sudden, loud feedback squeal partway through. My instinct could have been to stop, apologize at length, and explain what had happened technically. Instead I gave a brief acknowledgment with a small smile, and moved directly back into the demo. Everyone saw that it was a small technical glitch and then mentally went back to focusing on... The "what's in it for them" ... the content. It was a non issue.
Apologizing versus fixing and moving on
| Element | Apologizing | Fixing and moving on |
|---|---|---|
| What it signals | You knew about a flaw and did not fix it | A minor glitch, already handled |
| Time spent on the problem | Stretched out, repeated | A few seconds, at most |
| Audience's attention | Stays on what went wrong | Returns to your content |
| What they remember | The apology, more than the content | The content, barely the glitch |
What to do next
Before your next presentation, decide in advance how you will handle the most likely technical failure point, a slow slide, an unreliable clicker, a video that might not play, and rehearse fixing or skipping past it without a word of apology. If you want help pressure-testing a high-stakes talk for exactly this kind of moment, get a quick quote. For a related technique on acknowledging something the room has already noticed, see calling the moment, and for keeping momentum through the rest of a talk, see how to start a speech with the same confidence you want to keep all the way through.
The glitch is rarely the problem. The apology is what makes it one.