A PhD expectations guide
The unknown unknowns of a PhD — and a checklist to make them known
When I started my PhD, I thought I knew what I was signing up for. I had aced my studies. I knew how to grind. I was eager to prove myself. So I did what had always worked: I put my head down and pushed.
Weeks passed without a single meeting with my supervisor — because I had nothing to show. I kept postponing, waiting until I had an answer worth presenting. It never occurred to me that a meeting could be for asking questions, not only delivering solutions.
That was my first unknown unknown. There were many more.
False signposts of certainty
A PhD feels deceptively simple from the outside. You agree on a topic. You have a supervisor. You do the work. You get the results — or so you might have assumed.
Credit: Florian Aigner. Source
In reality, the rules you internalized as an undergrad — that problems have solutions, that the toolbox is given, that effort maps to visible progress — quietly stop applying. The comfortable solution is to keep spinning your wheels — do what worked before, harder. It takes courage and self-reflection to see how much you don’t know1.
This is, at its core, a problem of unclear expectations. There are unknown unknowns you cannot anticipate, and the curse of knowledge makes this worse from both sides. Supervisors have long forgotten the fog of the first year — they may not even realize what they’re leaving unsaid. Students don’t yet know which questions to ask. Both assume the expectations are clear — and neither checks2.
An overwhelming majority of PhD students suffer from this. So let’s lift the fog on expectations.
Unclear expectations are not the same as misaligned ones. Misalignment means you want X, your supervisor wants Y, and both of you know it. Hopefully, if you followed my questionnaire for selecting a supervisor, you are not in that camp. What follows is about the murkier problem: expectations that were never made explicit in the first place.
Things no one tells you upfront
Questions are better than answers
I made the mistake I see many PhDs make: I was afraid of booking meetings with my supervisor because I had no results3.
Rule of thumb: You don’t need to bring results to a meeting. It’s enough to bring questions and problems.
This is fundamentally different from what you were used to during your studies, where you aced all tests and solved all the problems. Here you are at the forefront of knowledge, where questions, failure, and getting stuck are the norm.
As one of my friends, Jana Zeller, quipped:
The task of your supervisor is to help you succeed.
Ask for their time accordingly. If they don’t have one, volunteer to set up a calendar for lab members to book meetings. If they have a secretary, be proactive and ask about the PI’s constraints so you know when it’s easier to get a slot.
Bad ideas are part of the process
Most of your ideas will be bad — that is normal. The problem is that they are yours, and attachment prevents you from seeing their faults — kill your darlings. You need to develop the internal taste to recognize weak ideas early, before they cost you months.
You build that taste by exposing your ideas to criticism. You don’t need cheerleaders; you need people who point out where your ideas fail. Expect most ideas to die, and treat that as the process working, not as failure.
See also: Taste for Makers, You and Your Research
“Can do” does not mean “should do”
In my undergrad, I never needed to question whether solving a task made sense — it did, if only because it contributed to my grade.
In a PhD, you need to internalize the distinction between “can do” and “should do.” As with many things, I learned this the hard way: I once spent weeks on a proof that turned out to be pointless. As far as I can tell, it was correct — but I had not asked whether it was worth doing.
“Worth doing” does not necessarily mean having a world-changing impact. Sometimes it means “only” that you learn something. But you need to ask yourself before spending weeks on something whether it makes sense.
Just because you can do something does not mean you should.
This problem comes in many disguises: having a hammer and mistaking everything for a nail, being carried away by inertia, or playing someone else’s game — even a groundbreaking result is the wrong result if it doesn’t align with your goals.
This doesn’t mean you shouldn’t explore — curiosity-driven research is how breakthroughs happen. But exploration with intention is different from inertia. Know why you’re exploring before you spend weeks on it.
Rule of thumb: Ask your why before deciding what you do.
There is no universal toolbox
Experimentation and failure are necessary to find your tools — whether productivity systems, your ideal daily schedule, or research methods. There will be conventions of your field you need to be aware of, but they should not constrain how you work.
Embrace experimentation and fail fast. Not for failure’s sake, but to separate the wheat from the chaff — I’ve written about failure at length.
But do not mistake shiny tools for impactful productivity. Start small, pick the simplest tool that is good enough, and extend if necessary. Time spent on tools is time not spent on research.
See also: An allostasis theory of failure
Asking for help is not a sign of weakness
Feedback loops only function if you reach out when you’re stuck.
Checking someone’s code or proofs can go a long way — though the more involved the feedback you seek, the less frequently you can expect it (but do ask!). Instruction accelerates learning the most.
This is also the best way to calibrate your expectations. Maybe finishing a project in 6 months was unrealistic from the start, and you set yourself up for failure — and unnecessary suffering.
I know this can feel awkward, especially if you're used to having all the answers. It doesn’t have to be a formal meeting or code review — a coffee chat or a passing mention during lunch counts too.
See also: Kind and Wicked Learning Environments
You are the expert
One of the most frequent mistakes I made was assuming that colleagues, reviewers, and supervisors are familiar with the intricate technical details of my project. They know the field and the idea — but how would they know why my code doesn’t work or why the proof is stuck?
Provide context top-down. People will signal the level of detail that is enough for them. It will almost always be less than you think.
Rule of thumb: If you wrote a three-page summary, cut it down to half a page. You have much more time to spend on a single idea, project, or document than your mentors.
This does not mean you should remain superficial. It means starting with the big picture and building up complexity incrementally — a skill that will serve you in papers and talks alike.
Lack of feedback/response is not a sign of neglect but busyness
No answer from your supervisor doesn’t necessarily mean ghosting or lack of interest. More often, it means busyness and forgetfulness. Reminders are always appreciated — and necessary.
Rule of thumb: Write more reminders than you think necessary/prudent.
Your PI has a lot on their plate — running the lab, writing grants, reviewing, teaching. This can steal their time even at the last minute, leading to cancelled meetings. It is not personal.
People can be picky about authorship
Authorship disputes are common, and your inexperience with the norms makes early-career situations especially awkward. Clear this up in advance. Not all “authorship fights” go the way you’d expect — some people will fight to put you in a more prominent position4.
Rule of thumb: Discuss authorship expectations before a project starts, not after tensions build up.
I remember once thinking: why does X want to be on this paper? I did the whole project — wrote the code, ran the experiments. That person “only” gave me feedback. I changed my mind on this. Nowadays, I ask:
Would this project have succeeded if that person had not been involved?
If the answer is no, we have a (joint) first/last author. Beyond that, nuance matters — feedback alone or a single conversation is not enough, but active involvement in shaping the work is.
Some journals, such as TMLR, have clear criteria for what constitutes authorship. Check, and if uncertain, ask — earlier than you think necessary.
Reviews can be unfair
Reviews can be unfair, outright dismissive, or even aggressive. This is common — not good, but common. It does not mean your work is bad.
Detaching your self-worth from the feedback on your work is hard but essential for a sustainable career.
Writing reviews will help you understand (some of) the criticisms you receive. I’ve written about both how to write reviews and how to rebuttal.
The next deadline is always around the corner — it’s up to you to take rest
Research never stops, even though it has milestones along the conference cycle. If you don’t plan to rest, you will burn out5.
The high of submitting fades quickly because the next deadline is already approaching. You may need to prepare the preprint or write reviews for the same conference. Pace yourself.
Missing a deadline is not the end of the world — even though it feels like it. Give yourself a day or two to commiserate. Then pick it up where you left off, and reflect on what went wrong.
The mindset to adopt
Be humble. Make it explicit that you are here to learn, and since you don’t know many of the conventions and norms, you are asking to learn those.
Earning a PhD does not make you immune to cognitive biases, so practicing intellectual humility is the priority. This comes with lots of questions. As an upside, it will accelerate your progress in every pursuit of your life because you will learn much faster by admitting what you don’t know — and these include the expectations.
Doing a PhD is hard: you are pushing the boundaries of not just your own knowledge, but of humanity’s. The journey should not be made harder by implicit norms and mismatched expectations.
My shift from answers towards questions — from proving myself to asking better questions — changed everything. It accelerated my research, improved my relationships with supervisors, and freed me from the weight of pretending I had it all figured out.
A checklist to clarify expectations — with yourself and your supervisor
The items below are split into two: things to work out on your own, and things worth discussing with your supervisor. Consider revisiting this after your first few months.
Work out for yourself
Am I starting work before asking whether it should be done at all? Do I know my “why”?
Am I holding onto an idea, rather than exposing it to feedback early?
When a review is harsh, am I separating the quality of my work from the tone of the response?
Do I have a system for managing my work that I’ve actually tested, or am I running on defaults? Do I embrace some experimentation?
Have I scheduled rest, or am I assuming it will happen?
Am I assuming expectations are clear — or have I actually checked?
Discuss with your supervisor
Have we agreed on what meetings are for? (Asking questions, not only presenting results.)
Do I know what “enough progress” looks like before our next meeting?
Is the scope of my current project mine to decide, or does that need a conversation?
Have we discussed authorship expectations for any ongoing collaborations?
If I send an email and don’t hear back, what is the best way to follow up?
What would you want me to come to you about that I might currently be handling alone?
The ancient Greeks knew this all along — “know thyself,” inscribed at Delphi. As Stuart Firestein argues, recognizing the boundaries of your knowledge is how science actually works.
Power dynamics can compound the problem. Even in relatively flat academic cultures, the asymmetry is real. If approaching your supervisor feels daunting, start with senior PhD students, postdocs, or lab technicians — their experience is fresher about what it felt like at the beginning to start doing research.
It also did not help that I was much shier and more of a perfectionist back then.
I have the privilege of knowing multiple people with such a noble character: Evgenia Rusak and Alice Bizeul.
Everyone rushes before deadlines, so resources like compute and supervisor time get scarce. Plan ahead and prioritize early — it saves a lot of stress.
Thanks for the insight!