Lightning talk presentation

1. Learn the event rules and audience

When preparing a lightning talk, first check the organizer’s announcement or speaker briefing for the talk duration, slide rules, Q&A format, and any file submission requirements. If information is missing, ask the organizer rather than making assumptions. The name “lightning talk” alone does not determine the duration or format of your event. For example, the UMass Amherst event page describes a program in which speakers change every few minutes; this is information about that event’s schedule, not a time limit that applies to all lightning talks (UMass Amherst event page).

Also consider how familiar the audience is with the subject. You can use technical terms with an expert audience; if you are speaking to people from different disciplines, explain the terms they need to understand your main point in plain language the first time they come up. Choose information that serves the purpose of the talk rather than including every background detail.

2. Choose a single main message

Narrow your topic by asking: “What is the one idea I want the audience to remember after the talk?” For example, “database performance” is a broad topic. “To find a slow query, measure first and then make changes” is a message you can explain with an example in a short talk.

Choose an example, workflow, or comparison to support your message. Describing several methods, tools, and results can dilute your focus. If you need more comprehensive content, you can plan it separately using an approach to creating an informative presentation. The goal is not to fit every detail into one talk, but to make your chosen idea clear.

3. Build a schedule that fits the time

First write down the actual time allowed by the event, then allocate time for the introduction, example, and conclusion. For example, in a five-minute talk, you might allow about 30 seconds for the problem and main message, 45 seconds for context, two minutes for the example, one minute for the takeaway, and the remaining time for transitions. This is only a hypothetical breakdown for an initial draft; it is not an event rule. Time yourself during rehearsal and adjust the flow as needed.

Start by stating the problem and what the talk promises to deliver. In the middle, describe the example you chose. In the final section, state the takeaway and reconnect to the main message in one sentence. In your closing, say what you want the audience to remember rather than simply thanking them.

4. Hypothetical example: a slow API request

Hypothetical five-minute talk — “Improve a slow API request by measuring, not guessing.” The measurements and service conditions below are entirely fictional; do not present them as results obtained from a real system.

• Slide 1 — Problem: Raise the question, “Why is an API request slow?” and state the talk’s main message.
• Slide 2 — Initial observation: Use a simple diagram to show where latency accumulates in a fictional request flow. Make clear that the example is illustrative.
• Slide 3 — Test: Explain that you made one change and took the same measurement again. Describe the change and measurement conditions; do not withhold information needed to understand the comparison.
• Slide 4 — Takeaway: Return to the message, “Measure the bottleneck first, then verify one change.” Note that the result could differ in another system.

In this example, a detailed architecture explanation, a second optimization method, and a long list of tools are left out. The goal is not to teach API performance in full, but to explain a measurement-based decision-making habit through a fictional example.

5. Arrange slides to support the message

Give each slide one job: show the problem, observation, test, or takeaway. Use short headings, simple diagrams, and clear labels. If you show code, choose the section that explains the main idea; also state aloud which change the audience should follow. Avoid turning slides into pages containing the entire talk.

When using a chart, technical result, or screenshot, explain what it shows and the scope of the example. Clearly label fictional data. A lightning talk summary from a university symposium also offers an example of adapting a concrete example to the audience’s needs: the presentation aims to share practical examples that participants can readily use, modify, and adapt (symposium presentation summary).

6. Rehearse and check transitions

Rehearse the talk aloud with the slides at least once and time yourself. If you go over time, cut repetition and details that do not contribute to the main idea rather than trying to speak faster. If the main message is unclear, simplify the explanation of the problem; if a slide carries several different ideas, remove the ones you do not need.

Rehearse any steps you plan to use, such as changing slides, opening a link, or giving a live demonstration. If a live demonstration is not required, decide whether to use one based on the event’s conditions and your delivery; if you choose to use one, consider keeping a backup image of the content you will show. Check the presentation file and the readability of its visuals on the screen you will use, if possible.

Do not automatically treat a lightning talk as the same format as an Ignite presentation, where rapid transitions are part of a specific presentation format; confirm the applicable rules with your event. If you encounter an unexpected question, you can use techniques for organizing your thoughts during an impromptu presentation to shape your response.

7. Final checklist

• The event’s time limit, slide rules, and Q&A format have been confirmed.
• The main message can be expressed in one sentence.
• The example supports the message; hypothetical data is not presented as real.
• Every slide has a clear purpose; text and visuals are readable.
• The rehearsal fits the event’s time limit, and the takeaway is stated clearly in the closing.
• The file and any backup visuals have been checked against the presentation conditions.

Frequently asked questions

How many slides should a lightning talk have?

If the event has not specified a slide count, do not assume there is a universal number. Base your choice on the time available and the steps you plan to cover; remove slides that do not contribute to the main message. Ask the organizer whether there is a rule such as a fixed slide count or automatic slide advancement.

Should I leave out technical details altogether?

No. Keep the details needed to understand the main idea; leave out side topics and lengthy background. If the audience asks for more, you can share further explanation or resources after the talk.