So in 2019 I can have a different New Year’s resolution than I’ve set for the last several years, because in 2018 I actually wrote my lab handbook.
There are lots of great reasons to have a lab handbook. How your’s works and what you focus on will depend on what policies you need in place to accomplish research. I need one that suits the student-driven research I manage. I became a PI in 2008, in the wake of a global recession. Fortunately, I already had a stable job (started ~ 1 month before the crash, fortunately). But the prospect of getting a major grant diminished considerably. Typical funding rates in my area plummeted from improbable-but-possible-with-great-effort to so unlikely that large-scale funding – the kind you would need if you want a lot of paid personnel working for you in the way you want for years – was practically mythical.
Fortunately my bread-and-butter is basic cognitive research, which can often be accomplished to a high standard with student participants and student researchers. (Note to potential funders: there is work I would like to do that cannot be accomplished this way though.) Across a few years, I can accumulate data for a major paper via student-driven projects. But this present big management challenges. There is a lot of turn-over. Other than PhD students (which are rarer in Europe than the US because funding them here is managed differently), I can usually expect a student to work with me for one academic year or less. The quality of the work depends on how well I can train and supervise my students as well as the characteristics and skills they bring to me. However smart someone is, they do not automatically know how to manage a research project, how to design a study well, or how to work with participants. I need to constantly be mindful of what they know and what they don’t, and to find ways for them to benefit from my knowledge and experience while giving them a chance to learn for themselves.
I learned quickly that I had to be proactive about the lab work my students carried out if I wanted to know the provenance of the data. To be confident that I knew how the data were collected, I needed some formalization of how processes were documented, what steps needed to be carried out before a project was ready to start. It’s also crucial to learn what I needed from students as a project ended. It would usually be months before I got around to processing a student’s data set my own way, and only then would I realize what I didn’t know, and needed to know. That’s too late: by then, I may no longer be able to reach a student who has left the lab, the student may no longer remember what they did. In any case, the data were already collected, so if something important is missing or unclear, it is too late to rectify it. Whatever the problem, at that point you must either simply live with it as-is, or collect a fresh data set.
I had to learn, over ~10 years, how to provide consistent mentorship and instruction to my students in order to make the most of their efforts. I’m still learning: sometimes we still miss out recording something important, or fail to document an element of our process that would have been useful to know. New methods become available that we have to figure out and integrate into our workflow. I try to add bits to my policy that prevent the same problems from arising again. It’s not that we can’t learn anything unless the project was perfect; I’ll learn what I can from what I’ve got. But I want to learn more from the next data set, and I want my students to be fully onboard with helping me develop and maintain high standards.
There are still parts I want to write, and I expect to edit it heavily later this academic year based on user feedback, new experiences, and reading the other lab manuals I know are out there to see what else could be included. Also, if you ever worked in my lab as a student, I want to include you on the alumni list! Get in touch and let me know if I missed you, or if you want your title updated, or if you want me to link to your current website.