PhD advice

7 things I wish I would have done during my tenure track

by

Recently I’ve seen some Twitter threads on advice for new PhDs/postdocs/PIs. I’ve shared this about my PhD before (see 7 things I wish I would have done during my PhD), and in my current job I’ve been reflecting a bit about how my previous job went, I thought I would also share the 7 things I wish I would have done during my tenure track!

They are:

  1. Being in the office less
  2. Not agreeing to only teach undergraduate courses
  3. Spending less energy on grants
  4. Divorcing my email accounts
  5. Getting a Macbook
  6. More papers with people from Twitter
  7. Sharing more work online

1 Being in the office less

After starting my tenure track in February 2017, my best-case scenario day would look like this: I would leave my house in Rotterdam at 7:20, to take the train and get to the office at 9:00. Similarly I would leave at 16:50 and get home at 18:30, in time for dinner. There were sometimes disruptions, with me arriving 1-2 hours late in either direction. Maybe not too bad considering depending from where in the world you are reading. And as a plus I could work in the train – I would often read or draft blog posts.

After two years of working at home, I cannot imagine being able to do these kind of hours again. Although I was already quite mindful of the hours I would spend on my job, I didn’t realize that doing productive things in the train also counted, and that I probably was not getting enough rest. I also don’t really understand why I felt it was necessary, as I wasn’t required to be in the office on specific days or hours unless I was teaching or had other meetings.

2 Not agreeing to only teach undergraduate courses

For the first three years, I was the course manager of a first year BSc project and taught in another third year BSc course. I enjoy teaching at multiple levels, but I think I shot myself in the foot a bit here. As I had no start-up, PhD students to co-supervise, etc, the main way to start new projects was to supervise MSc students. But since I wasn’t a person the then-MSc students were aware of, recruiting such students was rather difficult.

3 Spending less energy on grants

Funny given that during my PhD I wish I had “applied to all the things”! As part of my tenure track conditions I had to apply for two “medium” (1 PhD position size) grants a year, which was reasonable, and it was useful to think about the project proposal. But several of these applications were doomed to fail, as even with a perfect score on the research proposal, my CV just was not “good enough” to get funding. Given that there weren’t many other opportunities to apply for, I guess overall this was still a useful experience, but I definitely could have spent less time on writing workshops, endless revisions etc.

Another advice was to apply for all possible small grants (workshops, collaborations) that I could get. I did that and actually got several of the things I applied for. But this was too much – relative to larger proposals, these cost more time to write, AND require more work from you after, without the option of hiring somebody to help.

4 Divorcing my email accounts

I used be very much a “one inbox” kind of person, and forwarded my university email to my Gmail. But with a new job and email account, I decided to try it out. Although Gmail has a much better interface than Outlook (don’t get me started on this…), I like it a lot. I don’t have Outlook on my phone, so I mainly have access to my work email during my work hours. This frees up a bit of headspace during time off, which I would often already use to mentally draft emails, thus spending way more energy on emails overall.

5. Getting a Macbook

Similarly to me trying out a different strategy with emails, I felt brave enough to try out a Macbook after a lifetime of Windows. It’s kind of great, I’m still pretty inept at using shortcuts etc, but I don’t imagine going back anytime soon.

6. Starting more papers with people from Twitter

One of the most satisfying things in my career has been to work with people met on Twitter. The prime example is probably this paper about Twitter – some of us have met each other beforehand but I feel safe to say this was a Twitter collaboration.

Another highlight was this preprint with Gaël – it started because I agreed with him about AI being hyped too much and said “we should write a paper about this”. A longer revised version has just been accepted so keep an eye out.

I like slow science, so there are other projects that are amazing and that started on Twitter but are not out yet. Stay tuned 🙂

7.Sharing more work online

This perhaps sounds surprising since I share preprints, slides etc and would even write blog posts on a more-regular basis. But I still see so many things that I’ve done that could be possibly useful to others, that I did not share, either because the thing needed a bit more input (for example going from an undergraduate project to a preprint), or simply because I didn’t get around to it (for example rejected grant proposals).

I am not sure I will ever get to a point where I’m doing this better, but as usual, if there is something I have that might be helpful to you, just ask.

***

This is just my list! There are also a few issues others mentioned in the Twitter discussion that maybe I did OK with? and are therefore not on this page – but that’s for another blog post 🙂

How I write cover letters

by

Following up on some recent (and less recent) discussions on Twitter, I decided to share a few of my applications for academic positions. Although the tips here are specifically about the cover letters, for context I am also adding the CVs that I applied with at the time. Depending on the application, other documents may have been required as well.

