How to Present your Research: Part 3: Status Updates

Normally, we think of presentations in terms of formal talks. However, I am willing to bet that we all spend far more time giving information status updates (which are, in fact, presentations) than we do giving formal talks, yet I do not believe I've ever seen any guidance on how to do that effectively.  How strange!

Well, here goes ...

Surprise: I'm going to argue that every status update is, wait for it, a fairy tale! (This is going to be a recurring theme.) Before diving into the details of that fairy tale, let's talk about different categories of status updates.

The 1:1 meeting with your advisor/supervisor/team lead. At some point, you'll find yourself in a 1:1 with someone we'll call "your boss" and you'll want to update them on what you've been doing. The key thing to help organize your thoughts and presentation for this meeting is to ask yourself, "In how much depth does this person understand what I'm doing?" In some cases, the boss will know exactly what you are doing and could be doing the task themself.  In other cases, the boss has a big picture idea of the project, but is not knee deep in the details. Obviously, you're going to have to present your work differently depending on the situation you are in.

The project meeting. This is typically a small meeting with the people directly working on the same project you are working on. In this case, you can assume that the others in the meeting know the project-level fairy tale, so you are going to focus on the smaller fairy tale describing what you are doing.

The large group meeting. This meeting includes people working on projects different from the one on which you are working. Even if you see these folks every week, you probably cannot assume that they remember from week to week exactly what you are doing, so you need to plan accordingly.

Regardless of which of these meetings you are having, you are still going to present your status in the same structure: 1) some context setting, 2) a discussion of the challenge you were addressing this week, 3) where you are in addressing that challenge, and 4) what comes next. (Sound familiar?) It doesn't matter if you're winging this entirely verbally, giving a formal presentation with slides, or communicating via interpretive dance, you pretty much must have all four parts.

So let's focus on some of the finer points in how to think about this.

The 1:1 Meeting

You can pretty much assume that your boss knows the overall project you're working on. If they aren't knee deep in your work, I suggest starting by reminding them of your overall task, e.g., "I'm working on our server performance," and then helping them recall where you were at the end of your last meeting, e.g., "Recall that when last we met (or at the last project update), I had been working on <something> and had gotten to <some particular point>." If they are knee-deep in your project, you can probably skip that. But even if they don't need that context, because, for example, you just met yesterday, I still recommend starting out with what you were working on during the time since the last meeting. For example, "My focus the past day/week/month has been on improving the throughput of our server." If this has been a long-term undertaking, then perhaps there has been progress reported at previous meetings, "And so far, we have 1) added multi-threading, and 2) partitioned the data structures to avoid too much synchronization overhead."

At this point, you've brought your boss up to date on the context in which this period's work happened. This is really important. All too often, it's easy to forget that while every teeny tiny detail is crystal clear in your mind, that is not the case for your boss. If you met two days ago, they may very well be on the same page as you, but a short reminder won't hurt.  If it's been longer, your boss is interacting with way too many people, they have been gone, they have been distracted, or (as is the case with me) they simply have a sieve-like brain, getting them focused on your details will let you make the most of a a meeting.

Now you can shift into "the problem." What specific thing were you trying to accomplish? It may have been an easy week: you had a straight forward implementation challenge; it may have been a difficult week: you were tackling a completely wide open, open-ended task. In either case, the problem/solution part of your meeting is where you can engage others in helping you, so think in advance of any areas in which you might want assistance. In explaining what you were working on during this period, be as specific as possible. You might use data you gathered to describe the problem in more detail. For example, "It was unclear where the next bottleneck was, so I spent some time profiling the server." This is beginning to blur the line between problem and solution, but I think that's actually just fine in this context.

So, the problem is really what you started out the day/week/month intending to do and the solution part consists of all the things you did to address that problem. Again, be specific, show data. If you spent the time reading papers, organize your reading into a structure, so you can say something more meaningful than, "I read a bunch of papers."  Instead, start with why you were reading papers (problem), "I did not feel that I had sufficient background in different ways to improve server performance, so I looked for papers describing similar tuning efforts. I looked in the following conferences for papers, and I found N papers that seemed appropriate."  That is what your problem phase looks like -- in your solution phase, report what you learned. "After reading them, I realize that performance tuning breaks down into three basic classes .... the first two don't apply here, so I skimmed those papers for techniques, but focused primarily on the third class, which was closest to our work. I identified the following three things that might be good next steps."

