Effective collaboration and communication are the key to the academic success of both the advisor and the student. Unfortunately, in most cases the advisor can only afford to schedule the regular 1:1 meetings weekly or bi-weekly rather than daily. This means that in a month, a student merely gets a handful of chances to communicate with the advisor. It is thus worth considering how to optimize such meetings to achieve effective communication between students and advisors.
Actually, right now this exact topic is crucial for me. Just in the past one and a half years, my group has grown to eight graduate students (including incoming ones for the next year) plus several undergraduate and gap-year interns. Almost every student has his/her individual project that needs dedicated time to meet and discuss. A dozen meetings are thus held every week, and each has to be limited within only 30 to 45 minutes. In such a scenario, communication efficiency naturally becomes a key priority.
After thinking from both perspectives of advisors and students during this unique time when transitioning between the two roles, I would like to share the following suggestions based on our recent experiences, with the hope that this first-hand experience could be a useful starting point for new graduate students and new faculty members.
Set up a suitable style at first
Before diving into any specific suggestions, I would like to emphasize that everyone has different preferences and working styles. The following may not apply to all cases. It is therefore extremely important to get to know each other, and set clear expectations at the beginning of an advisor-student relationship. For example, the student may want to know what the advisor’s mentoring style is, what project milestones and paper deadlines to foresee through a year; the advisor also needs to recognize how independent the student is, when and how much time in a week to expect the student to work. And it is typically not a bad idea to call for a direct conversation, rather than waiting to observe and slowly adapt.
Focus on long-term roadmaps and immediate next steps
Many junior students like to prepare long and detailed progress reports to describe everything they did in the last week, as they are worried that the advisor may think they did too little. I argue that this is inefficient. To get the most value from the precious meeting time, the student should spend more time seeking for advice about what they should do next. This is the exact time to learn from the advisor how to think through research problems and sketch out project plans at the high level. A better approach is to have the student briefly summarize where they are now in the overall plan, what issues block them, and what the next plan is. Then the advisor can start to provide comments and advice.
There are generally two types of discussions. At the early stage of a project, it is crucial to quickly establish the overall research roadmap with well-summarized high-level anticipated goals. A junior student may propose a promising idea, but usually not foreseeing all the design issues and the full potential. The advisor can help thoroughly analyze the challenges and opportunities and better identify the expected key contributions. During the investigate stage, more time should instead be spent on the immediate next steps about what to focus on in the next week, such as what priority order to apply among multiple things, what to adjust to deal with negative results, and what additional exploration could be done to make the work more complete.
After the meeting, the student should have a clear picture about what to do next, both in the long term aiming at the final paper, and in the coming week before the next meeting. It is always helpful to summarize a list of to-do tasks after the meeting, and use it as a record that can be closely followed and checked again in the next meeting.
Save details to offline writing
If the meeting is all about high-level ideas, when shall we talk about the equally important underlying details, such as theorem proofs, model specifications, workflow descriptions, and concrete case studies? My suggestion is to save all these to offline. In other words, the student should write detailed and comprehensive documents containing all the necessary details to support the high-level points discussed during the meeting. The advisor can check the documents either before or after the meeting.
I want to emphasize that these documents need to be as detailed as possible, and different from the concise meeting slides that only summarize the key points. At first glance, this may seem quite inefficient as writing is always considered time consuming. But several key advantages make it worth the effort.
First, when writing things down, the student gets a chance to organize the ideas and review the overall design end-to-end. It is not uncommon to miss something until writing everything down and checking it thoroughly. Second, it will be easier for the advisor to use sufficient offline time to look at the details carefully, rather than under the time pressure from the tight schedule of back-to-back meetings. Third, this is also a good time for the student to practice writing. If you find it difficult to clearly explain the complicated design details using text and always want to directly talk, remember that you get no chance to “talk” with your paper reviewers. Finally, many of the paragraphs and figures in these internal documents will likely be reused or directly copied into the final paper anyway; your time is not wasted.
Learn to do in-depth analysis
Another useful skill that the students should have is to handle simple issues by themselves, saving the meeting time for more important and difficult topics. This means that a student should learn how to independently conduct in-depth analysis to resolve encountered issues, or at least to collect sufficient detailed data and evidence for the discussion in the next meeting.
One example is when the experiment result diverges from the original expectation. Rather than waiting until the next meeting to report this to the advisor, the student should proactively identify plausible reasons by analyzing the data. One technique is to zoom in to the next level of details, or to always measure one level deeper. For instance, when the latency distribution of network packets shows a long tail, one can select several representative packets in the tail and check their routes to see if there is any pattern (zoom in from all packets to individual packets), or if there is any common hotspot along these routes (zoom in from entire routes to individual links).
Reach out for help
The final advice, which is also the most important one, is to actively seek help when needed. It is never the case that a single person can do everything. After you have tried every way you can think of (such as those in the previous suggestions), it is time to talk with your group mates or directly to your advisor for help. There is no shame or embarrassment to admit the problematic scenarios. And you do not need to wait until the next meeting. Send a short email, or just stop by the advisor’s office to have a 5-minute chat. Maybe one or two words can shed some light, and allow you to make more progress rather than be stuck in the same place. There are always ups and downs in life and in research. Remember that you are not alone; the advisor is here to help and support.
As a summary, the key to an effective meeting is to make a good plan for time and content. Our experience suggests the following. Review the current progress quickly. Spend time mostly on advice for improvements and plans for the next steps. End the meeting with a summary of to-do tasks. Save easy and minor issues as well as detail checks to offline. Learn how to analyze problems independently and comprehensively. And also actively reach out for help when needed.
About the author: Mingyu Gao is an Assistant Professor at the Institute for Interdisciplinary Information Sciences (IIIS) at Tsinghua University. His research interests lie in the fields of computer architecture and systems, including efficient memory architectures and scalable acceleration for data processing.
Disclaimer: These posts are written by individual contributors to share their thoughts on the Computer Architecture Today blog for the benefit of the community. Any views or opinions represented in this blog are personal, belong solely to the blog author and do not represent those of ACM SIGARCH or its parent organization, ACM.
