Tell Me a Story

Commencement time brings commencement speeches; one of my favorite commencement speeches is a speech by Robert Krulwich at Caltech in 2008, where he discusses the importance of storytelling in science.  His speech makes a case for talking about science to audiences that may not be well-versed experts in the topic being presented.   This speech should be required listening for any graduate student or researcher in science.

Krulwich begins the speech by putting the students in a hypothetical scenario where a non-technical friend or family member asks “What are you working on?” What would you think: Is it worth the effort to try to explain your work to the general public?  Do you care to be understood by average folks? His advice: When someone asks this question, even if it is hard to explain, give it a try.  Talking about science to non-scientists is a non-trivial undertaking.  And, it is an important undertaking, because the scientific version of things compete with other perhaps equally (or more) compelling stories.

As researchers, we are competing for human attention; we love to hear stories.  Storytelling is perhaps one of the most important—and one of the most under-taught—aspects of our discipline.  The narrative of a research writeup or talk can often determine whether the work is well-received—or even received, for that matter.  Some cynics may dismiss storytelling as “marketing”, “hype”, or “packaging”, but the fact of the matter is that packaging is important.  Certainly, research papers (or talks) cannot have merely style without substance, people are busy, and many people (reviewers, journalists, and even other people within your field) will not stick around for the punchline if the story is not compelling.  Of course, this advice applies well beyond the research community, but I will focus here on storytelling in research, and some things I have learned thus far in my experiences.

When I began working on network-level spam filtering, I was initially pretty surprised at how much attention the work was receiving.  In particular, I viewed our first paper on the topic as somewhat light in terms of results: there was no sound theory or strong results, for example.  But, the work was quickly picked up by the media, on multiple occasions.  I found myself talking to a lot of reporters about the work, and, as I repeatedly explained the work to reporters, I found myself getting better at telling the story of the work.  I was using analogies and metaphors to describe our techniques, and I got much better at setting the stage for the work.  I also realized what gave the work such broad appeal: everyone understands email spam, and the conceptual differences with our approach were very easy to explain.  Here is the story, in a nutshell:

“Approximately 95% of all email traffic is spam.  Conventional mail filters look at the contents of the message—words in the mail, for example, to distinguish spam from legitimate content.  Unfortunately, as spammers get more clever, they can evade these filtering techniques by changing the content of their messages.  In contrast, our approach looks at behavioral characteristics: rather than looking at the message itself or who sent it, look at how it was sent.  To understand this, think about telemarketer phone calls: you know when someone calls first thing in the morning or right during dinner that the call is most likely a telemarketer, simply because your friends or family are too considerate to call you at those times.  You know the call is unwanted and can dismiss it before you even answer the phone.  We take the same approach with email messages: we identify behavioral characteristics that allow a mail server to reject a message based on the initial contact attempt, before it even accepts or examines the message.  Our method filters spam with 99.9% accuracy, and network operators can deploy our techniques easily without modifications to existing protocols or infrastructure.”

It turns out that this message is relatively easy for the average human to understand; they can relate to this story because they can see what it has to do with their lives, and the approach is explained clearly, and in terms of things they already understand.  Even after this initial work was published, it took me years to refine the story, so that it could be expressed crisply.  Introductions to papers and talks should always be treated with similar care. One can think of the introduction to a paper as a synopsis of the entire story, with the paper itself being the “unabridged” version (i.e., it may include many details that only the most interested reader will pore over).

How does one tell a story that readers or listeners actually want to hear?  Unfortunately, there really is not a single silver bullet, and storytelling is certainly an art.  However, there are definitely certain key ingredients that I find tend to work well; in general, I find that good stories (and, in particular, good research stories) have many common elements.  Based on those common elements, here is some advice:

• Have a beginning, middle, and an end. At the beginning, a research paper or talk should set the context for the work.  A reader or listener immediately wants to know why they should devote their time or attention to what you have to say.  Why is the problem being solved important and interesting?  Why is the problem challenging?  Why is the solution useful or beautiful?  Who can use the results, and how can they use them?  For example, in the above story on spam filtering, there is a beginning (“users get spam; it’s annoying, and current approaches don’t work perfectly”), a middle (“here’s a new and interesting approach”), and an end (“it works; people can use it easily”).
• Use analogies and metaphors. People have a much easier time understanding a new concept if you can relate it to something they already understand.  For example, the above story uses telemarketing as an analogy for email spam; nearly everyone has experienced a rude awakening or disruption from a telemarketer, which makes the analogy easy to understand.  In some cases, it may be that the analogy is not perfect; in these cases, I find that it helps to use an analogy anyway and explain subtle differences later.
• Use concrete examples. People like to see concrete examples because they are exciting and much easier to relate to.  It’s even better if the example can be surprising, or otherwise engaging.  For example, the above story gives a statistic about spam that is concrete, and some may even find surprising.  In a talk, I often augment this concrete example with a news clipping, a graph, or an interactive question (e.g., one can have people guess what fraction of email traffic is spam).
• Write in the active voice. Consider “It was observed.” (passive) vs. “We saw.” (active).  The first is boring, indirect, and unclear: the reader (or listener) cannot even figure out who observed.  I find this writing style immensely frustrating for this reason.  My frustration generally comes to a boil when someone describes a system using primarily verbs in the passive voice (“The message was sent.”).  Passive voice makes it nearly impossible for the reader to figure out what is happening because the subject of the verb is unspecified.  Often, when I press students to turn their verbs into active voice, we find out that even they were unclear on what the subject of the verb should be (e.g., what part of the system takes a certain action).
• Be as concise as possible, but not too concise. We’ve all complained about movies that “drag on too long” or a speech that “does not get to the point”.  Humans can be quite impatient, and, in the context of research papers, people want to know the punchline quickly, as well.  Research papers are not mystery novels; they should be interesting, but they should also convey findings clearly and efficiently.  Most of my time editing writing involves removing words and otherwise shortening paragraphs to streamline the story as much as possible.

A final point is to consider the audience.  Someone you meet in an elevator or hallway might be much less interested in the details of your work than someone listening to a conference talk or thesis defense.  For this reason, it’s important to have multiple versions of your story ready.  I call this a “multi-resolution elevator pitch”, because it’s a pitch where I can start with a high-level story and dive into details as necessary.  Having a multi-resolution elevator pitch ready also makes it much easier to convey your point to very busy people who may not have the time to stick around for more than 30 seconds.  If, however, you can hook them in the first 30 seconds, you may find that they stick around to hear the longer version of your story.