Presentations

Read this before a sprint demo, a partner update, or a design review; it gives you a structure for the talk and a way to demo without failing live.

Engineering work that is not communicated effectively might as well not exist. A working feature nobody understands has no champions. A strong technical decision nobody can explain gets overruled by whoever speaks loudest. A risk nobody articulates becomes a surprise in production.

Presentations are how engineers share progress, build trust with stakeholders, and collect the feedback that keeps a project aligned with reality. Without strong communication skills:

Stakeholders lose confidence in the team’s direction, even when the technical work is solid.
Good decisions get revisited because nobody remembers (or understood) the rationale.
Demos that fail live overshadow months of real progress.
Opportunities to collect critical feedback are wasted because the audience did not understand enough to respond.

The goal of any technical presentation is simple: leave the audience with a clear, accurate understanding of what matters most, whether that is a decision they need to make, a risk they should know about, or progress they should feel confident in. Everything else on this page follows from that one goal, and where two pieces of advice conflict, the one that serves the audience’s understanding wins.

That framing is not original to this handbook. Jean-luc Doumont builds an entire method for technical communication on it: decide the single message first, then let structure, slides, and delivery serve that message rather than the other way round. Patrick Winston’s How to Speak, taught at MIT for four decades and recorded in full, reaches the same conclusion from the opposite direction: he treats speaking as a learnable craft with specific, teachable moves, not a personality trait you either have or lack. If you read or watch nothing else on this page, watch that hour.

Sprint Demos

A sprint demo is a live walkthrough of what the team delivered in the most recent sprint. It is not a status report. It is a demonstration of real results: working software, experimental outputs, validated findings.

A good sprint demo:

Shows the work in action, end-to-end, on realistic data. Not a description of what was attempted, not a status update, not a slide deck about future plans.
Demonstrates work that meets the team’s Definition of Done. If the team agreed that “done” means reviewed, tested, and deployed to a staging environment, the demo should show it running there. If the DoD for this phase only requires passing tests locally, that is fine too; the point is that the demo reflects the standard the team committed to.
Connects what was built to a requirement or acceptance criterion the audience already understands.
Is honest about what was descoped, delayed, or changed, and explains why.
Ends with a clear invitation for feedback: “Does this meet your expectations? What should we adjust?”

The sprint demo is the team’s primary feedback loop with stakeholders, and it sits inside the review phase of the sprint cycle. Whether the audience is a project partner, an instructor, or the rest of the team, treat it as a conversation, not a performance. The goal is alignment, not applause, and the difference shows up in what you do with the last five minutes: a performance ends with a summary, a conversation ends with a question you actually want answered.

Stakeholder Presentations

A stakeholder presentation addresses a broader audience: people who care about the project’s outcomes but may not be involved in the day-to-day work. This includes leadership, management, cross-functional teams, the executives who fund the work, and anyone evaluating the project from the outside.

Stakeholder presentations follow a different rhythm than sprint demos. Where a demo says “here is what we built this sprint,” a stakeholder presentation says “here is where the project stands, how we got here, and where it is going.”

Effective stakeholder presentations tend to cover four things:

The problem. What problem is this project solving, and for whom? This grounds the audience before any technical content.
The approach. How did the team decide to solve it? What alternatives were considered and rejected? This builds credibility by showing the team made deliberate choices.
Current state. What has been built, validated, or discovered so far? Show it. A working demo, a visualization of results, or a credible walkthrough of the system is far more convincing than a summary of tasks completed.
What comes next. What are the known limitations? What risks remain? What is the plan for the next phase?

There is a serious argument that slides are the wrong medium for this entirely. Amazon replaced them for leadership reviews with a six-page narrative memo, read silently at the start of the meeting in what Jeff Bezos described in the 2017 letter to shareholders as a kind of study hall, and only then discussed. His reasoning is worth taking seriously: a narrative forces you to connect your claims, and bullet points let you skip the connections and never notice. You will almost certainly be asked for slides rather than a memo in this course, so the practical version is to write the argument in prose first, check that it holds together as prose, and only then decide which parts need a slide.