I picked this example, because I find that many times, students do need to spend time reading, but there is not necessarily a clear goal or perspective from which the reading happens. The more you can focus your reading on trying to fill a specific gap, learn something specific, or build background in a particular area, the more value you will get out of that reading. However, you can apply that same process to your weekly work.

Once you've presented what you've actually been working on you should find yourself in one of two positions. You might know exactly what needs to happen next and you lay that out as your final "Next Up" (happily ever after).  Or, you could use some help.  Then you invite discussion and brainstorming around your problem. Continuing our example, "The profiling didn't seem to indicate any one area where all our time is going, so I'm not really sure what to try next. I was hoping we might brainstorm ideas."

So now you have turned your "status update" with your "boss" into an engaged discussion. I intentionally started with this one, as it's likely to be the most detailed (and perhaps the most stress-inducing for some); all the others are simply subsets of the 1:1 update, so let's move on to them.

The Project Group Meeting

Your assumption here is that everyone knows the project you are working on, but may not know all the intricate details of the specific thing that you are doing. So, your context starts pretty much at sentence number two of the 1:1 context setting part: "Recall that when last we met (or at the last project update), I had been working on <something> and had gotten to <some particular point>." Assuming that these meetings are happening relatively frequently, that's probably all the context you need.  You can move right into problem/solution.

The problem/solution part of your status can be pretty much identical to what you might do in the 1:1 meeting. And it could lead to the, "Here is what I have to do next," or you might say, "I could use some help brainstorming next steps. Perhaps after all the status updates, I could get a few minutes from the team to do this?" If your project meetings are jam-packed, then ask who might be willing to meet at a different time to do this. I fear that students often feel that they must solve every single problem all by themselves, and that's not how research (or development) works.  It's a team sport. It is absolutely OK to ask for help; it just means that when others ask for help, you should try to step up and help. (It's OK to say, "You know I don't have much experience in this area, but I'm happy to do my best to help!") 

The Large Group Meeting

For this one, think of Systopia Standup. Before going into the specifics, I want to take a moment and explain why we have a large-group standup. When I joined UBC, after the students got to know me a bit better, the single most frequent complaint I heard was, "We have no intellectual cohesion. No one knows what anyone else is working on." TLDR: Our large-group standup was invented as a solution to this problem.  But let's ask the question that underlies that complaint: Why is it important to know what others are working on?  For some, the answer may be obvious, but for others it might not be, so I want to be explicit about this.

Why have large group status updates where hardly anyone really understands what I'm doing?

1. The people in the lab form the beginning of your professional social network. You may have absolutely nothing in common with them outside of the lab, but simply by virtue of being members of the same lab, you have a common experience. These people will show up over and over again throughout your professional career, and you never know when you might suddenly find yourself wanting their expertise, assistance, or advice. You don't have to become best friends, but you should take advantage of this opportunity to forge professional relationships with your lab mates. (You never know, 25 years later, you might find that you are their colleague, e.g., Will Evans and I were at UC Berkeley at the same time, and although we were not in the same research group [as I'm sure should be apparent], we knew each other well enough that when I intereviewed here, I felt that I had a colleague here that I knew].
2. Great research rarely happens in silos. Elegant solutions to real problems frequently require expertise in many areas or at least different perspectives from within the same area. If you have some understanding of what your peers are working on, you can figure out who to reach out to when you encounter an obstacle. Help need not only come from your own project participants or only from students with your advisor. Here are some examples of ways in which my students have gained explicit benefit from knowing what's happening around the lab: Ali and I were stumped on a proof for a paper on weighted GOSDT. One of us mentioned it in standup and the next thing you know, Mathias and Ali had come up with a lovely probabilistic bound on the problem we were trying to solve. Zainab is getting direct end-user feedback on her system. It's not a formal user study; it's not even a pilot. It's obvious to us that Paul is the right person to ask about this. (And I know that Nichole has also had similar experiences.)
3. Our field is HUGE. You can't possibly know everything happening in it or even all the techniques people in different areas use. Large group status updates give you a glimpse of what's happening other areas. These are an incredible learning opportunity.
4. Some day you are going to either A) be on the job market or B) be talking to someone who is looking to hire someone. The best thing that labmates can do for one another is promote each other. If you are in category A, would you not love it if your peers introduced you to their former managers who might be looking for someone just like you? Think how impressed your colleague in situation B will be when you say, "Oh, one of my labmates would be perfect for this." If you don't know what others in your lab are doing (and they don't know what you are doing), none of this can happen.
5. And speaking of that job market. I am 100% convinced that one of the reasons I was as successful as I was on the new prof job market (oh so long ago) is that I could actually talk to people in fields other than my own. I knew enough about what folks in my lab were doing and some of the big ideas others in the department were working on that I could ask questions of everyone, from theoretician to computer architect. You want to be that candidate, and you can't be that candidate by staying firmly in a silo and ignoring all that is happening around you.

