November, 2025
As researchers, our job is not just to produce research results, but also to present them to the community in papers and talks. There is no single formula for a good engineering talk; some of the best talks I’ve seen have had unusual structure or somehow broken the rules. Nonetheless, if you are struggling to make a compelling talk, I’ve found a recipe that reliably improves presentations. Often people unconsciously do something similar, so thinking in terms of this concrete recipe can help identify what is missing.
Of course, the most important ingredient is having a good result to present, but that’s not what this blog post is about. The problem I want to address here is how to avoid giving a mediocre talk about a solid engineering result.
My recipe is simple. Structure your talk so as to lead the audience through a series of four emotions:
I expand on each of these below.
Right from the start of the talk, you have to make people want the results of your work. Make the audience feel how nice it would be to use your work, or fear what might happen if your work is not deployed. In an age of dwindling attention spans, it’s crucial to convince people as quickly as possible that there will be a payoff for giving you the next 20-40 minutes of their attention.
Paint as tangible a picture as possible of what your work enables using a concrete, even if toy example. Such an example makes people want to learn what you are showing them. It also commits to a least one specific criterion for what it means for your work succeed, providing some implicit guarantee on what listeners will get from the talk. Finally, it provides a kind of north star when you later delve into your technical contributions. If people get lost and wonder, “Why am I listening to this? Why do we want this complexity?” the answer should be obvious—to enable the concrete scenarios we desire from the start of the talk. Tie technical details back to this motivation so that people always know why you are telling them what you are telling them.
Another important ingredient for maintaining your audience’s attention is convincing them you’ve solved a hard problem. Once you incite desire, good engineers in the audience will immediately think, “Okay, I want this. How would I build it?” If the first answer that comes to mind is exactly what you describe, people will stop listening to you and start daydreaming about doing it themselves.
The emotion you want to elicit at this point is bewilderment. In an ideal situation, you want people thinking “Of course I want this, but how on earth is it possible? Tell me!” Depending on the nature your result, it might be easier or harder to get your audience eagerly awaiting the solution to the problem you have laid out.
If you’ve solved a long-standing open problem, eliciting bewilderment is easy. You can point to how many other published results have fallen short, or how many billions of dollars have been invested to work around a problem that you actually solved. You may even have people in the audience who worked on your exact problem and couldn’t crack it, fascinated to hear how you solved it. Unfortunately, few results involve such an objective breakthrough.
Many interesting engineering contributions derive as much from asking the right question as from discovering the answer. Even so, there are trade-offs that make taste very important to the design of your solution. You need to convince the audience that any obvious solutions have undesirable characteristics. For instance, maybe it’s straightforward to solve several problems individually, but the solutions don’t compose. Or maybe it’s hard to design a single, simple, elegant mechanism that solves several related problems. Somehow you need to convince your audience that there’s something they can’t figure out on their own, for which it’s worth listening to the rest of your talk.
The key moment around which to structure your presentation is enlightenment: the denouement in which the audience learns something new and exciting—how to get a result they desire in a way that’s better than what they would have come up with on their own. When people acquire novel, useful information, it provides a memorable payoff for the time they invested in your talk. If your result involves a salient breakthrough, this is where you reveal the key idea to the audience and everything clicks. Don’t be afraid to build up some narrative tension to get people excited or even impatient to hear your solution.
In the absence of a single, key breakthrough idea, the path to enlightenment is less obvious. When you’ve worked on a project for months or years, solving a series of medium-sized challenges along the way, it can be harder to figure out how to engineer an aha moment for the audience, but that doesn’t make doing so any less important. Just telling people what you did is unlikely to hold their attention. You need to tell them why that is a good way to do things—which is rarely the actual reason you arrived at your solution. Maybe you did it that way because it was easier than the first three approaches you tried, or because you initially thought it necessary for some other goal you later abandoned. Forget how you actually arrived at your solution and articulate its merit in the context of the desire you have incited.
One thing that helps the audience contextualize your result is understanding why you were able to solve a problem that no one else did. With a true breakthrough, maybe lots of people tried and you were just smarter, luckier, harder-working, or better-resourced than everybody else. But be honest—most of us can hope to publish at most a handful of such results over a 40-year career. Typical results cannot be sold as solutions nobody else was capable of figuring out. A better approach is to explain what changed in the world to enable your solution. Maybe your result leveraged some technological change—performance trends, or new technology that you figured out how to apply in a different domain. Or maybe people were asking the wrong question—you figured out that what we really want doesn’t require solving the long-standing open problem others have focused on. These kinds of claims can leave people feeling enlightened without the need to believe the unlikely proposition that you are simply smarter than anyone else who worked on the problem.
Okay, so your talk has reached the enlightenment stage. Your audience members feel an endorphin rush as you finally reveal the secret to achieving this seemingly impossible goal everybody wants so much. Can you declare victory? Not yet. It’s all too easy to make ideas sound good until you actually go to implement them. You motivated your talk by making people desire a certain outcome. Now you owe your audience the satisfaction of seeing your work deliver that outcome. Way too many talks fail to deliver satisfaction and leave me disappointed that the new idea I’ve just learned doesn’t actually do what I want.
Presentations often deliver satisfaction through empirical evaluation results. It’s great to close a talk with end-to-end performance benchmarks of a solution to the exact motivating problem from the beginning of the talk. Benchmarks demonstrate your solution can be practical and cost-effective. Equally important, they demonstrate that you actually implemented your system to the point that you could run the system end-to-end. But beware the cardinal sin of technical talks: evaluating something unrelated to your motivating example.
If you take one point from this blog post, it’s that engineering talks absolutely must close the loop between motivation and evaluation. I’m not going to name weak research, so let me pick on what is by all accounts fine work, a SIGOPS hall-of-fame paper on seL4, the first machine-checked, general-purpose microkernel. The presenter motivated the work by showing a flight-simulator cockpit with Windows “blue screens of death.” Maybe this was a joke and the presenter assumed a verified kernel was ipso facto such a breakthrough that no real motivation was necessary. However, I think this was a missed opportunity to turn a great paper into a great talk. It also exemplifies something I’ve seen in countless other talks where it definitely was not an attempt at humor.
The problems are that A) this isn’t even a real cockpit (Windows is not permitted to run critical avionics systems), B) avionics was at the time one of the few areas that already enforced strict software standards, including verification of any loops, C) no Windows applications are going to run on seL4, and D) safety involves far more than the kernel, so you want to show at least one real-world domain in which seL4’s correctness meaningfully improves end-to-end safety—avionics isn’t an obvious choice given how much safety-critical logic would have to reside outside the seL4 kernel.
I’ve presented a recipe that I find useful in preparing and giving feedback on technical talks. Let me emphasize again that this is just a recipe, certainly not the only recipe for a good talk. That said, the recipe has proven useful enough to me that I wanted to share it in a blog post.
Particularly in computer systems, a lot of talks follow some variation of the pattern: Introduction, Related Work, Design, Implementation, Evaluation, Conclusion. It’s pretty easy to fit my recipe onto such an organization. You want desire by the end of the Introduction, bewilderment by the first few slides of Design, enlightenment by the end of Design, and satisfaction in the Evaluation section. When I’m giving feedback on a practice talk, it’s often clear which ingredient is missing—maybe the talk seems flat because there’s no bewilderment, or there’s no enlightenment to provide excitement, or the evaluation is completely unsatisfying in light of the motivation. Identifying and concentrating on any missing ingredients can dramatically improve a talk and help turn solid engineering results into a compelling, memorable presentation.