Design Reviews

A design review is a presentation to peers: teammates, advisors, or anyone qualified to critique the proposed approach. Design reviews are not limited to architecture and code. They apply equally to UI/UX designs, data models, research methodologies, and workflow proposals. Any decision that affects how the system looks, behaves, or is built benefits from structured critique before implementation begins.

The purpose is not to defend a design but to stress-test it, which works best when there is a written technical design to react to rather than a verbal sketch. Present the design, the options that were considered, the decision that was made, and its consequences. Then invite critique. The best design reviews surface problems that would have been expensive to discover during implementation.

Treat hard questions as help, not attacks. A design review that produces no changes is either a very mature design or a review that was not honest enough.

Public Demonstrations

Some presentations happen in open, public settings: expos, showcases, poster sessions, or employer events. These have different dynamics than a team-internal or classroom presentation, because the audience is self-selecting, arrives mid-explanation, and leaves whenever it wants.

Key differences:

The demo leads. Have it running before the doors open, looping or ready to restart, and show a visitor the thing working before you explain it. Do not rely on a single run-through.
The audience is diverse. Some viewers are deeply technical; many are not. You need an explanation that works for both, and the running software is the part both understand.
You do not control timing. Someone may approach your booth at any moment. Be ready to start cold.
Brevity is the fallback, not the plan. Many visitors will only give you a minute, so keep a 60-second elevator pitch ready for the one who will not stop. It comes after the demo, not instead of it.

Principles That Apply to Every Presentation

Regardless of format or audience, a few principles consistently separate effective presentations from forgettable ones.

Lead with the Point

Do not build to a conclusion; start with it. “This sprint we shipped user authentication and onboarded our first external tester” is a stronger opening than three slides of context. The audience should understand what matters before you explain the details.

This applies at every level: the presentation as a whole, each section, each slide. If someone walked in halfway through your presentation and saw only the current slide, would they understand the point being made?

Show, Do Not Tell

A live demo is worth ten slides. If you can show something working, show it. Reserve slides for things you cannot demo: architecture diagrams, risk tables, timelines, before-and-after comparisons, data visualizations.

For research-oriented projects, “showing” means displaying real outputs: plots, model performance metrics, pipeline results on actual data. A Jupyter notebook with real outputs is more convincing than a slide summarizing what the notebook produced.

Design for Your Audience

Technical presentations to peers can include architecture diagrams, code snippets, and implementation specifics. Stakeholder presentations should not. Ask yourself: “Would a non-engineer in this audience understand this slide?”

The same project might require both versions. A sprint demo to the project partner focuses on functionality and outcomes. A design review with the team focuses on architecture and trade-offs. Adjust the depth and vocabulary to match who is listening.

Let Ownership Guide Who Speaks

The person closest to a piece of work should be the one explaining it. This applies to sprint demos, stakeholder presentations, and design reviews alike. Dividing presentation responsibilities by ownership (the person who built the feature explains the feature, the person who ran the experiment presents the results) produces more credible and natural delivery than arbitrary segmentation.

Prepare for Questions

Spend a meaningful portion of your preparation time anticipating questions and rehearsing answers. Common hard questions in technical presentations:

“Why did you choose X instead of Y?”
“What happens if this component fails?”
“How does this scale beyond your current usage?”
“What is the biggest risk right now?”

You do not need perfect answers. “We considered that and chose not to because…” or “We do not know yet, and here is how we plan to find out” are honest and credible responses. What damages trust is being caught without having thought about it at all.

Delivering a Demo

Demos are high-stakes moments, and the teams that make them look effortless are the ones that practiced the most.

Use realistic data. Demos with obviously fake data (“Test User 1”, “Lorem ipsum”, “AAAA”) undermine credibility. Populate the demo environment with data that looks like the real thing.
Know the path. Practice the exact sequence of interactions you will perform. Know what you will click, what you will type, and what the system will show in response.
Have a fallback. Record a video of the demo before the presentation. If the live demo breaks (and live demos break regularly), play the recording. This is not a failure; it is preparation.
Narrate as you go. Do not silently click through screens. Say what you are doing and why: “I am logging in as an admin user and navigating to the project dashboard, where we can see the new analytics view.”
Leave the demo visible. After the walkthrough, keep the application or notebook open rather than switching back to slides. It stays available for follow-up questions.