End Digression

OK, so let's say you now understand why large group status updates are useful. How do you do a good one? Tell a very short fairytale (a nice short story is way better than and endless list of tiny things you accomplished).

Context: Recall that I work on the Awesome Server Project.

Problem: This week I was trying to figure out how to improve throughput on the server. We are handling X requests/per second and the state of the art systems seem to be able to handle 2X requests/second.  We don't necessarily have to match that performance, since we do This Awesome Thing. But a 100% performance penalty will never be considered worthwhile, so we need to get performance to within at least 10% of state of the art.

Solution: This week I tried removing every other line of code. Good news: Performance was great. Bad news: The server no longer works.

Up Next: I think I'm going to be a bit more strategic in what I remove; I'm going to do some dead code elimination to see if I can improve the iCache hit rate, since I took some measurements and I'm getting truly awful results for that.

It's just another fairy-tale, but one focused on your activities for the week, not your overall project, not your dissertation, just the thing that has been keeping you up at night this week.

Wrapping Up

Here is a tiny table to remind you how to think about the four parts of the fairytale in different settings.

	The 1:1	Project Update	Group Update
Context	Remind, Recall, Focus	Recall	Recall (Big Picture)
Problem	Specific (maybe with data)	Specific	Importance
Solution	Specific (include data)	Specific (include data)	Overview
Next Up	Brainstorm or Plan	Specific Plan	High-level Plan

How to Present your Research: Part 2: Visual Materials

How to Present your Research: Part 2: Visual Materials

(I wrote a related post a long time ago about use of visual materials in teaching. It is related to what's discussed here, but is focused specifically on presentations in the classroom. At the same time, I would argue that whenever you are presenting your work, you are, in fact, teaching.)

About a millisecond after you are asked to give a talk, I'd be willing to bet your attention turns to slide preparation. While I too, almost always, use slides when I give a talk, I do want to point out that there are fields where this it not common. There are fields where talks are people (literally) reading their written work out loud and fields where people give talks without any kind of visual aids.  If you're reading this, I am guessing that you might find this anywhere from surprising to shocking.

Once you have gotten over the shock, however, perhaps we should ask ourselves why we use visual aids. I'm completely serious -- why do we feel the need to have slides to accompany our words?  There are a few reasons:

1. To help illustrate complex concepts.
2. To remind yourself what you want to talk about.
3. Because it's expected.
4. To leave behind an artifact that summarizes your work.

I hope you won't be shocked if I opine that 1 and 2 are good reasons, and that 3&4 are not good reasons. (The artifact you leave behind is, in fact, your paper!  Or, today, perhaps you've been asked to produce a short, e.g., 2-minute, video overview.  This is a much better advertisement for your work than a slide deck.)

If you believe that you produce slides purely for #1, let me ask the following: if you are merely trying to illustrate complex concepts, why do you have slides for every part of your talk (including the introduction and thank you)?  Surely those are not complex concepts?  In other areas, you might see talks that are only occasionally punctuated by images or visuals, which really do illustrate a concept -- they show a picture of a novel experimental apparatus or some results or some particularly complicated concept.  However, there are not necessarily slides to accompany every single part of the talk. In our field, that is not the norm.