Applications

I am sharing three applications from different periods of time:

  • 2010 when applying for my PhD
  • 2014 when applying for a postdoc
  • 2016 when applying for a faculty position

These led to me at least getting an interview (see CV of Failures) and/or also getting the position. You can find them all in a single zip file here.

A bit of a disclaimer – I do NOT think these are the best examples out there at all, but I’m sharing these for transparency, as realistic examples. I also have to note that I have likely benefitted from applying to places “close by” in my network.

Cover letter structure

When I write letters – and I have tried these with the letters above, I try to use the following structure:

  • General introduction of the letter – who am I, why am I applying
  • My research background and how it fits the position
  • Another thing that is special about me
  • Summarize why it’s a good fit & plans for the future

Often this translates into a paragraph per bullet point, but as the examples show there is some flexibility there.

As much as possible, I try to address the person who is going to read the application, using their correct title. If you are not sure, I would go with “Dear committee” since that is the most inclusive version.

Tips

Above I have highlighted which parts I think are the most important. All of it is about personalizing your letter to the position. Researching the website of the lab, the long-term vision document of the university, etc., can give you a lot of information on what to write.

It is also important not to write too much – although I highlight a few things from my CV, I do not repeat everything in detail. And, I think it is good to write in a way that sounds natural to you. Although I think these are not the best letters at all, I do still find that I sound like myself, even though one of these is from 10 years ago! Note that I do NOT have an in-depth story of how motivated I am to solve a major scientific problem, because that is just not me.

Although I do not know it for a fact, I think my “another thing that is special about me” has helped my applications a lot. The exact contents have evolved over the years, but overall I think I tried to focus on activities that can be seen in a leadership context – from organizing student events to outreach on social media.

***

That’s all I have to say about my cover letters! I hope these documents are helpful – if you have any questions please leave a comment or get in touch on Twitter!

How to share papers with your students in Evernote

by

Although I have only supervised a couple of students during my tenure track, I already found often saying the same thing during each meeting – in particular, what are good papers to start reading about a particular topic. Since I was already an avid Evernote (get 1 month premium for free here) user, I decided to see if shared Evernote notebooks could be the solution to share papers with students. This might be also an option if you are organizing a journal club. Read on for the solution!

Initial setup 

I was already keeping track of the papers I read in Evernote – see this post on organizing my bibliography with Evernote and Jabref, but I will recap some things here. 

Remember that Evernote is not a reference manager, but it is where I store the paper PDFs and notes about the papers. Jabref is where I store the references. The only link between the two is the Bibtex key, which is how I name the note in Evernote. 

This is my paper collection i Evernote – 913 in total – and each note is a paper (or report, etc).

A list of notes in Evernote, each is titled in the format "last name, year, first word of paper title". The notes have several tags assigned to them, like "medical".

Each note is at least the PDF I saved (below), and perhaps some notes I made about the paper. And this is how it looks like in Jabref:

A list of academic papers in a .bib file, columns shown are the type of entry, author, title and year. The papers are covering various machine learning and medical imaging topics.

Since there is no direct link, I might have a paper in one place but not the other, but papers that I cited in my own research in the last few years, are definitely in both.

Sharing your paper collection with others

Since Evernote allows sharing notebooks, to have a shared collection of papers all you need is to share the notebook with the people involved. For the students I was supervising, I used the “can edit” as permissions so they could also add new notes, annotate papers etc. But you could also choose “can view” option if you prefer.

Sharing a collection of 900+ papers is probably not effective 🙂 But what helps here a lot, is the tagging system of Evernote. When I add a paper to this notebook, I add several types of tags:

  • Type (paper, thesis, etc)
  • Topics (specific types of machine learning, applications etc)
  • Projects (a specific project where I might want to cite this paper)
  • “Priority” (p1, p2, p3 or p4)

I have been using the type, topics and projects for a while, but the priority was an addition after I shared the notebook. Roughly, the priorities translate as:

  • p1 – everybody in the lab should read this
  • p2 – important paper for many projects in the lab
  • p3 – relevant to some projects
  • p4 – not related to our research but more “general interest”

With these tags, you can then do queries on topic & priority. So for example if your project is on transfer learning and you want to find all papers I might suggest, the query “tag:ml-transfer & tag:p2” gets you 43 results. Still a lot, but now it’s doable to screen the results and narrow them down. 

It’s good to mention that since the notebook is originally mine, only my tags can be used within the notebook. So somebody with edit permissions would be able to add more of the tags that I use, but not add entirely new tags. 

