Computing Profession

Sharing Through Storytelling

Why I tell stories at conferences.

Maaiki Zwart

I recently attended the Logic Mentoring Workshop, a workshop for young researchers to discuss academic life as logicians and computer scientists. Many students feel insecure at conferences because they find a lot of the talks hard or impossible to follow. I do not blame them; I often do not get much out of conference talks myself, and when discussing this with the more senior researchers in my group, even they admitted the same. This means that the problem is not with the audience, but with the speakers.

We seem to have forgotten the main purpose of a conference: to share our work with others through talks and discussions. I go to talks because I want to learn something. So instead of displaying the obligatory summary of our paper, let us put real effort into our conference talks again. Let us make them informative, fun, and worthwhile to listen to.

There are many possible approaches and styles for making and delivering good talks. I have seen blackboard talks that captivated me, demonstrations of software that made me want to try it out, talks about security that changed how I handle data. What these talks have in common is that I remember their main message. In this blog I would like to share my favorite technique to achieve this in a conference talk, namely through storytelling.

Stories have been used for thousands of years as an effective way to convey information. We all love a good story: they are entertaining and easy to keep paying attention to. In addition, the moral of a story is easy to remember, which makes them great for teaching purposes. And the best part is that they are not only fun to listen to, they are also fun to make! Here is how I turn my papers into a story suitable for telling at a conference[1].

I am a great fan of the three-act story structure: set the stage, create a conflict, and resolve the conflict. Notice the singular here: conflict, not conflicts. Even though papers need to be packed with results to be accepted at the top-tier conferences, a 20-30 minute conference talk should focus on just one idea from a paper. What is the one thing that I want people to know about and understand from my paper? That is what my story will be about, and this is how I tell it:

“Once upon a time…”

The first few sentences are crucial to capture the attention of the audience. This is where they decide: listen to my talk, or work on their laptop? If I make it clear that a story is coming, people will be interested and pay attention. Here is how I started my last talk: “Three years ago, Rasmus asked me a question…”

Next, I need to set the stage. I introduce the audience to the world, its main characters, and the main quest. The main quest is this one idea or result from my paper that I chose earlier. In this case, finding the answer to Rasmus’s question: Does the powerset monad distribute over the delay monad? (For those unfamiliar with monads, it is enough to know that this is a yes/no question). The world and characters determine how I will tell the story of this quest.

What the world looks like depends on my audience. I try to set my story in a world that is familiar to my entire audience. This is important for them to be able to follow my story. I am not afraid to oversimplify here. In my case, for a broad audience I am in the category of sets or in set theory, whereas for a highly specialized audience I am in Clocked Cubical Type Theory.

Characters can be humans, such as player and opponent for quantifiers in game semantics. The main character could even be me in a story of discovery of my main theorem, filled with enlightening collaborations. But characters can also be very abstract: I once featured a proof technique as my main character. To tackle Rasmus’s quest, I chose parallel computation as the main character, and the property of idempotence (x * x = x) was one of my side characters; a villain because it keeps messing up my beautiful theorems[2].

The quest

With the world set and my characters in hand, it is time to go tackle the main problem. This is the most creative part of constructing a story out of my paper. Instead of going straight to the solution, this is the place where most of the actual storytelling happens, and where the audience can learn the most. It is the journey Frodo takes towards Mordor, the three quests the prince needs to fulfill to get the hand of the princess. Or for a conference talk, it could be the challenges I met in my research and how I overcame them. In my case, parallel computation seemed like an obvious solution, but it failed. I still spent a third of my talk on it. Explaining what I tried and why it did not work was a great learning experience for my audience: it built an understanding of my final solution, as well as a bit of excitement for it!

And then finally, time for the big finale. The answer to the question we have all been waiting for: Will the lovers get together? Does Frodo destroy the ring? Did I manage to solve the main problem, and how did I do it? In my case, I solved Rasmus’s question, and the answer is… No. And it is because of Idempotence (I told you it was the villain).

“…and they lived happily ever after.”

After the big finale it is time for a short recap, maybe tie up some loose ends, advertise other results of my paper and future work. But most importantly, my closing sentences determine the emotion people connect to my talk. What should they have learned? If I have been successful, then repeating this as a take home message will make my audience feel smart and satisfied. Humor can make them feel happy. A question can tickle their curiosity: how can they apply my results in their own work? I ended my talk with hope: parallel computation can be a good solution if we change Rasmus’s question slightly, caring only about equations up to weak bisimilarity. This has the effect of ignoring idempotence on the delay monad – beating our villain by giving up precision.

In this blog I explained how I use storytelling techniques as an effective way to communicate the main points of my papers at conferences: I get my audience to pay attention, to understand the main challenges of my work, and to remember my solutions. The focus was on how I structure my talks as stories. But there is more to successful conference storytelling than structure alone. Just like a joke, the delivery of a story can make or break it. There is also the matter of slides and blackboard usage. But, those are stories for another time. For now, I will leave you with this: How will you turn your paper into a story at the next conference?

Maaike Zwart is a postdoctoral student at the IT University of Copenhagen. She studies monads in category theory and type theory, specifically focusing on combinations of monads via distributive laws.

[1] The running example I use is based on my recent paper and accompanying conference talk “What monads can and cannot do with a bit of extra time,” written with Rasmus Møgelberg and published and presented at CSL2024. Sadly, the talk was not recorded, but the slides are available here.

[2] There is some subtlety here. Anthropomorphisms are frowned upon in science: atoms don’t want to minimize their energy, etc. I still think it is useful to think of abstract concepts as `characters’ in my story. But I do so without giving them human intentions. 

Join the Discussion (0)

Become a Member or Sign In to Post a Comment

The Latest from CACM

Shape the Future of Computing

ACM encourages its members to take a direct hand in shaping the future of the association. There are more ways than ever to get involved.

Get Involved

Communications of the ACM (CACM) is now a fully Open Access publication.

By opening CACM to the world, we hope to increase engagement among the broader computer science community and encourage non-members to discover the rich resources ACM has to offer.

Learn More