So, I ask again, what is the purpose of the slides?

I believe that most of the time, whether we admit it or not, slides are mostly to help us remember what we want to say or talk about as well as to remember how we decided to talk about it. Once you embrace this concept, you buy yourself a great deal of freedom in what you place on your slides. Your slides no longer need to parrot your talk. Instead, they can enhance and embellish your talk. Almost ten years ago, I decided to switch from a fairly conventional slide style where words were primary and images secondary to a style with as few words as possible. Two things happened: First, it started taking me MUCH longer to prepare slides for a talk, because it took forever for me to find exactly the right image to convey what I was trying to convey. Second, I began writing much more extensive speaker notes, frequently, because I like strategic animations, and I want to make sure I use them at precisely the right point in the voiceover. (Sadly, I almost never look at my notes while giving a talk; I ad lib almost completely. Thus, I need to go over my slides enough that I know where I'm supposed to click and hope I get it right. This usually works well the first time I give a talk, because everything is fresh in my brain; when I pull out a deck a year later and "tweak" it and then give the talk, I don't do nearly as well.)

Enough rambling about me, what advice do I have about preparing visual materials to accompany a talk?

1. Do keep in mind that the purpose of the visual materials is to accompany the talk, not replace it.

<flame>

One of my greatest frustrations as a teacher is when students believe that the slides are a replacement for lecture. I do not intend them to be. I tell students this. Yet, time and time again, students who cannot be bothered to attend class complain that the slides sometimes are incomplete. That is explicitly by design so that in class we can discuss and probe things!

</flame>

2. If the slides merely repeat what you are going to say, why should people attend your talk?

3. Think hard about how can you use a visual aid to:

A) Burn an image in your audience's brain that will immediately conjure up you and your work (i.e., make your work memorable).

B) Make something abstract concrete

C) Simplify a complex concept

D) Connect multiple concepts 

4. Use slide real estate to communicate with the audience; use notes to communicate with yourself (although it's good of the slides themselves trigger you to remember most of what you want to talk about).

5. Remember that you want the audience, for the most part, listening to you, not frantically trying to read paragraphs of prose on slides.    

How to present your (Systems) Research: Oral Presentations (Part 1)

It has been a long time since I wrote anything for my blog. I have a bunch of half written things, but let me see if I can actually write a complete post!  Well, not a complete post - how about the "first in a series" post?  I'm running a workshop this summer and it's more importanbt that I get little pieces of this out than I finish it all at once, so welcome to:

Part 1: Introduction and The Fairy Tale

It took me a long time as a professor to realize that I spent a great deal of my time working with students teaching them to communicate. Most of our students enter graduate school with excellent technical skills, and most have learned how to teach themselves additional technical skills. However, they have not necessarily been taught A) how to find a good research question worth pursuing or B) how to communicate what they have done effectively. Today's post is about the latter.

I've already written about writing (i.e., how to write a dissertation), so let's talk about how to present orally. There are two different dimensions that we can use to describe presentations: by type and by content. We'll do both. Let's start with the different types of presentation that largely differ in length, which leads to a corresponding difference in the level of detail that can be presented.