Pros

  • The system is easy to use, paid account only needed if you want a lot of storage
  • Saves time both for me and for students
  • Less chance to miss a relevant paper
  • Everybody can use their own reference manager if they want

Cons

  • Could limit the way students explore literature
  • Limited commenting possibilities (notes from everyone appear the same by default) 
  • No true integration with a reference manager

Conclusion

This system has been quite helpful for me with several student projects. However, there are many things I am still missing, such as creating your own fields for each paper, and interacting with the annotations through a spreadsheet. (This is possible in Notion, but that is something for another post…)

However, an important quality of any system is that you actually use it. Since I already use Evernote on a daily basis, it works for me. But I’d love to know what everybody else is using for sharing literature with others – please leave a comment below or let me know on Twitter!

Organizing student projects with scrum

by

Project supervision is one of the many things you do during a tenure track. Since I was already interested in project organization, I did some research, which inspired my own lab scrum setup. I discuss why and how I used scrum to organize student projects, and my take-aways from the experience. To find out more, read on!  

Inspiration

At the start of my tenure track I did a bit of research about what others had recommended, and came across several interesting papers about project organization. This is a whole post in itself, but for today’s topic, here are a few papers that I found helpful: 

Patterns for Supervising Thesis Projects

Adapting Scrum to Managing a Research Group 

LabScrum: A Case Study For Agility in Academic Research Labs

The last two papers are about a technique called scrum, which is a type of process frequently used in software development (more background here). Traditionally in this process, a team is working on the same project. This is different with several students working on different projects. Another difference is the timing, which might be slower in a research setting. Nevertheless I was inspired by the ideas in these papers and decided to try it out.  

Setup with Kanban board

Although I was excited by the idea of trying a different type of organization, I had no previous experience with scrum, and didn’t want to introduce too many things that would be overwhelming for everyone.  What follows is the setup we (myself, 4 MSc students and 2 PhD researchers) used for 6+ months, where some things are loosely based on scrum, papers I read, etc. This setup has advantages and disadvantages, which I discuss later in this post.  

The main idea was to keep track of all projects jointly, via a shared Kanban board and two weekly meetings with everyone there. Typically we did the following meetings:

  • Tuesday – group update round, planning tasks (30 – 60 min)
  • Thursday – group update round  (< 30 min)
  • Tuesday/Thursday – individual meetings in time slots as needed (30 min each)

When planning tasks, we added “post-its” (I bought these reusable magnetic ones which are pretty awesome) to the shared scrum board. We initially used different colors for different types of tasks, but using different colors for different people might be more logical.  

Whiteboard with colorful post-its with tasks on it, divided into categories "backlog", "do", "doing" and "done"

 For me it was important that everybody created actionable, finite tasks. So, “literature research” is not OK, but “summarize 10 papers on topic X” is. When students had exams, they included studying as a task. We didn’t have guidelines for how small or big a task could be, although in practice they were probably things that could be done in days, rather than hours or weeks.  

New tasks always started in the backlog section of the board. On Tuesdays, tasks can be moved to the “in progress” section. The idea is not too have too many “in progress” tasks at the same time. 

Every group meeting was essentially a longer “stand-up”. Each person (including me!) would briefly say something about their “in progress” tasks. This involved saying something about what was done since last time (and if the task was completed, still in progress, or deprioritized), and any problems that came up. Suggestions from others about things to try usually followed. When it was clear that I needed to spend more time with the student, or some students could help each other, additional meetings were planned. This way this meeting was an hour at most, but usually closer to half an hour.

Everyone could plan an individual meeting with me via a shared calendar with 30 minute time slots. In practice, about 4 slots would be filled each week, so I would see each person at least once in two weeks (next to the group meetings). 

Alternative with Google Slides

While the initial setup had many positive points, there were two main things missing. The first was more of an overview of what has happened / is happening in the period of a few weeks. The second was the ability to show something, such as results (bugs, etc). 

For these reasons, we switched from the Kanban board to a Google Slides presentation, where each person had two slides, one for results, and one for a 6-8 week task planning and progress. The slides had to be prepared before the Tuesday meeting. Otherwise the meeting setup was mostly the same.  

This setup provided more overview, but I also missed the structure the Kanban board provided. In the end, I was thinking about a system that would have both features, but I didn’t get the chance.  

Here is an example of how one of my Google Slides looked like, with on the left the plan as I imagined it, and on the right an illustration of progress.

Pros

I’ve already mentioned a few advantages that this system had, but here is a recap. 

