Don’t run your projects open-loop
The outcome is what you’re judged on; but the process is your biggest lever — how to run a project postmortem.
Projects often end without closing the feedback loop, i.e., asking about the process itself. Generally, the outcome is what you are evaluated against, but the process is what matters in the long term and it is your biggest lever to improve — so by not reflecting on it, you leave much on the table.
When I started specializing in control engineering, the professor demonstrated the difference between steering and control at the whiteboard: two people were each asked to connect two dots. The catch: one of them had to close their eyes after placing the marker on the starting point. You can imagine the outcome of not having feedback — and I do not need to tell you how trivial the task was for the person with eyes open.
This is exactly what most people do when moving to the next project: they might build upon the outcome, but they fail to recognize the process as a resource. It is like fire-and-forget control (which is not really control, as you just make a decision and then forget about adjusting), then continue the next project the same way, leading to the same mistakes.
A project without a postmortem is an open-loop controller, it is much less likely to guarantee reaching your goals smoothly.
The solution is simple but not easy: conducting a postmortem, i.e., a retrospective analysis of how things went. This is cheap in terms of time and effort — you surely can spend 1–2 hours on a project that took months. The upside can be substantial, as it can surface skeletons that were conveniently hidden in the closet. There is no free lunch, though: it can get uncomfortable — and, all else being equal, the more uncomfortable it gets, the closer you get to recognizing the real problems and pain points. That’s the tax you need to pay to learn. So ask for feedback, even if it hurts — especially then.
So — where do we start?
Before you start
Take some rest. It does not make sense to discuss hard questions when you are angry, lonely, or tired. Not every group will want to do this, because asking the hard questions — the ones you can actually learn from — is uncomfortable. But if you cannot get past the “oh, it was such a great pleasure working with you” responses, you won’t learn. You have to put in the work first to establish trust and psychological safety so everyone can open up. There are tools for anonymous feedback — though that might not work if the group is very small.
What follows is a set of guiding questions. You can also use them to reflect on your own and discuss them with your colleagues.
Self-reflection
Change starts with you, which requires honest (alas, often painful) self-reflection. It is about knowing your modus operandi — this is why I encourage you to write your own “Working with me manual”; see mine on my website.
These questions are not just for you to ask yourself (I recommend starting with that), but then to ask your teammates, so that you can do a reality check on how you and others see you.
The highest leverage (and most high-level) question is:
do you know your preferred way of working?
You need to figure out how you work best — expect it to change — and keep track of that. As you reflect on the specifics of the project, the necessary (surface) question you will probably start with is:
what were the things you did well/inappropriately?
This question can also provide deeper insights if you ask your teammates and then compare their responses to yours. Then you will get a better understanding of
how well do you know yourself? And how clearly do you see yourself (compared to how others see you)?
And, this will teach you something, even if the project’s outcome is an utter failure. If you can articulate what you learned, then the project was not in vain, even though this does not make it less painful in the moment. To make things even more complicated, it might be that a project is a treasure trove for learning, but lacks on the human side. Thus, your answer to the following question will require intensive soul-searching:
if the project was not the smoothest experience (conflicts, interest mismatch, etc.), would you still want to continue working on the topic/with the people because you think you can learn something useful?
This includes assessing how the different aspects add up, e.g.:
did you enjoy working on the topic/with the people? was it energizing or draining to work with those people?
were the upsides worth the downsides?
if there was a crisis, did you get both kinds of support (problem solving and empathy)? e.g., a colleague who debugs alongside you vs. one who just says “this sucks, I’ve been there”
what were the things you dismissed during the project as “ah, it’s annoying but let’s get things done first”? what is worth following up on?
what were the pain points?
If you thought about how you see the project, you are not done: you need to communicate these. Both to get the baseline for comparison, and to let others’ observations and opinions surface your blind spots (everyone has them).
Communication
Most issues and friction stem from assuming that the intent of communication has been achieved (a.k.a., you think that what you wanted to communicate is what you actually said, and what the other party actually understood). Think about the misunderstood conversations, and ask:
did you and the others ensure that the intent of communication is clear?
The simple act of asking others to summarize what you said can work wonders.
There are particular issues that frequently come up in (research) projects. Since research is generally much more international and diverse, cultural and experiential differences can make communication more difficult to interpret (e.g., some cultures value direct communication, while others prefer more implicit, implied messages). Thus, it’s worth asking whether anything stemming from such differences could have been clarified.
When you start your PhD and have a single project, it can be hard to imagine how many things more senior people juggle. Thus, you might have expectations about their commitment, but they might see things differently. Not being clear about priorities can lead to the biggest pain points down the line, when you realize you won’t be able to meet the deadline as not everybody can invest as much time as you thought.
Clarifying these expectations upfront is also how you prevent the awkward authorship debates — way too frequent in academia1.
The same goes for clarifying expertise and interests. Someone might be amazing at coding, but they might not want to do it in this project — so think about the matrix of expertise present and how it compares to the project’s requirements.
what kind of help/expertise did you need that was not present in the project?
Depending on career stage, team members may have different goals and foci, and these can shift during the project. Maybe the life/career situation of a project member changes, e.g. they are graduating/leaving for an internship, or their research interests shift. For longer projects, regular check-ins, especially near deadlines, can reduce frustration.
Some of these conversations are hard on their own, even on a level playing field. If there is power asymmetry within the team, you might need to be more careful. To decide which conflicts to lean into, I like asking whether this conflict can deepen the relationship.
Smooth communication already improves the experience a lot. The other game changer for reducing friction is to have systems in place — not too much, and surely not the overengineered stuff current productivity advice is promoting, but the most minimal thing that works for you.
Project hygiene
The elephant in the room is that project management is rarely taught in grad school — but it still might be expected to have the skills. This goes beyond being a project leader and also includes effective teamwork. See my notes on time management and knowledge management.
It starts with having a plan, which many do not have — especially at the beginning, when you are new to the field, thinking about things beyond the technical can feel overwhelming. And plans themselves will be overwritten by Murphy. However, as Eisenhower said:
Plans are useless, planning is useful.
Because it forces you to think about what can (and will) go wrong. It helps address one of the biggest and most frequent pain points: lack of clarity about roles and task allocation, i.e.:
who does what by when?
This includes triaging on what should and should not be part of the project.
Since plans shatter when they meet reality, there will be failures and mistakes to analyze. It is useful to get to the root cause: lack of time, lack of resources, or a planning error. If you reflect after submission, it’s also a great time to summarize what needs to be done for the rebuttal.
Here, the key question is:
did you have enough margin of safety?
The compute cluster can go down just before the deadline, OpenReview and Overleaf can be inaccessible, and supply chains can break down for the physical resources you might need.
You cannot avoid every breakdown (there are black swans, and your time and financial budget will be limited; or a colleague can be ill or have a family emergency), but you can — and should — be aware of the bottlenecks.
Meetings have a bad rep, but they can be short and satisfying — the lever there is to be prepared and ensure things run efficiently.
To avoid losing the big picture, I love asking:
what would need to change to make things easy?
Project-related information might have been scattered, responsibilities unclear, meetings became the default without a leader, and actual content and actionable outcomes were missing. Or maybe the timeline was too ambitious, given the availabilities and scope, or the headroom for delays was insufficient.
Now run it forward
When you read these questions — and remember the pain such situations caused you and your teammates — you might wonder: it would be great to have this clarified in advance. Well, nothing is stopping you from doing that.
If analyzing the failures and mishaps in hindsight is useful, it is even more useful to prevent (some of) them from happening. Assume you are at the start of your next project and it has already failed. Why could it have failed? Resolve those things now.
Many thanks to Fanfei Li and Jana Zeller for their feedback and our fruitful discussion.
There is another type of authorship debate, i.e., the one when you and your colleagues are trying to convince the other to be the first author. It’s a heartwarming experience, and I was lucky enough to have two such conversations with Evgenia Rusak and Alice Bizeul. Thanks Evi and Alice for this experience!