Recorded vs. Live Presentations

Each format has different preparation requirements.

For recorded presentations:

Use a quiet environment with consistent lighting.
Screen recording tools capture both slides and a face camera, and showing the speaker builds engagement. OBS Studio is the free, cross-platform option and is what most streamers use; Loom and Zoom local recording are quicker to set up if you only need one take.
Edit out dead air and false starts. Polished recordings show professionalism.
Speak slightly slower than feels natural. Playback consistently sounds faster than the original delivery.

For live presentations:

Practice the full run-through, including transitions between speakers, at least once before delivery. TED puts its speakers through multiple full rehearsals for talks that are shorter than your demo, which should tell you something about how much a single run-through actually buys.
Confirm the technical setup (display resolution, audio, browser, microphone) on the actual machine and screen you will use. Adapter and display issues are the most common source of last-minute panic.
Arrive early. Problems discovered five minutes before the presentation starts are emergencies; problems discovered thirty minutes before are inconveniences.

Slide Design

You do not need design expertise to make effective slides, but you do need a position on what a slide is for. The default most people inherit, a title plus five bullets, is the one worth abandoning first, because it puts the same words on the screen that are coming out of your mouth and forces the audience to choose between reading and listening.

The best-supported alternative is the assertion-evidence structure, developed by Michael Alley at Penn State and documented with the underlying research at assertion-evidence.com. Each slide gets a headline that states a complete sentence rather than a topic (“Latency doubles above 200 concurrent users”, not “Performance”), and the body of the slide is the visual evidence for that sentence: a chart, a diagram, a screenshot. The bullets disappear because the headline already carries the claim and the image already carries the support. It takes longer to build and it is substantially harder to hide behind.

With that settled, the rest is mechanical:

One idea per slide. If a slide makes two separate points, split it. A slide that needs the word “and” in its headline is two slides.
Diagrams over prose. A system architecture diagram, a data flow visualization, or an experimental workflow communicates more than three paragraphs of description, and it survives being looked at while you are talking.
Readable type. Use at minimum 24pt for body text, and check contrast rather than trusting your monitor. The WCAG contrast minimum of 4.5:1 for body text is the threshold to design against; a projector in a bright room is worse than any screen you tested on.
Attribute borrowed assets. If you use an image, icon, or diagram you did not create, include a source credit. This is the same habit the rest of the handbook asks for in writing, applied to pictures.

Best Practices

Practice the full presentation at least once before delivering it, especially the demo.
Time yourself. A presentation that significantly overruns its allotted time signals poor preparation.
Get feedback from someone outside the team before the final delivery. Fresh eyes catch what familiarity hides.
Do not apologize for things being “in progress.” Own the current state confidently and explain what comes next.
Know your handoffs. “I will now hand it over to Alex, who will walk through the data pipeline” is more professional than trailing off while someone else starts unexpectedly.

Some Truths About Presentations

Most of the presentation advice you will encounter, including some of the advice above, is asserted rather than tested. The assertion-evidence structure has actual comparative studies behind it; “make eye contact with the audience” and “never read your slides” are craft wisdom that happens to be widely agreed on. Both can be useful, but they are not the same kind of claim, and it is worth knowing which one you are following. Where this page recommends something on the strength of a named source, the source is linked, and where it does not, treat the recommendation as the opinion of people who have watched a lot of bad demos.

Sprint demos in a course are a partial simulation and everyone in the room knows it. In industry the audience controls a budget and can kill the feature; here the audience is grading you and has already committed to the project continuing. That changes the incentives in a way nobody says out loud: the honest disclosure that would cost you a feature at work costs you very little here, which makes this a cheap place to practice a habit that is expensive to learn later. Use it that way rather than treating the demo as a performance review.

