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?
- 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].
- 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.)
- 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.
- 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.
- 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.
Wrapping Up
| 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 |
No comments:
Post a Comment