First, I think this is a great way to have a “lab feeling” if you are in a similar situation to me, and do not have funded projects with multiple students or physical lab space. Although the students all did distinct projects, it did feel like a team. Getting coffee, bringing cake etc also helped of course 🙂 

Second, I saved time by not having unnecessary meetings, but without compromising my availability. Further time is saved by less repetition when explaining something, and by identifying similarities across projects, where students might be in a better position to help each other. 

Third, I think this setup improved everybody’s planning skills, but also their awareness of how planning is hard. I also participated with my own projects, and I typically got the least done because of other responsibilities. I think this is important for students to see. Students seeing each other’s project plans likely gave them more examples to learn from, and perhaps a bit of accountability.  

Cons

The disadvantages of this system, from my point of view, mostly have to do with implementation. First, it takes a while to figure out how to do everything, if you try to adapt a system to fit a different situation. There is also time involved in figuring out how/where to meet (if you don’t have a dedicated space) and/or selecting which apps you want to use. 

Second, your adaptation may miss parts that you want to have. We did not have a clear separation of meetings (such as planning only, retrospective only) or project roles (such as scrum master). Perhaps these things might have felt silly at first, but I do think they would have been beneficial.  

It’s possible that this setup might not be the preferred setup for some students, who want to keep everything about their project private. I do not have specific advice for this situation. But ultimately different labs are organized in different ways, and it’s OK that this might not be for everybody.

Verdict

Overall I would say that doing this is a worthwhile experience! Do spend more time thinking about the exact implementation beforehand, particularly what meetings there will be, who will do what, and where all the plans/tasks/results will “live”. Once you have this in place, help people stay with the process for a least a month or two to evaluate if it’s a good idea. 

Acknowledgments

This post is inspired by a discussion on Twitter, started by Antony Caravaggi and continued by Christian Baumgartner, who also sent me several follow-up questions – thanks! I’d also like to thank everyone had first-hand experience of my lab organization ideas 🙂 – Ralf Raumanns, Ishaan Bhat, Tom van Sonsbeek, Rumjana Romanova, Colin Nieuwlaat and Britt Michels. Thanks a lot! 

Guest post: 9 ways to fail a project in grad school and beyond

by

This post is a collaboration between myself, and a guest author who wishes to stay anonymous. They are a researcher and PhD candidate in neuroscience, based in Europe, and in the post they are referred to as Alice. 

When people talk about failures, often rejections are the first things that come to mind. But what about other things in science, that did not work out? Today’s post is all about those – projects that don’t work out, and that do not end up either on your CV and probably even your “CV of Failures” (here is mine).

Read on to find out about the ways our projects have failed, during the PhD or after, AND the lessons from these experiences.  In short, here are the 9 ways to fail a project: 

  1. Inheriting a poor project setup
  2. Failing to plan
  3. Not enough redundancy
  4. Changing the scope 
  5. Underestimating the complexity
  6. No data available
  7. Collaborating for the wrong reasons 
  8. Starting too many projects 
  9. Forgetting to advertise your successful project

1) Inheriting a poor project setup   

Alice: My first project failed in a bad way. In retrospect the idea was not thought through and vague and the methodology was not sound. In fact this is what got me into trouble – as I tried to discuss these issues with my supervisor, he got angry and said that I am at no place to challenge his authority… After two years when he left the project was evaluated by a panel of group leaders at the department and found to be crap from the very bottom. The project was killed. 

Veronika: Of course a lot here depends on the supervisor. But from the researcher’s perspective there are still a few lessons here: 

  • If you inherit an existing project, verify that the objectives and methodology are clear
  • Ask questions early on, consult with others 
  • Remember that quitting a poor project early is not your failure, but might save time and stress

2) Failing to plan

“Failing to plan is planning to fail” – no post about failed projects is complete without this quote attributed to Benjamin Franklin. If you are responsible for the project setup from the beginning, definitely do not skip this step. 

This is particularly important for side projects that you might initiate next to your main research, that “shouldn’t take a lot of time”. While that may be true, in my experience things can go wrong is it is not clear who is going to be responsible for what. Or, all content-related tasks might be divided, but nobody is taking the lead on the project. Lesson:

  • Spend time defining the project timeline and contributions of all team members, including a leadership role

3) Not enough redundancy in the project

Alice: My second project failed for two main reasons. One was founded around a collaboration which was tied to one person who left. The lesson being that being dependent on certain people for connections or data is a weak spot. 

