How to handle a hands-off supervisor

< Back to "Thoughts" | Posted on June 10, 2022

If you’ve started a PhD then you probably already have a topic and a supervisor. Your supervisor should have handed you a few problems to cut your teeth on.

Unfortunately, this isn’t always the case.

Your supervisor may be in a slightly different field to you (this was the case for me). Or your supervisor may have taken on more students than they can handle – this is a common failing of many CS professors. Occasionally I’ve even heard of some supervisors refusing to give problems to early-stage PhD students because they “want the student to practice coming up with ideas”.

That last one in particular sounds completely backwards to me. I believe ideation stems mostly from possessing a technical depth of knowledge. That isn’t something most early-stage PhD students possess yet. A better plan is to give an early-stage student some problems to work on; in doing so they can develop both their problem-solving skills and the depth of their own knowledge. (Later-stage PhD students should absolutely be able to come up with own research agenda, though.)

Regardless of the reason. For those who need it, here’s a crash-course on pursuing research independently from your supervisor.

Mindset: this is your PhD

First of all, take ownership of your PhD. It would have been nice if your supervisor were there to support you more, but they aren’t. So expect to work hard – harder than your peers have to – teaching yourself, promoting yourself, attending conferences yourself, finding collaborators by yourself, and so on.

This sucks, but is essentially no different to life in general. It’s always going to be down to you to ensure that you succeed.

Find problems you want to solve

For this heading, I didn’t write “find low hanging fruit” or “find difficult problems”. What I wrote was: find problems that you want to solve.

Doing a PhD isn’t a job. It’s a lifestyle. It defines who you are. When the going gets tough – and it will – being fundamentally invested in your topic will be what pulls you through.

And if you don’t feel that invested in your current topic? Pick a new topic. Ask yourself what you most enjoy. Ask yourself what gets you up in the morning. Then go and do that.

During my PhD I changed topic twice before finding what was right for me.

To give an explicit example. The driving force for much of my recent work was the desire to write a new unified system of differential equation solvers in JAX. I think that trying to locate the appropriate abstractions for this, and finding computationally efficient implementations, is just such a cool technical problem. It successfully distracted me writing my thesis for a couple of months. And it’s what got me my current job.

Locating these kinds of problems can be made much easier by finding a mentor figure. On that note…

Contact senior PhD students or postdocs

You will probably need a mentor figure, who knows the literature better than you do, and who can suggest research directions.

Ideally this is supposed to your supervisor, of course. But if you need an alternative, then a senior PhD student or postdoc can be a great person to reach out to.

  1. A lot of people in this position want to eventually leading teams or research groups themselves, and would love to grow their leadership experience by taking on informal mentoring arrangements.
  2. Likewise, anyone with any kind of seniority will have a surplus of ideas and too little time to pursue them. Passing these research ideas on to competent junior collaborators is an opportunity for them to increase their own portfolio of publications, without them taking on too much extra work.

This mentor figure may be from outside your research group!

Cold emailing other academics with “I’ve read your papers X, Y, and Z, and would you like to collaborate?” works ~10% of the time. Those are pretty good odds.

If you can, have a discussion first – ideally you both have something in common anyway.

In my case, my mentor figure took the nebulous autodidactical form of “the internet”, and in particular the machine learning subreddit. My actual supervisor was amazing, and always made time for me – but unfortunately we worked in slightly different fields, so his expertise wasn’t always aligned with what I needed.

Promote yourself

Tell the world whenever you write academic papers, release open-source software, and so on.

Having a public presence is not optional. Having a personal website is not optional. Having a Twitter account is not optional. If your PhD involves writing code then having a GitHub account is not optional.

You’re looking to do two things.

  1. Develop a public portfolio of work – research articles, blog posts, open-source software, and so on.

  2. Engage with the community around your work and the work of your peers. Follow the Zeitgeist of your field.

As an academic, you’re a content creator looking to engage with your audience, just as much as a professional YouTuber. Where a YouTuber puts out videos, the academic puts out research articles. The appropriate venues will depend on your field, but in my case (machine learning) it’s a mix of Twitter, Reddit, GitHub, Hacker News, some programming language forums, private email, and of course conferences.

The goal is to become well-known to the few thousand academic and industry professionals in your niche. And the dividends are astounding! As a direct result of this I’ve received numerous job offers, talk invitations, and so on. Networking, job seeking, people citing your work – all of this happen by being known.

Time management

Between teaching classes, navigating university admin, and debugging IT issues, many folks have difficulty finding time to do research.

  1. With a hands-off supervisor who may not have the clearest idea of what you’re currently working on: be willing to fend them off when they do come to you with an idea that doesn’t fit your current research agenda. I’ve met too many folks who feel the need to do everything their supervisor tells them – but remember, this is your PhD, not theirs!

  2. Avoid overheads. Say “no” when people try to distract you with unwanted teaching responsibilities, exam grading, etc. Stay focused on your goal.

  3. There’s obviously an ongoing conversation about work-life balance in academia:

    Nonetheless, putting in the hours really helps. (In my case this was aided by a pandemic limiting social opportunities.) Remember the previous heading, find problems you want to solve? Do what you love and you’ll never work a day in your life.

    My personal schedule was usually to work midday-midnight 7 days a week, but to take ad-hoc days off whenever I felt I needed it, or whenever some cool event was on.

  4. If you’re in a field that relies on programming: be good at software development. If you can, be really good at software development.

    In general, academic code quality is very bad. I regard this as a serious systemic failing, which I have seen be responsible for killing or delaying a majority of projects. Being bad at writing code isn’t just about debugging your bad code. More insidiously, it means wasting weeks or months trying to get results from code that was silently wrong all along.

    In contrast, being good at writing code means that it’s not the bottleneck; in my case it meant I could easily work on multiple papers in parallel.

    Software development is unfortunately never taught well in class, so be prepared to teach yourself this from the internet.

  5. Be willing to call it quits on a project. Give each project a really good try… but if things aren’t working after a while, then don’t keep wasting time on what isn’t going to work.

    At the start of my PhD I think I had about a 90% failure rate on project ideas. (With experience comes wisdom, and I think I’ve got it down to about a 50% failure rate now.)

Unsticking yourself

At some point, you’re going to get stuck. Without a hands-on supervisor to unstick you, you’re probably going to have to unstick yourself.

Being able to unstick yourself is probably the single most valuable skill you can possess.

I’m expecting that many/most of you reading this come from my own field of applied math and machine learning. For you, I can give more specific advice on how to unstick yourself: be prepared to move up or down from the level of abstraction you’re used to working on.

For example, when debugging code: don’t just trust the documentation. Instead, look up the source code of whichever library(s) you’re using. Add breakpoints and open up debuggers. Monkey-patch some methods and see what values are being passed around. Try modifying source code and see what happens. (Your tools are closed-source? Use better tools. In particular MATLAB is heavily outdated by now; use JAX or Julia.) In doing all of this you’re moving down levels of abstraction.

Conversely, if you’re trying to prove a theorem, then you should absolutely be prepared to go and learn the relevant mathematics. A well-developed theory will be one that abstracts away the details you don’t need. This is about moving up a level of abstraction.

Developing your underlying mathematical/programmatic skills may be a necessary part of this process.

Conclusion

In conclusion. Have the right mindset; it’s up to you to make the most of the opportunity afforded by a PhD. Find mentor figures. Promote yourself. Have a public presence. Have a public portfolio. If you do STEM, then be good at software development. Finally, be prepared to unstick yourself: you may not be able to depend on anyone else to do it for you.