Rehearsal is the advice most often given and most often skipped, and the reason is that rehearsal is boring and slide-tweaking feels like work. The failure it prevents is specific: demos break on the machine, the adapter, the resolution, the network, and the one account whose password nobody remembers. A rehearsal on your own laptop catches almost none of that. A rehearsal on the actual machine, projected onto the actual screen, catches most of it, which is why the recommendation is narrower than “practice more” and why the recorded fallback exists.

Audiences forgive far more than presenters expect, but only on one condition. “This part does not work yet, and here is why” costs you almost nothing and often buys credibility, because it signals you know where the edges are. Glossing over a gap and getting caught costs you the room, because now every other claim is suspect. The asymmetry is large enough that disclosure is the correct default even when you are fairly sure nobody would have noticed.

The best engineers are not always the best communicators, and pretending otherwise does nobody a favor. Technical communication is a learnable skill that improves with deliberate practice and does not improve with avoidance, which is the entire premise of Winston’s course. If you find this genuinely difficult, that is information about where to spend your effort, not a verdict about whether you belong in the field.

Presentations in Industry and Academia

In industry, engineers present constantly: sprint demos, design reviews, incident post-mortems, all-hands updates, sales engineering calls, and cross-team coordination meetings. The ability to communicate technical work clearly to both technical and non-technical audiences is consistently cited as a key differentiator for senior engineering roles. Many companies consider communication skills as important as technical depth when evaluating promotions.

Amazon’s “six-pager” written memo replaces slides for many leadership reviews: the document is read silently at the start of the meeting, which Jeff Bezos has described as a roughly half-hour “study hall”, and only then discussed. The principle is the same as any presentation: structure your argument clearly, support it with evidence, and be prepared to defend your thinking under questioning.

In academia, conference presentations and thesis defenses follow similar principles. A poster session at an academic conference has more in common with a public demo at an engineering expo than either audience might expect: brevity, clarity, and the ability to adjust depth based on who is asking. The assertion-evidence work came out of engineering education for exactly this reason, and the communication courses that teach it, Doumont’s and Winston’s among them, are aimed at researchers who present for a living.

The two worlds differ most in what counts as evidence. An industry stakeholder wants to see the thing working; a conference audience wants to see the method and the numbers that let them judge whether it generalizes. A capstone project presented at an expo usually needs both, because the people walking past your table include employers who want a demo and faculty who want a method.

Additional Readings

Presentation advice is abundant and mostly untested, so this list leans on the people who either studied the question or taught it long enough to have watched the failures repeat. Start with Winston if you have an hour and Doumont if you have a term.

Sources and further reading

How to Speak, Patrick Winston, MIT OpenCourseWare: the canonical lecture on technical speaking, with the full recording.
Assertion-Evidence, Michael Alley, Penn State: the slide structure with actual comparative research behind it, plus templates.
Principiae, Jean-luc Doumont: books and talks on structuring technical communication around a single message.
2017 Letter to Shareholders, Jeff Bezos, Amazon: the narrative memo as an alternative to slides, argued by the person who mandated it.
Duarte presentation resources, Nancy Duarte: story structure and slide craft from the studio behind a great many well-known decks.
speaking.io, Zach Holman: practical, unsentimental advice on delivery, written for developers.
How to design a better pitch deck, Y Combinator: useful for the stakeholder presentation, where you are asking for continued confidence.
Understanding Contrast (Minimum), W3C: the contrast threshold to design slides against.
OBS Studio: free screen and camera recording for the fallback video and for recorded submissions.
re:Work, Google: research-backed material on team practices, including how findings get communicated.

Activities that exercise this

Learn from Patrick Winston: watch the lecture and pull the moves you will actually use.
Learn from Jean-Luc Doumont: the message-first method applied to your own material.
Learn from TED Presentation Advice: delivery and structure from the people who coach it professionally.
Conquer your Fear of Public Speaking: for the part of this that is not technique.
Write for Accessibility and ESL: the same clarity discipline applied to what ends up on the slide.