Veronika: I recognize this! I’ve experienced problems when parts of the project depended on specific data, code or tools that were not available / accessible to others. Again a lot about this depends on the PI, but for me the lesson from the researcher’s perspective:

  • Be your own best collaborator by using open science principles, sharing data/code where possible. Consider using public data or artificial data in addition to the main data, if the main data cannot be shared. 

4) Changing the scope during the project 

Alice: […] But there was more. In the course of the project, as I processed the data, the PI got ambitious and teamed up with his colleague who did similar things and was interested. He then wanted to do a much bigger comparative study and requested me to process large amounts of public data which slowed me down significantly. By then my PI left. The lesson is getting too ambitious can drown the project.  

Veronika: I’ve had similar experiences too and see it all around me – a PI invents things to try until there are “state of the art” results (similar to HARKing). I’m getting repetitive here but again you are quite dependent on the PI. What you might be able to do: 

  • Clarify project objectives and timeline in the beginning in writing (for example, type up meeting notes, and send them around after to confirm) 
  • Open science principles like preregistration might be worth a try, although this depends on your field and will also require the PI’s approval

5) Underestimating the complexity of the project

Alice: My third project did not fail as such but rather faded away., which is a failure of a kind. It was a collaboration with a postdoc who was an expert in the field and had a nice idea. The problem was that the implementation and most importantly interpretation of the data turned out to be much more difficult than she had anticipated and it required more input from both of us than we pledged for. A mistake here I’d say – wrong estimate of the complexity and resources available.

Veronika: Agreed – I’ve had several nice ideas that sounded great when brainstorming, but in the end did not receive enough attention to progress. I have a lot of thoughts about these which would warrant an entire blog post. Still, I wish I would have been better at planning my time. My lessons would be:

  • When agreeing on a new (side) project, agree on how much time you can put into it. I think this is hard to do, but if you did have this agreement in the past, the future you will have an easier time letting go of the project. 

6) No data available

Alice: The fourth project failed when I learned that I can not get the phenotype data on the cohort I worked on and at this point there was nothing I could do. The data was blocked due to disagreement and issues between my PI and the competitors with whom initially it was supposed to be a collaboration. I don’t really have a recipe how to help that, it is one of the things that I have little control over. 

The fifth project failed for a similar reason. But this time it was because we were not allowed to collaborate with the boss of our PI (who has a cohort with the exact phenotype we need) who did not want to publish with the previous boss in view of the career. We were thus pushed to prey on the public data repositories which a) did not have such precise phenotype we needed b) required downloading and low-level processing of large amounts of data which was very straining and hard for a single person and given resources. We managed with the published subset of the data and we found nothing. I spent almost a year working on it. 

Veronika: This overlaps a bit with my previous ideas about open science, but in this case there’s not a lot somebody in your position could do other than use public data. Lesson: don’t blame yourself for decisions of your PI!  

7) Collaborating for the wrong reasons

Alice: A friend of mine went to a prestigious university to collaborate with a research group there for a few months. He worked very hard, but faced open racism and bullying. The conflict escalated and the project was tabled. Instead of support, my friend’s supervisor was unhappy with him. This is also a situation which is hard to foresee. But perhaps trying out collaborating remotely first and building relationships slowly would be a safer bet.

Veronika: Sounds like a terrible experience for your friend! Agreed it is a good idea to try out collaborations first but perhaps that was not possible. There needs to be not only a research fit, but also a safe environment.

 But on the other hand, the environment alone is also not enough – even with people who really want to collaborate, sometimes it just doesn’t work. Getting along well with somebody doesn’t mean your research project will be complementary as well. My lesson would be:

  • Know who you will collaborate with, and aim for a combination of research fit & good environment

8) Starting too many projects

Veronika: A “favorite” reason why some of my projects failed, is starting too many projects and then not getting back to them. Often this would happen if I was waiting for reviews on a paper, and already planning the next project. But when a major revision would come in, I would drop new ideas to revise the paper, and once done, fail to get back to the new_idea.txt. Side projects could also end up in this category. 

In a way, this is a combination of “failing to plan” and “underestimating the complexity”, but on a larger scale. My lesson from this:

  • Keep track of how many projects you’ve agreed to do, and what stage the are in (for example with a Kanban board)

9) Failing to advertise your successful project

Veronika: Congratulations, you finished the project! What now? While this is not technically a failure, there’s still ways to increase the success of your project.

Once you do finish a project, you might not give the project output enough attention. It’s easy to become focused on getting a paper for the thesis, especially if your PI is pushing you to. So a natural response might be to just move on to the next project, leaving the published paper as is.

