Most of the time, I’m more than glad when a project is all done and written up. Research projects can have this tendency to take too long and require a lot of breath towards their end. In a hurry to get it over with, it’s easy to forget to look back and evaluate what went well and what didn’t.
In our scientific work, we are used to progress step by step. Each time an experiment doesn’t turn out the results we expected, we adjust methods and paradigm a little and try again.
But when it comes to the way we organize our teams and our projects, we often don’t show the same scrutiny. Maybe we’re just fed up with that project. Or it’s all the new stuff that’s already piled up. Either way, we forget to sit down with the project members and evaluate or debrief.
Although there are detailed schemes available, a project debriefing can be really simple. All you need to do is ask yourself, and your team, two really short questions:
What worked? And, what should we do different next time?
That’s all. Easy. And note, it’s about the positive just as it is about the negative. Just like any good feedback should be.
The two questions can apply to any aspect of organizing your projects, but here are a few examples:
Communication and supervision. Did everyone know what their responsibilities were, and did the supervisor delegate well? Was conflict dealt with adequately? What kind of communication worked well (email, skype, personal meetings…)? Was help available when needed?
Writing. Was authorship handled properly, e.g. did everyone know early on where they would land in the authors’ order? Did manuscript reviews go smoothly between all authors? How can writing together be improved?
Lab handling. Did everything work out with the technical setup? Are there any procedures that need to be changed, and communicated to others? Which procedures were good, and can be distilled into workflows that others should follow?
Of course, there may be many other aspects that merit discussion. Then again, it’s not necessary to make it a therapy process. Just don’t skip the debrief all together, and identify a few good things to keep, and the bad ones to throw out.
In some cases, a project evaluation may be part of the conversation you have during the personal evaluation meetings with your individual team members. Yet, if a project involved several people, debriefing together with the entire project team will provide more valuable input, and allow clearing up any hickups that may still await closure.
Do you have a routine for project evaluation? Tell us about it in the comments!
Peer review is the horror of many a PhD student who submits his or her first paper. Seeing their colleagues’ frustrations and hearing about impossible reviews nurtures a fear that painstaking work will be crushed by that one email from the editor. Therefore, a PhD’s first submission shouldn’t be the first time they come in contact with the peer review system.
Students will only get acquainted with peer review if it’s a topic in the lab. This has two sides: reviews we get, and reviews we write.
Learning to deal with the reviews we get
One of the most important things about reviews is to talk about what they (can) do to you. If you haven’t cried your own tears, I am sure you know someone who has. Reviews can be devastating. So, it’s helpful to talk about how one can deal.
Read it once. If it makes you choke, save it, and leave it for three days until you go back to it. As Bradley Voytek puts it in his lab philosophy: You are not your science. You are not your science. You are not your science.
Attack the review point by point: brake it down into its single points. If the reviewer did not structure his points well, do it yourself. Isolate each single point that requires some action. This reduces the overwhelm of the many points that seem to be wrong with the paper.
For each point, assess whether and how you can address it.
Start with one point. Then work yourself through the list.
There appears to be a trend for editorial decisions to become more dramatic. What used to be a major revision is now often a reject with permission to resubmit. And what used to be categorized as a minor revision is now often a major one. If you’ve written a number of papers, you don’t even notice these things anymore. But first timers do. Reject feels like a killer to them. So they should learn from their supervisor that the gravity of a decision letter can only be assessed by checking whether what the reviewers want can be fulfilled (or rebutted) or not.
Learning to write reviews
It helps a bunch to have seen other reviews and to have written some reviews to be able to put one’s own reviews in perspective.
Besides, being able to give scientific criticism in an adequate manner should be one of the major aims of scientific teaching.
There are two approaches I take in my lab: discussing reviews we get ourselves, and writing reviews.
Discuss the incoming: reviews we get
There are several things to learn from discussing reviews of the lab’s papers.
Content: Learning to expect what reviewers want to know. This is important when writing a paper: we try to foresee what may be critical points, and answer them before the question comes up. But it’s just as important for learning to write reviews: What kind of questions appear often? What do other reviewers look for? How detailed are they in their criticism?
Style: I can’t stress the style issue enough. All those reviewers who yell at us must have grown up somewhere. Make your lab a place that brings up a different kind. You can discuss positive examples — reviews that are clear, respectful, concise and precise. And contrast them with negative examples — reviews that are difficult to understand, lack respect, are lengthy, and don’t tell you what the reviewer wants changed.
Discuss the outgoing: reviews we write
I once read the suggestion that all reviews should be done by PhD students, because they know what they are doing, know the latest literature, and are motivated. I guess it would be rather demotivating if the boss always passed everything down. But more importantly, PhDs should not be left alone with their reviews.
I ask students to write their first review in the second year. For the first few, I do the entire review in parallel. I read their review draft and discuss points that were difficult or things that I will add that they didn’t see. Of course, all the style points are also part of the discussion. Many journals let you enter the student’s name in a designated field. If they don’t, it’s good style to acknowledge the student in the note to the editor.
When a student has more experience, both in her scientific field and with writing reviews, I interfere less with their work. They can then decide themselves whether you should read the paper and help them, and discuss points they are insecure about.
And finally, one great advantage when students write their reviews is that they can read what the other reviewers said. In my experience, this is a really important thing. It feels great to detect your own points in someone else’s review, too. It feels great to see that you did a better, more thorough job than other reviewers. These experiences build confidence.
If you have thoughts to share, or links to good resources to teach peer review, do leave a comment!
There are many resources that deal with peer review. These are a good start for students before they write their own:
Benos, D. J., Kirk, K. L., & Hall, J. E. (2003). How to review a paper. AJP: Advances in Physiology Education, 27(2), 47–52. http://doi.org/10.1152/advan.00057.2002
Remember your own PhD? Ever felt lost and wished someone had told you where it’s going? While you probably can’t avoid that your PhDs will be frustrated at times, you can do a lot to help them stay on track. Regular evaluation meetings make recent progress explicit and map out what to focus on beyond the immediate daily chores. They can go a long way in guiding your team members towards a successful PhD.
It is my impression that many PhDs are not receiving sufficient support from their supervisors and/or mentors. Admittedly, a PhD is the highest academic achievement one can reach, and supervisors should expect the aspiring student to be driven and goal-oriented.
Yet, the PhD project can be a swamp into which the candidate slowly sinks, not noticing at first, and becoming aware only when it’s potentially too late to pull herself out. We’ve all seen students procrastinate, get lost in detail, losing focus, and missing the big picture.
At the same time, as PIs and supervisors, we must ask ourselves what our responsibility is toward our PhD students. I think that what a PhD should learn is different today than it may have been some years ago.
In most (if not all) countries, we’re filling many more PhD positions that we can use as postdocs, let alone professors, later on. The internet is now full of advice about how to get out of science, an option that looms not just for a few who simply aren’t cut out for it, but instead becoming more and more normal, given the barren job landscape in academia.
Therefore, it’s not enough today to teach a PhD student some experimentation and analysis methods to become academic experts. Rather, we must make clear to them how they can advance their skill set in a way that gives them flexibility within and outside of science once they leave our lab.
Evaluation meetings: sign posts along the PhD
In my lab, I’ve implemented evaluation meetings. I hold them with each person every 6 months, and every three months for new lab members. Here’s how they work:
Predefined structure: I’ve created two mindmaps, one for feedback to me (download), and one for the student’s/employee’s development (download) (I’ll say student from hereon, but it works the same with Postdocs). We go through all branches of those mindmaps in a meeting.
Come prepared: The meetings are scheduled well in advance, and the PhD is allowed to use work time to prepare the mindmaps.
Look back, look forward: The student continually develops the mindmap, adding new achievements with each evaluation meeting in green color. Things that are goals at the time scale of the entire PhD are entered in red. Things that are scheduled for the next 6 months (i.e. until the next evaluation) are colored yellow.
Enough time: I schedule 90-120 minutes. This may sound a lot, but it creates the space for a serious, unstressed conversation.
Setting goals and timelines
In the beginning, there is an all red mindmap. I’ve filled it [with things that I consider important][mindmap_development] to acquire during a PhD in my lab. In the first meeting, students tend to have difficulty with planning for their 3 or 4 years to come, but we discuss what they would like to achieve, where they think they want to go after the PhD (research, industry, …), and what building blocks might be important on the way, such as analysis and experimentation skills, writing skills, teaching, and networking. Although many goals are important for every student, no two maps are the same, even after the first meeting.
Setting short-term goals for, say, the next 6 months, is usually much easier than setting long-term goals. They are, of course, often directly related to the project, but can be independent, too: language courses, conference visits, networking…
Continuing goal development
Because meetings are held regularly, goals can be added and adjusted.
As a supervisor, I’ve learned that I have to focus on different areas in each phase of my student’s PhD. For instance, when I held my first meetings, I felt that my students should all develop long term ideas about where they wanted to go at the end of their PhD, so that we could plan well ahead what kind of network we should attempt to build for them. I found that my students just didn’t think the same way, and that talking about these kind of things is much more appropriate at the end of year two than at the start of year one.
But at every meeting, you can give impulses, something that often gets lost in day-to-day interaction.
One thing I particularly like is that PhDs add all new skills, achievements, and events that happened since the last meeting into the mindmap, and color green what was previously yellow and red. Over time, the branches grow with programming skills, studies, papers, conferences, people they have met, duties they have taken over in the lab, and so on. More than once I’ve heard a PhD say “wow” when they looked at their map.
It’s almost too obvious to say, but going over these new blobs in the mindmap is a good opportunity to give positive feedback (something that seems to happen too seldom).
To the student
Because the evaluation meeting focuses on the bigger picture, it is a place to give feedback about areas that need improvement. Because this is known in advance, the conversation can be held respectfully even when something unpleasant needs to be discussed.
To the supervisor
Don’t be fooled: even if you think you’re one of the cool guys, and get along with everyone so well, relationships change when you are the PI. You’re no longer on the same level as your group members. This results in a loss of communication. The longer you are the boss, the less people complain directly to you. So you have to try and make it happen. In my lab, the evaluation meeting has feedback to me as a fixed point on the agenda.
I’ve learned that just asking whether the student is “ok” usually does not result in honest feedback about what bothers them. It does for some, but not for all. I’ve been using two “techniques” (sounds horrible) to try and encourage feedback:
Scales: This is a technique often used in therapy and coaching. For each area I ask feedback about, I also ask for a rating between 1 (really bad) and 10 (really great). In theory, any number that is not 10 means that there is room for improvement on your side, and so you inquire where the number comes from; or what would have to happen to increase it by 2. In practice, I’ve been laughed at for asking how an 8 could become a 10, because “I can be just happy about an 8”. Such non-linearities notwithstanding, numbers are a great way to get a quick overview over the areas that need discussion.
3 things: After I had not gotten much feedback for a while, I started using the questions like These (3) things I would really like to get rid off…, These (3) things should really be continued in the same way…, and These (3) things could improve our group….
I started by saying that many PhDs don’t receive enough quality supervision. I think that evaluation meetings are a really good tool to supervise. They enforce feedback between supervisor and student; they encourage by looking at past achievements; and they adjust the focus on some longer-term goals so that the student doesn’t get lost in details for years.
I’m curious to hear your opinion about this post. Do you hold evaluation meetings? What do you find important? Have you had good or bad experiences? Leave a comment below!
You can download my mindmap templates in different formats here. They were created (and thus look best) in [iThoughts][web-ithoughts].
Evernote is not only great for personal note-taking and organization. Because notes and notebooks can be shared, Evernote is also great for collaboration in teaching. This post looks at some use cases.
There are many online tools to provide materials for teaching and collect contributions by students. My university offers at least two. Many online tools work in the browser, and uploading stuff can be a pain. I’ve found Evernote to be a great alternative.
Sharing the course notebook
I create a notebook for the course, and then share it with all attendees. For this purpose, they must register with Evernote using an email address of their choice. Students can use the free plan, so no cost is incurred. I share the notebook with the email address they send me. Done.
Because sharing requires entering the email address in Evernote, I haven’t used Evernote for lectures with a large number of listeners. However, interaction is usually limited in lectures anyway. Evernote unfolds its potential in smaller courses in which lots of materials need to be shared.
Using Evernote for regular classes
The greatest advantage of Evernote is that it integrates with almost all major platforms (Linux excluded, unfortunately, though there it works in the browser as everywhere else). My biggest motivation for using it for teaching is that all my information is either already in Evernote, or I can easily move it there. It simply integrates perfectly with my computer environment and my workflows.
Providing a course outline
Before I start a course, I create notes with the course overview and course rules. Then I create a note for each session. Each note simply outlines the general structure of what I want students to fill in when they prepare their contribution:
The names of the students responsible for the session
The objectives of the session
The session plan
When they prepare their session, students fill in this grid. It helps them to know what I expect them to prepare.
I also use these notes to give an overview over the course in the first session. I directly write into each session’s note who will be responsible for each session.
If you name notes beginning with an exclamation mark, they will be sorted to the top when sorting notes alphabetically. Similarly, numbering sessions will result in the correct order then.
It’s hardly worth mentioning that both you and your students can upload whatever they want to share. I make all papers used in the course available. Students add their own papers, their presentations, photos of flipcharts, metaplan posters, and the chalk board, content they find on the web, and whatever else might come up in the course.
It is worth mentioning that students’ upload goes against your account. This means they can upload large amounts of stuff, even if they are using the free account. That is, as long as you have a paid account (both professional and business accounts come with unlimited upload nowadays).
Using Evernote for research classes
In our Psychology BSc and MSc programs, we offer courses that teach students hands-on experimental work. In these courses, I use Evernote to collect everything, just as in a regular teaching course: relevant papers, programming code for the experiment, etc.
In addition, students save their data files, notes about data acquisition, and code for statistical analysis. Some also use the platform to exchange ideas and have discussions.
Because Evernote synchronizes automatically, students don’t have to remember to download anything. Their materials are just always there. It’s practical.
Using Evernote for individual student research projects
Finally, I use Evernote to share materials for BSc and MSc thesis projects. In the end, this is no different from using it for our group’s regular research projects (I’ve explained in an earlier Evernote Hacks post how we organize Evernote for this purpose).
I ask my students to collect everything in their project folder: meeting notes; notes about their experiment; notes about data acquisition; etc.
This way, if you ever want to use the work of your student in a paper, you’ll know where to find everything. If you still have to save data elsewhere, such as large data files, create a note that states where the data are. This is very helpful if you are searching several months (or years…) later. Really.
Everything in one place
In short, all my teaching is in Evernote.
I always know where to look. Finding stuff is easy, because everything is in one place.
Copying materials from an earlier course to create a new one is as easy as marking some notes and copying them over to the other notebook.
And with all of that stored information, Evernote’s many features are always at hand: sharing notes with new people, sending stuff by email, working on documents right out of Evernote, and search capabilities.
Have you used Evernote in your teaching? Good or bad experiences? I’m curious! Let me know in the comments…
Writing well is a continuous challenge. It’s even more difficult when writing in a non-native language. Although I’ve been writing papers for more than 10 years, I am still learning how to write better with every paper I read or write. I figure, there’s all the more to teach the students I work with.
Many students have great difficulties with putting their thoughts on paper. Writing has many pitfalls. Grammar can be complex, especially when writing in a foreign language. But it’s just as hard to structure the logic of sentences, paragraphs, and an entire paper.
Given that papers are what the world sees of our work, scientific writing is our bread and butter: we’d like our papers to be perfect. As the group head, we have to do our best to teach our students well.
I’ve found that many writers make similar mistakes. And I’ve found that telling them once or twice doesn’t usually do the trick of making sure these mistakes don’t show up in their future writing. This has led me to prioritize writing in my group by implementing regular lessons on different aspects of writing in our group meetings.
Making writing a priority in your lab
#1: Weekly grammar lesson
For some time, we had a 3-5 minute lesson in the group’s weekly meeting. Each week, a different group member prepared the lesson. In the beginning, we used a book that described common grammar and word choice mistakes in short, comprehensive chapters. Later, we picked questions that came up during reading or writing; the person responsible researched the solution to our question by searching on the internet, or by asking a native speaker.
#2: Weekly sentence analysis
Another great way to learn about writing well is to discuss bad sentences. There is an abundance of bad sentences in published papers. Even the table of contents summaries of Science Magazine have some gruesome grammar mistakes. It’s actually quite fun to try and spot them, and we’ve often had a good laugh about what the sentence did say, compared to what it was supposedly intended to say.
An even better source of bad sentences are the writings of our own group. Whenever I write or revise, I copy sentences (including my own) with typical errors for the next group meeting.
With each sentence, we first let everyone take a shot at what’s wrong. We then discuss why it’s wrong, and how the sentence could have been written better.
Discussing bad sentences lets us go beyond just word use and grammar mistakes, and we look at sentence clarity, logic, word order, etc. One can even look at entire paragraphs, though then 3-5 minutes won’t do it.
As a result of our writing-better-sentences practice, I now often get better sentences from the start when I revise papers we write in the group. And when there are errors, I just have to give a short reminder of what’s wrong.
#3: Make an assessment of writing style part of your journal club
Sometimes, you read a paper that just reads well. It’s worth losing a few words about it when the paper is discussed in the journal club. Ask the presenting student to pinpoint what is so good about the writing. Rather than looking at details in grammar and sentences, the points raised when talking about well-written papers usually focus on the large-scale organization of the paper: the flow of logic; the way the discussion picks up the topics that the introduction raised; the order of topics in methods and results; clarity of writing; organization of figures; etc.
Making writing style a topic in the group meetings emphasizes that a well-written paper can shed very positive light on a research group. It encourages team members to make improving their writing a goal for themselves.
#4: Discuss reviews of your group’s papers
Discussing peer reviews is probably the highest level view on writing you can have with your team. Seeing reviews will prepare more junior scientists like new PhDs for what to expect when they submit their work. They get to know the tone of reviews and learn to distinguish harmless from serious criticism. As a consequence, they learn to anticipate which parts of their own paper may be prone to criticism, so that they can address potentially difficult parts of their study accordingly already in their first draft.
There’s a lot to learn for every PhD student, and still for many Postdocs. Even as experienced writers, we can still improve. Showing that writing is a priority, and having short but regular writing lessons in your group, can boost learning.
How do you improve writing in your group? Comments, tips, and experiences are welcome!
Some books I’ve found useful in learning how to write better:
The Reader’s Brain by Yellowlees Douglas: A book that takes a close look at each hierarchical level of a paper: sentence parts, sentences, paragraphs, paper as a whole. Comes from a neuroscientific perspective and bases writing tips on how people read. A bit too much of that, for my taste. But the writing tips are really good. It also features an appendix of “everything you need to know about English grammar”.
The Elements of Style by E.B. White & William Strunk: a classic of English grammar and writing. Newer texts criticize this book here and there, but by many it’s considered the gold standard. It’s more compact that Bugs in Writing, but could also serve as the basis for weekly lessons. If you buy it, do not be surprised by its size: it’ll fit in your pants’ back pocket. (No, this doesn’t mean that there’s little in it. It’s small print.)
When your group grows, two trends make being available to the team more difficult: you are more often gone from the lab, and an increasing number of team members multiplies the requests for your time. It can be difficult to find the balance between making yourself available, following your calendar, and getting your own stuff done.
I recently interviewed candidates for a Postdoc position in my lab. One of the questions I ask is what the candidate expects of me as a supervisor. To my surprise, two candidates replied that they would like to get a response to email within 3 to 5 days. One of the candidates paused, looked out the window, and then carefully said: “Yes, that would be nice.”
Why it’s important to be responsive to your team
Advancing a science career not only brings with it a team that works for you. At the same time, we are more and more absent from the lab, sitting in administrative meetings, giving talks, visiting conferences, or finding some quiet to write.
As the head of my team, I hope that my team members will make the right decisions when I am not there. Yet, from the day to day experience in the lab, I know that there are often situations in which a PhD or Postdoc would ask my opinion if I were available. On the one hand, it’s nice if they don’t, and leave me to concentrate on the stuff I’m doing. On the other hand, it’s hard to know when it would actually be critical that I make a decision myself, and detrimental if the team member decided not to ask, fearing to disrupt my work.
First and foremost, not responding to a team member’s inquiry communicates that your priorities are elsewhere. People quickly feel disrespected, whether this is what you intend or not. Beyond that, holding off responses for several days can delay important work of the team, make you miss opportunities, or force your team members to make potentially disadvantageous, if not right-out wrong, decisions.
Some tools you can implement to help you being available
Even if availability appears unproblematic in your group right now, it could prove helpful to install some tools before your schedule becomes unexpectedly busy. Here are some ideas.
Regular meetings hold off ad-hoc disruptions. Many things don’t need to be solved at once; but they also can’t wait several weeks. Similarly, many potential questions are foreseeable. If you schedule short weekly meetings, or have open time slots that can be booked by your team, then you’ll have less interruptions during other times.
Make your cell phone number known. If you are regularly gone from the lab, give people the possibility to call you. If you don’t like to be called, you can ask to be notified by SMS when you are needed. This gives you the possibility to respond when you have time. If you won’t be reachable or don’t want to be called, let your team know.
Separate team email from other email. Email is one of the hells of today’s working world. I try to check email only twice a day, and have notifications turned off on all my devices. But when I open my Inbox, I can have a fear-inducing number of new email.
To prioritize your team, you can use the filter functions that most email apps provide. For instance, you can have email by your team members display in bold, or in a different color, so they pop out.
Organize your email notifications. Some email clients allow you to specify for which kind of email you want to be notified. For instance, Mac and iOS allow you designating your contacts as VIPs, for which you can set up separate notification rules.
You can set up a separate email address just for “emergencies”. Ask your team to use this email when it’s urgent. If you use this approach, consider turning on notifications for that account, and make sure you check it regularly.
An easier way might be to use keywords in email titles with your team. This combines well with filters. For instance, ask that urgent emails start with URGENT, and filter such emails to be displayed in a different color. To avoid spam being filtered incorrectly, you can use an additional keyword, for example your lab name’s abbreviation, e.g. MyLab URGENT. Keywords also help you scan for important email more generally. For example, it can be very helpful to always mention in the title the project the email is about.
Use Evernote for offline communication. My lab uses Evernote with notebooks shared by all project members. Following up on critical projects, or checking on a designated “what’s up” note in the project notebook relieves everyone from writing emails, and automatically documents the project progress.
It’s worth playing around with these different methods to find the combination that best works for you and your team. In my experience, putting these kinds of tools into place takes a bit of getting used to for everyone. Some people will tend to call too often; some not enough. Some feedback will help tuning.
What are your stuggles with availability? Have you found well-working solutions? Let us know in the comments!
Find out about how we use Evernote in the lab in my Evernote Hacks series.
I’ll write about regular meetings sometime, but until then, there’s some interesting stuff to learn in the Manager Tools Basics podcast. Look for posts about One-on-One meetings; also see their website. Warning: these guys talk a lot. Helpful. But lengthy.
Years ago, at a conference, I visited a poster with a promising title. The student who stood by it was visibly uncomfortable and started her poster presentation with the words: “Actually, everything we tried didn’t work, but I can walk you through the poster anyway, if you want.” Mmmmh. No thanks. Until this day, I remember the name of that student’s supervisor. I wonder whether he was aware how his student represented his group?
When one of my students presents her work, her performance falls back on me and my group. I am surprised how often supervisors let their group members present a poster or talk ill prepared.
Prepping for a presentation
There are a number of points that are worth doing before a group member presents at a conference or seminar.
Revise the poster or slides yourself.
Give the presenter an opportunity to practice the presentation. In my lab, we do this in a group meeting, and everyone gives feedback. I’ve found this to be valuable, because the presenter gets a lot of tips, and those who are listening will take away a lot for their own presentations, too.
I’m often surprised how difficult presenters find it to bring across their main point and take home message. Many find it hard to extract the most relevant result, and to frame their contribution in a way that is interesting for a wider audience, one that is not specialized in one’s own topic or methodological approach. Make sure the presenter has decided on his message, and make sure you agree! It’s good to discuss the main message with the group, or at least with the presenter. The presentation should start and end with it, and everything in between should lead towards it. If a part of the talk doesn’t have anything to do with the main message, it can usually be left out.
Make the presenter aware of annoying mannerisms. What are their hands doing? Are they doing weird things with their feet? Are they using a lot of filler words (“like”, “uuuuh”, …)?
Create and discuss an “elevator pitch”. Whether your student will speak or present a poster, she will mention her presentation many times to colleagues at the conference. Often, people ask: “So what’s your poster about?” Prepare your student to have a short answer ready for that question – it makes her life easier and helps her confidence. By the way, designing a pitch can also help with finding the main message.
I’ve found that students are sometimes insecure about what to wear (no joke!). It can help to take initiative and discuss it with them.
With these points, you make sure that your team members will put your group’s work, and ultimately yourself, in a good light. At the same time, you help your team member to be well prepared and feel confident.
How do you prepare your group members for presentations? Do you have tips I didn’t mention? Do you know some good resources about presenting? Leave a comment!
Carmine Gallo’s book, Talk Like TED: The 9 Public Speaking Secrets of the World’s Top Minds disusses how successful TED presenters give their talks. I’d say it’s mostly geared towards talks to large, non-specialized audiences (like TED), but a lot of the content can be applied to scientific talks as well. Unfortunately, Gallo tries to connect his talk “secrets” to neuroscience. A lot of the neuroscience stuff in the book is either wrong or presented as generalizations from specialized research that is not always justified. Gallo is a communication expert, and that part of the book is good. Skip the neuroscience parts.
This post is part of the open draft for the Research Group Leader Book [about][read more].
I had a shocking experience recently. Within a week, my three PhD students all told me that they were thinking of leaving the group and going elsewhere when they’re done. Who’s going to do their work? And how??
When you started your group, things probably developed somewhat “naturally”. Without really planning for it, your group develops “a way we do things around here”.
Your group members know things you don’t
In my group, each PhD student has specialized beyond my own expertise. This means, they know more than I do. At least about the specific methods they are applying in our current experiments. In the beginning, I tried to keep up and learn with them. This started with technical things; for example, we use motion trackers to monitor movements of human participants. With my last grant, I had bought a new brand. Besides having to figure out the complicated setup, we had to re-write our Matlab code to control online measurements and data transfer. Today, I wouldn’t be able to run an experiment without the help of my PhDs.
But their knowledge monopoly doesn’t end with technical things. It continues with expertise about data analysis, experience in how data should look so that they are usable, and many other aspects of everyday scientific work.
So, when my three PhDs leave… well, I really don’t want to finish this sentence.
Document what your group is doing
People turn-over is high in science, with our short-term contracts on third-party funding, so my PhD disappearance problem is definitely not a one-time mishap. So, how can I retain the knowledge in my group? How can I make sure I consistently get similar quality in all the work done in my lab?
The answer is threefold: workflows, instructions, and templates. All three are types of documentation. Will you be surprised when I mention that I got these ideas reading business books?
A workflow is a series of steps that have to be taken to complete some task. You can think big and small.
For a big example, in my group we’ve created a workflow for running an experiment. It has all the steps that need to be done from creating a standard folder structure; Evernote documentation folders; documentation of idea, goals, computer code; instructions about what steps must be discussed with me or in the group; …
For a small example, we have a workflow for giving a contract to a new student assistant.
So I can see you thinking: running an experiment? I don’t need written instructions for that! But have you ever tried to find a file in the idiosyncratic folder structure one of your PhDs came up with, because there weren’t defined places of where specific files should go? Have you ever forgotten to check the experimental setup before your master student started acquiring data, only to find later that there was a cardinal mistake in the setup?
Multiply these “accidents” by 10 when you have a new lab member. Multiply by 100 when your team changes completely.
And have I mentioned how much time you save when you don’t have to explain everything to the new guy yourself, but he can go to a document and only return to you with a couple of things he didn’t understand?
Document how things are done. For the new motion tracker I mentioned, my PhDs created detailed instructions about how to set it up. You can use photos, mark things on them, and make detailed lists. Seriously: the more detailed the instructions, the less will go wrong the next time someone new has to do it the first time.
Write lists for things that need to be done regularly. For example, we have a list of what all needs to be done when we clean the lab.
These are masks that you can use over and over. You can use templates in quite a few situations.
If you have to contact a lot of people, such as to recruit them for experiments, you can have email templates.
We have a set of templates for the consent forms our participants must sign before they can take part in our experiments. Every time someone starts a new experiment, all they have to do is get the doc and adjust a few lines.
There are ethical guidelines about what all you have to tell your participants when you instruct them for experiments. We have a template so that no one forgets any of the required info.
I’m sure you can think of more.
Nice. But we don’t have time for this.
My group didn’t love me for it when I introduced workflows and instructions. It’s extra work.
We were lucky, because we had documented here and there already in Evernote. Those documents weren’t always complete and up to date. But we could use them as a start.
Your documentation will build over time. You don’t have to do it over night – unless you wait too long, until your PhDs have one foot out the door. So start now – the earlier, the better. If you are starting a new group, ask your group members to create re-usable workflows from the beginning, and then use them the next time they do the same task. Then they can revise and optimize them continuously with little extra effort.
Making it a priority to document all your lab’s best practices in is central to retaining knowledge in your group.
Does your group document workflows, instructions, and templates? If not, then why? What other things do you document? Use the comments section to let us know!
Michael Gerber takes documentation to the extreme in his book, The E-Myth Revisited. His point is that the more everything is standardized by documentation, the easier it is to scale, that is, have someone do the same thing again elsewhere, because you don’t have to be there yourself to make it happen. The classic example is a franchise. Every McDonald’s is the same. Obviously, not really what we want in research. But it’s worth looking at what all you can at least consider to document and standardize.
A picture is worth 1,000 words. If you need to document a lot of stuff on-screen, then Skitch might help; it integrates with Evernote. But there are plenty of other solutions, such as Clarify-it and Jing.