1. The Elevator Pitch: this is what you can tell someone in an elevator ride when they ask, "So, what are you working on?" It is also the 1-slide presentation you might give as part of an introduction. In Margo-speak, this is the fairy tale (an idea that will be familiar to anyone who has taken Harvard CS261 or UBC CPSC 508 or to anyone with whom I've written a paper); I'll get to that in just a bit.
2. The Status Update: This is typically presented to someone who knows what you are doing and your goal is to add to their understanding of the project by sharing not simply what you did recently, but what you've learned, how that has advanced the project, and how that leads to next steps. In other words, how did the things you've done in the current time period move the project forward, and what obstacles have you encountered.
3. The Work-In-Progress Talk (WIP): These are perhaps the most difficult. They are approximately 5-minute talks designed to summarize what you are working on now. Many conferences have explicit work-in-progress sessions. However, for years, the majority of NeurIPs presentations were 5-minute Spotlight talks, which were supposed to tell the whole story of a research project. For the most part, you best you can do here is convince someone to read your paper; it's difficult to relay too much technical content in five minutes when you first have to lay out the problem space.
4. The Conference Presentation: This is usually about a 20-minute talk (at least in my field). You get to describe the problem, present your solution, and demonstrate how well your solution works.
5. The Full Talk: This is typically a 45-60 minute talk (although even if you are told 60, I recommend 45 leaving plenty of time for questions). In many ways, this is the easiest talk to give, because you have the luxury of time, and you can tell the whole story.

Let's now disect a talk into its constituent elements (not all of which can be crammed into every talk).

1. The story: I will refer to this as the fairy tale, and I'll talk about that below.
2. An outline: Depending on the length of the talk, you often need to provide some structure, so the listener knows what's coming and how you are going to tell your story.
3. Motivation: What is the problem you are solving and why is it important? You might think it's important, but that doesn't mean your audience will care about it. Your job is to convince the audience that they really care. If you fail to convince them of that, it's going to be quite difficult to keep them engaged, even with the best work.
4. Your work: So, what exactly did you do?
5. The evaluation: How well did your solution work? Ideally you show both the strengths and weaknesses of your approach (although the latter is far too frequently swept under the rug)
6. Related work: How does your work fit into the landscape of existing work?
7. Conclusions: A good conclusion not only repeats what you've said already, but draws some larger takeaways and implications of your work.

If you have read my blog post on writing a dissertation, these parts should all appear familiar.

Now we can examine which elements go into which talks.

 

	Elevator Pitch	Status Update	WIP	Conference	Full Talk
Fairy Tale	✅	✅	✅	✅	✅
Outline	❌	❌	❌	✅	✅
Motivation	✅	✅	✅	✅	✅
Your Work	❌	✅	✅	✅	✅
Evaluation	❌	❌	✅	✅	✅
Related Work	❌	❌	❌	✅	✅
Conclusions	❌	✅	✅	✅	✅

The astute reader will notice that the fairy tale appears in all talks, so let's start there. Humans love narratives. They like stories. They do not like being spoken at -- they want to be engaged and drawn into a compelling narrative. Therefore, if you want to truly engage your audience, you need to tell them a story. I claim that the fairy tale is the ultimate story and is particularly well matched to presenting research.

The Fairy Tale

A fairy tale follows a predictable pattern. It begins with, "Once upon a time." This is context setting. For research, what is the relevant state of the world (technology) from which your work begins? For example, "Computation is moving into the cloud," for work on cloud computing or data center operation. "Eighty-five percent of the world's population own cell phones," for work on mobility or phone apps. "DRAM accounts for 30% of the cost of most data centers today," for work on far memory. "Data centers alone account for 2% of all electricity consumption in the world, and this number is predicted to grow to 8% by 2030." for work on energy efficiency. Notice that this also serves as a teeny bit of motivation - it tells the listener both how to place your work in context but also why your work matters.  Contrast that opening with, "We present a better algorithm for doing X."

Soon after the context setting, a fairy tale introduces us to the villain to be vanquished. This corresponds to the problem we are trying to solve. Try to be precise -- poor performance is a weak villain; making people wait or wasting energy or using resources inefficiently so things are expensive are more compelling than, "We make something X% faster."

And for every good villain, we need a hero -- that's your solution!  How does your solution address the problem you just introduced?  In your initial fairy tale, you need not go into great detail here, just enough to give the listener a flavor of what you've done.

Finally, fairy tales end with a, "happily ever after." What good will come from your work? How does your work make the world better? How does it change that context in which your work took place? Why should the listener care about the work you've done.

So, the minimum story of your work is simply four sentences: the "once upon a time," the villain, the hero, and the "happily ever after."  It's really that simple -- you can write an abstract for pretty much any paper in 4-8 sentences if you can identify these four key points.  Try it!

For a well written paper, you can read the abstract and extract exactly these four elements. For a badly written paper, you will have to wade through at least the entire introduction (and maybe more) before you can extract these four ideas.

So, the key take away for this post is: master the elevator pitch by having a crisp, clear, and easy to understand statement of the four parts of the fairy tale.