But maybe it’s good to pause, and give that effort more justice by sharing the paper with your colleagues, submitting a poster about it to a local conference, or writing a thread about it on Twitter. I know I am guilty of this – despite my rather active Twitter presence, I haven’t tweeted about my research this year. The lesson is: 

  • Give your finished projects (and your hard work!) the attention they deserve! 

******

These were the 9 ways to fail a project during your PhD and beyond! These are based on Alice’s and my experiences, but there are probably more reasons there.

Let us know which ones are recognizable, or if you are missing any failures that can happen along the way. The best way is to leave a comment below so they reach both of us, otherwise as usual you can reach me (@DrVeronikaCH) on Twitter!  

Tenure track in the Netherlands

by

By popular demand, today’s post is about my tenure track position which I started 3 years ago. Although I intended to give an update of how my tenure track is going, there’s a bit of background that’s relevant to share, so this post is only about my experiences when I started. Also, recently I’ve had a few questions from future tenure trackers, so I’m sharing my answers in case it is useful to others.

Starting conditions

As I’ve also explained in my “student or employee during your PhD” post, all academic positions in the Netherlands work with fixed pay scales. You can find these here, below I also added a screenshot of some of the scales.

These numbers are all before tax and per month. Various secondary benefits also apply.

Assistant professor positions are in scale 11 or 12. Typically a starting assistant professor would be in scale 11, and in scale 12 after tenure. The Dutch Network of Women Professors (LNVH) reports that 50.8% of women assistant professors are in scale 11, versus 40.8% of men.  

When I started at TUe, I was initially offered scale 11.0. However, I had already been in scale 11 as a postdoc, and my institution was a medical center, with slightly higher pay scales. Due to this I was offered 11.3, which just matched my previous salary, and which I accepted.   

There was no start-up package – I think this in general isn’t a thing in the Netherlands, although I do see this being offered more frequently now.

Contract & tenure conditions

The tenure track contract is a temporary contract for 5 years. After 4 years there is an evaluation which decides whether you get tenure or not. If yes, you get permanent contract, if not, you are still employed for a year. There is also a (less formal) midway evaluation after about 2 years, to prepare for the real thing.

The criteria for evaluation are described in various documents. I received some general criteria on what is important for the university (for example “supervising students”), and a department-specific interpretation of these criteria. In the context of creating a personal development plan for the tenure track period, I did receive some quantifiable criteria too, of what you should aim for within 4 years:

  • Significant progress in obtaining the teaching qualification certificate
  • Responsible instructor for 1-2 courses
  • Good teaching evaluations
  • Supervision of at least 2 MSc and 4 BSc students
  • Co-author of at least 5 peer-reviewed publications in high impact, relevant journals
  • Written statement from chair about contribution to getting funding
  • Significant progress in increasing external visibility
  • Collaborations with other departments, hospitals or industry
  • Successful (co-) supervision of multiple PhD researchers
  • Examples of strong leadership
  • Examples of strong communication skills
  • Examples of independence and responsibility

A bit more quantifiable, but still open to interpretation. In my own personal development plan I translated these as follows:

  • Get teaching certificate
  • Setup and teach a first year course, co-teach in a third year course, later start developing course closer to my research
  • Supervise at least 2 MSc and 4 BSc students
  • Co-author of at least 5 peer-reviewed publications in high impact, relevant journals
  • Apply for 2 medium-sized (1 PhD or postdoc) grants per year
  • Apply to small grants, for example for workshops, when possible
  • Give talks at (local) conferences, or invited talks if possible
  • Setup collaborations with other departments 
  • Co-supervise a PhD researcher (if funding)
  • Outreach about academia through blog and Twitter 

Also not entirely quantifiable, but I also left out a few specific details here (examples of papers, collaborations, numbers of blog/Twitter followers etc).

The (midway) tenure evaluation moments consist of submitting an update of this plan and a recent CV, and then giving a presentation about your achievements to a committee of 3-4 professors.  

This is all I wanted to share for the first part of this topic – next time I’ll talk about how things are going so far. If you have any questions about this post, or anything I can address next time, please comment below!

Firsts: publishing a preprint before submitting the paper

by

Although I’ve been using preprints since 2013, recently I had a new kind of experience with preprints. Whereas before I would post the preprint upon submitting it to a journal, for the first time I decoupled the two events, and submitted the preprint several months ahead. In this post I reflect on this experience. 

Why

