When the Demo Breaks: Improvisational Agility for Solution Engineers

It will happen to you. The environment times out, a login fails, a data load did not finish overnight, the conference Wi-Fi drops, or a feature that worked an hour ago throws an error in front of the customer’s leadership team.

Live failures are not a sign that you are a bad Solution Engineer. They are a normal part of the job. What separates experienced SEs is not that their demos never break, but how they respond when one does. This skill, improvisational agility, is about handling failure gracefully, keeping the conversation focused on business value and preserving the audience’s confidence.

Why the reaction matters more than the failure

Audiences tend to remember how you handled a problem far more than the problem itself. A long apology, visible panic or ten minutes of frantic troubleshooting signals that the product, and perhaps the vendor, is fragile. A calm, composed pivot signals competence and control. Buyers are also imagining what working with you will be like when something goes wrong after purchase. Your reaction in the room is a preview.

Prepare before anything breaks

Agility in the moment depends largely on preparation beforehand:

• Run a pre-flight check. Log in, load key screens and confirm data shortly before the session, not the night before.
• Have a backup path. Keep screenshots or a short recording of the critical flow, a second environment or a second login ready.
• Keep a whiteboard story ready. Be able to explain the key outcome and architecture by drawing it, without any software.
• Know your network options. Have a fallback connection, such as a mobile hotspot, if you rely on the internet.
• Agree roles with your account executive. Decide in advance who keeps the conversation going while the other recovers.

What to do in the moment

1. Acknowledge briefly and calmly

One short, honest sentence is enough: “Looks like this environment is not responding the way it should. Let me take a different route.” Avoid over-apologising or blaming. Do not pretend nothing happened.

2. Give yourself a time limit

Decide quickly whether a fix is trivial, such as a refresh or re-login. If it will not work in a few seconds, stop trying in front of the audience. Troubleshooting live drains the energy from the room.

3. Pivot to value

Move the conversation to what matters most to the buyer. Ask a discovery question, walk through the outcome on a whiteboard, or show the backup screenshots while you explain how the workflow solves their pain. Often, this unplanned conversation is more valuable than the click-path you had scripted.

4. Offer a clear follow-up

If something important could not be shown, commit to a specific next step: “I will send a short recording of this flow today, and if helpful we can schedule fifteen minutes to walk through it live.” Then do it promptly.

Phrases that help

• “Rather than wait on this, let me show you what the result looks like and we can come back to the screen.”
• “While that reloads, can I ask how your team handles this today?”
• “Let me draw how this works. It is actually easier to see the architecture this way.”

What to avoid

• Long explanations of the cause. The audience does not need a technical post-mortem.
• Blaming colleagues, IT or the product. It undermines trust in everyone.
• Misrepresenting what happened. Masking a glitch smoothly is fine; claiming a broken feature works is not. Honesty protects your credibility.
• Letting the failure define the meeting. Do not keep referring back to it.

After the meeting

Investigate what went wrong and fix it before the next session. If the failure points to a real product issue, record it through your product feedback channel. Add the scenario to your pre-flight checklist so it does not happen twice.

Build the reflex through rehearsal

Improvisation feels natural only after practice. During dry-runs, ask a colleague to “break” the demo at random moments so you can practise pivoting. SE Ignite Academy covers this behavioural skill in its free curriculum and offers safe practice scenarios for rehearsing it. The goal is simple: when the demo breaks, the conversation keeps going.