Thoughts on starting a lab

It’s nearly three years since I moved to UCL to set up our Metacognition Group or “MetaLab” for short (www.metacoglab.org). This has been a steep learning curve, and now feels as good a time as any to reflect on what I’ve learnt and write down a few tips that might be useful for others going through the same thing. These are inevitably skewed from the perspective of cognitive neuroscience and different things may apply in other fields. And, especially as we study metacognition, I’m obliged to include the disclaimer that some or all of this may well be wrong…

  • First of all, if you’re still finishing your PhD, or partway through your postdoc, consider whether you want to go for a faculty position in the first place. Being an academic isn’t the only end goal, and it’s certainly not “better” than other paths. There are loads of amazing careers out there for qualified researchers, from tech to policy to industry (and we should make sure, as PI’s, that our students are aware of these opportunities). Academia is just one option, so think carefully about what you want to do before jumping in to the job market. Even within academia there are lots of different routes – lectureships vs. research fellowships, for instance, and each has its pros and cons.

 

  • There are two ways of interacting with your peers and colleagues. One is to look to them for useful advice and support; the other is to worry and despair that they’re all doing well and you’re not. Try to do more of the former than the latter. There are several excellent resources out there – for instance, check out other blogs from Becky Lawson, Tim Behrens, Duncan Astle and Sue Fletcher-Watson, and Aidan Horner.

 

  • Teach. If you’re employed on a lectureship this will be part of your contract. But even if you’re mainly employed to do research (e.g. as a postdoc, on a fellowship, or at a research institute), volunteer to teach (and take the teaching courses offered by your institution). This year I have taught Masters courses at UCL and Aix-Marseille, and next year we’re planning a third-year undergraduate course in UCL psychology. It’s a great way to work out what you really know and what you don’t know and to contribute to the core mission of your university, and your colleagues will appreciate your contribution.

 

  • Remember that, especially early on, you are your own most experienced postdoc. Don’t think that, just because you’re now a PI, you should sit back and wait for your students to make things happen and the paper drafts to roll in. The best way to maintain your productivity early on is to keep on thinking of yourself as a postdoc. This will happen naturally if you have datasets and papers that need writing up from your actual postdoc, but even after these papers are out of the door, having projects of your own helps you explore new ideas and keeps your eye in with coding and data analysis.

 

  • Try out a few different ways of running lab meetings and one-on-one meetings until you find a good routine that suits you and your group (and ask them for feedback on what they would prefer).

 

  • When supervising students, finding the right balance between guidance and freedom is hard. There’s no recipe for this, unfortunately – it differs between individuals, and you won’t always get it right. You will regularly need to dive in and help at the coal face – devoting several hours to writing or debugging code, fixing stimuli and re-running analyses. This is inevitable and doesn’t mean you’ve got the balance wrong – this is your job.

 

  • Projects are almost never linear, and that doesn’t mean you’re a bad scientist – in fact it means you’re a good scientist. Going back to square one on a project means you (and your student) have learnt something, and that what you do next will be much stronger as a result. The same goes for piloting – we often pilot several versions of an experiment before committing to a design. This can be frustrating if the initial assumption is that it will “work” out of the box. If you instead treat piloting as a learning process then it’s much less stressful.

 

  • Finding the right setting on the accelerator is hard. Resist the temptation to grow the lab for the sake of it – starting small is fine. But this is a delicate balance. Promotion criteria and future grant success are often linked to past grant success. So – once you’ve settled in and have a new idea you want to work on, go for it. Often there will be smaller internal grants for early career researchers at your institution, and these can be very helpful for getting a new line of work off the ground.

 

  • The people you hire as postdocs/RA’s or take on as students are your lab, and will shape the culture of your group. These are probably the most critical decisions you will make in the first few months/years. So don’t rush into it, and trust your gut feeling – it’s usually better not to hire at all than to hire people you’re not sure about. It’s especially crucial that postdocs are passionate about the same kind of questions as you, so that you are both pulling in the same direction. This works both ways: remember that postdocs are taking a gamble by working with you rather than someone more established, so you should expect to work hard for them, rather than the other way around.

 

  • Share your code and data for each project (for an overview of how to do this and why, check out these slides from Laurence Hunt). We have a lab Github and before a paper is published we take a couple of days to make sure all the code and data are uploaded with accompanying notes. I’m fairly sure no-one outside our lab cares about this, but within the lab it’s an incredibly useful resource. I can point new students to where they can get code snippets and examples of various types of analysis. We’ve also started pre-registering protocols and hypotheses for empirical projects by uploading timestamped PDFs to OSF. I’m not militant about this – a purely theoretical project, for instance, probably can’t be meaningfully pre-registered and several empirical projects in our lab start out as exercises in the development of candidate computational models. But there is usually some point within the life cycle of a project when it makes sense to pre-register. This forces us to commit to what we’re doing and keeps both student and PI honest.

 

  • Write a lab wiki. I haven’t done this yet but am jealous of other lab wikis. Like sharing code, it will save you time in the long run.

 

  • Give yourself time to think and try not to be busy just to seem busy. In Michael Lewis’ book The Undoing Project, Amos Tversky tells us that “The secret of doing good research is always to be a little underemployed. You waste years by not being able to waste hours.”

 

  • Take holidays and breaks (see above) and encourage people in your group to take time off. The world won’t end. But try to switch off your email – set an out of office, remove it from your phone and change the password. That way the only way you can get online is via a laptop, by making a conscious decision to work. When I’m doing something active on holiday (such as sailing, with any luck) I don’t take the laptop. But if we go to sit by a pool I like to have my laptop with me in case inspiration or boredom strike. Just don’t let it make you anxious or stressed.

 

  • Being a PI is like playing good tennis – it takes a lot of repeated practice. You will struggle at the start not because you’re not a good scientist/academic but because you’ve got less experience than someone who has been in the game for 10 years. Seek the respect of those who you respect, and everything else will take care of itself.
Advertisements