My choice was initially practically motivated. The idea for the paper was born in 2016, but since moving to a new position, I’ve been too overwhelmed to do any writing, so at the start of 2018 the paper – a survey of a magnitude I haven’t attempted before – was far from finished. I wanted a deadline, but I still wanted to be able to update the paper if needed. So a preprint seemed exactly what I needed! 

Timeline

I set the deadline to April 2018 and for the next weeks, worked towards getting the draft to a readable shape.  In April I submitted the preprint to arXiV. Differently from submitting journal-ready preprints, this time I put a piece of text inside the preprint, saying it is not the final version and I was happy to receive suggestions. At the same time, I emailed a few people with the URL asking for comments, and I asked for feedback on Twitter. This felt scary to do – I don’t think I felt as nervous with any of my other papers.

Response

Despite my fears, the experience was positive – I got a lot of constructive feedback which helped me to improve the paper. So in September 2018, I submitted the updated preprint to a journal. In the cover letter, I mentioned the Altmetric statistics of the preprint (I later discovered this is sometimes frowned upon).

Next to the traditional list of suggested reviewers, I also provided several names of people who I had no conflict of interest with, but who had commented on the preprint on their own. I figured that, since they had already read the preprint, they might be willing reviewers. Of course I disclosed this in the letter. 

Publication

The reviews came in about 8 weeks later – an absolute record for me, as during my PhD, regularly waited 6 to 9 months for reviews. The reviewers were constructive, and suggested a coufple of revisions. After revising, the paper was accepted in January 2019 – by that time already gathering a few citations and benefitting from the preprint bump. 

Verdict

Given this experience, I would definitely post a preprint online without submitting it to a journal first, and not necessarily because of more citations. I realized that me feeling worried about it is a good thing. I could be sure the paper would be seen by a larger group of people, who had an incentive to comment, since they could still influence the paper. This is different from convincing a few reviewers, and then maybe not having the paper noticed afterwards.

Since this paper, I have also been part of another paper that used the same strategy (and is currently under review), and I noticed other preprints putting similar “please email us” messages on the front page. It seems there is a need for interacting with preprints differently – I’m looking forward to what different initiatives like overlay journals will bring.

Not-so-supervised learning of academics

by

Picking up where I left off with blogging last year – this is part two of a write-up of a talk I’ve given a few times last year, part one is here. After talking about algorithms which deal with data that is not fully labeled, in this part I discuss how career choices can be similar, with my own as an example.

PhD 

Doing a PhD was not on my radar until my MSc supervisor suggested that I apply for a position in the group. I liked the group and doing research for 4 years seemed like a good job to me (see my post on being an employee during your PhD). I didn’t have any specific long-term goal and, as I now realize, was clueless about most aspects of academia. 

What I did understand is that it was good to publish papers. I had a few interesting (though not spectacular) results fairly early on, so I wrote papers and sent them to various workshops. I enjoyed these workshops a lot – since there were not that many people, I could meet researchers I’d just been citing, and have good discussions. On the other hand, I spent quite a lot of time writing smaller papers and pushing away the fact that I needed journal publications to graduate. Also, as I discovered later, my grant reviewers have never heard of these workshops, and thus were not impressed with my publication record. 

I also did a lot of service and outreach activities. I had already been doing this type of thing as a student, so I was good at it, I enjoyed helping others, and it was good for my CV, whether I’d stay in academia or not. So I spent time organizing workshops, reviewing papers, giving talks to encourage more girls into science. I did learn something from all of these activities but in retrospect I think I spent a disproportional amount of time on them. 

Postdoc

I doubted a lot before deciding to go for a postdoc. The awareness of the struggle of finding a position after, and all the people telling me I really have to go abroad to have any shot at it, didn’t help. In the end by talking to more mentors, I decided to go give it a try – without leaving the country. 

My plan was to only do one postdoc and then get an independent position – or leave academia.  As I understood to achieve an independent position I needed to do three things: publish on the project I was hired on, develop my own line of research, and get my own funding. I was not prepared to deal with so many different objectives, so in the end, I did all the things poorly. On top of that, I failed to take care of myself, and had to take a few months off to recover.

It was during a particular low point during the postdoc that I started blogging and tweeting more. It started with me publishing my CV of Failures – I thought I would be documenting a story that would end with me leaving academia. The response was overwhelmingly positive, and I continued with the How I Fail series. During all of this I found an incredibly supportive Twitter community, with many others who were going through similar struggles, and it’s been helpful ever since. 

Tenure Track

Much to my surprise (and other feelings), I did find myself in a tenure track position after all.  This is an important accomplishment, but at the same time, the next goal – getting tenure – is coming up in a few years. Again, there is this (self-imposed?) pressure to do all the things, so it is not without challenges.  But, it is a much better experience in several aspects, because I occasionally realize that I don’t have to do all the things all the time. :

  • I occasionally realize that I don’t have to do all the things all the time. I’ve now actually been able to have periods on time focusing on writing, then focusing on teaching etc. 
  • I occasionally (not often enough) realize that I don’t have to repeat the career paths on others to “succeed”. The combination of things that I do, might just be “good enough”, even though it doesn’t fit the typical “successful” CV. 
  • I have a lot of people, online and offline, who share or have shared many of the same experiences, and who have advice, or are just up for having a coffee or a beer when things are tough.

Academia as supervised learning 

Where does the not-so-supervised learning come in? It seems to me that a lot of advice of what we need to do to “succeed” is based on rules derived from previous “successful” CVs – publishing at particular venues, doing a postdoc abroad, etc. Some of these rules we are explicitly told as advice, others we assume ourselves.

But there is a lot of missing from this picture. The “success” label is a function of much more than particular activities, but also the state of the world (number of tenure track positions, number of students, etc), and the state you are in yourself (including anything else you have to deal with next to the job search). These features have not been taken into account when creating the rules. So even if you do follow all the rules you might get a disappointing outcome, and vice versa.

There might also be opportunities that didn’t exist before. For example, few full professors would have been using Twitter during their PhDs and postdocs. As a yet “unlabeled” activity, it probably wouldn’t come up in any rules, but it can be a powerful tool for early career researchers.

Last but not least, it’s important to remember there’s more than one success metric, and why I’ve been writing “success” in a CV sense. Ultimately success should probably involve being happy, which can be achieved through other types of jobs. And perhaps some of these jobs are not even in our dataset yet.

CV of Failures vs Shadow CV

by

If you’ve been following me for a while, you know that the “CV of Failures” or “Shadow CV” are a recurrent theme on my blog and on my Twitter timeline. In this post I discuss why I think the two concepts are actually quite different, and why this difference is important. 

CV of Failures

The CV of Failures, originally proposed by Dr. Melanie Stefan, is mostly that – a list of things that didn’t work out. Most often I see failures interpreted as “things I tried to do but didn’t succeed”. This category includes rejections of jobs, grants and papers. Although these failures are hard, I think they are not very personal because they depend on both everybody else who applies, as well as everybody who evaluates you. 

Much less common is to include things that are more personal – something you just didn’t do (but should have). It’s often not your fault, because of how academia is structured – but in retrospect, you would have done these differently. This category includes focusing on the quantity over quality, not taking opportunities out of fear and being a bad mentor to others. Even more personal, it’s neglecting your health or people around you – although I haven’t seen many examples of people sharing this. 

Shadow CV

What is a shadow CV then? To me it is larger than the CV of Failures. While the CV of Failures focuses on things you have done (or didn’t do), there are many more things that influence where your CV or CV of Failures are today. It’s all the additional challenges faced by one person, and all the privilege enjoyed by another. 

There are efforts to take parts of the shadow CV when evaluating people. For example, in the Netherlands time off due to parental leave or illness can be listed on a grant application. But this is limited in scope and does not include, for example, chronic illness, financial insecurity or family problems. Even if you are lucky to work in a place where people are supportive – and I have been – these things are invisible to somebody deciding whether you belong to the top 10% of researchers who deserve funding.  

But the shadow CV is not only the challenges. It is also all the things you are proud of but that are not on any CV, like finishing a paper despite having a difficult year or a thank you email from somebody who’s read it. Regardless of what your reviewers say, don’t forget that these are the true successes.

 

My biggest mistake and what it taught me about the academy

by

One of the most read posts on this blog is “7 things I wish I would have done during my PhD“. Although none of the advice there is surprising, it seems important to hear stories about mistakes, without “how to” one-size-fits-all rules attached to it. So when Times Higher Education invited me to write about “My biggest mistake & what it taught me about the academy”, I didn’t have to think twice.

In this piece I talk about not realising the importance of mentors early on in my academic career. I can view this mistake as something that led to a CV that is suboptimal, at least in the eyes of my reviewers. But now I also realize it’s made my journey much more interesting, and I wouldn’t trade what I was able to learn in this process for a few more high impact factor publications.

I haven’t yet decided on what the best trade-off is, but would love to hear from you! Should your mentors prepare you for everything? Or do you need to experience some mistakes yourself? Let me know after you read the article, in a comment here or on Twitter!

Mastodon More Mastodon
%d bloggers like this: