Habit, Not Hack: Stop Borrowing Timelines (Trainee)

The moment you start measuring your path with someone else's ruler, you've already lost your way.

The problem didn’t start with a deadline.

It started with a conversation in the hallway.

“So-and-so just defended in four years.”
“They already have three first-author papers.”
“She’s applying for faculty jobs this cycle.”

Alex smiled, congratulated them, and continued down the hallway.

The conversation lasted less than a minute. The feeling it produced stayed for the rest of the day.

I’m behind.

The thought followed Alex back to the desk, where an unfinished analysis was still open on the screen. It followed them into lab meeting, where another trainee presented a clean set of results from a project that seemed to be moving exactly as planned. It followed them home, where a LinkedIn post announced someone else’s new position, complete with a polished summary of the path that had led there.

Four years.

Three papers.

Faculty applications.

The milestones were easy to compare because they were easy to count.

What was harder to see were the conditions underneath them.

The project that worked on the first approach. The mentor who had already established the method. The stable funding. The collaborator who returned samples on time. The absence of a major change in research direction halfway through the degree.

Alex’s project had none of those things.

The original question had been revised twice. A key instrument had been unavailable for several months. One line of experiments had been abandoned after more than a year of work. Alex had also spent significant time keeping a shared method running for the rest of the lab—work that mattered, but would never appear in the title of a dissertation chapter.

None of that fit neatly into a hallway sentence.

So Alex compared the visible outcome of someone else’s path with the full, complicated reality of their own.

And the conclusion always seemed to be the same.

I should be further along by now.

How This Happens

Research training makes timeline comparison unusually easy.

There are recognizable markers: qualifying exams, first-author papers, conference presentations, dissertation proposals, defenses, fellowships, job applications. These milestones create the appearance of a standard sequence, as though everyone is traveling the same road and the only meaningful difference is speed.

But research timelines are not standardized in the way the milestones suggest.

They are shaped by project design, technical risk, funding stability, access to equipment, mentorship quality, authorship decisions, institutional requirements, collaboration delays, changes in direction, and responsibilities outside the lab.

Even two trainees in the same program can be doing fundamentally different kinds of work.

One may inherit a mature project with preliminary data and a working protocol. Another may spend two years establishing the system itself. One may publish several smaller studies. Another may be asked to build a single, technically demanding story. One may have a supervisor who makes decisions quickly. Another may wait weeks for feedback before moving forward.

The dates still look comparable.

The conditions are not.

The problem becomes more complicated because other people’s timelines usually arrive as finished narratives. A defense announcement does not include the twelve months spent troubleshooting an assay. A new job post does not list the applications that received no response. A publication announcement does not explain how many people, resources, or abandoned directions made the final paper possible.

The milestone is visible.

The infrastructure behind it is not.

When that missing context goes unacknowledged, comparison turns into a false measurement. The question stops being, What does my project require?

It becomes, Why am I not moving at the speed of someone whose conditions I do not actually know?

What Alex Tried

The problem became harder to ignore during a meeting with the PI.

“How long do you think the remaining experiments will take?” the PI asked.

Alex had thought about the answer.

The realistic estimate was six months, assuming the assay stabilized and the collaborator delivered the next set of samples on schedule.

What Alex said was, “Probably three or four.”

The shorter estimate came out automatically.

It was not based on the work. It was based on what Alex thought a capable trainee should be able to say.

The PI wrote the estimate into the project notes.

Alex left the meeting already knowing it was unlikely to hold.

That evening, Alex opened a notebook and wrote two headings.

What actually affects my timeline

— Project scope
— Technical uncertainty
— Equipment access
— Reagent and sample availability
— Collaborator response times
— Funding interruptions
— Changes in project direction
— Time required to learn unfamiliar methods
— Teaching, service, and shared lab responsibilities
— Health, caregiving, and life outside the lab

Then, underneath:

What does not determine my timeline

— Someone else’s publication count
— Someone else’s defense year
— Someone else’s job title
— Someone else’s fellowship announcement
— A polished career update with the delays removed
— The fastest example I have heard repeated in the department

The lists did not make the comparison disappear.

Alex still knew who had defended quickly. Still noticed who had published more. Still felt the small jolt of anxiety when another milestone announcement appeared.

But the exercise revealed something important.

The timeline Alex had been using was not really a timeline.

It was a collection of borrowed expectations.

So Alex tried building one from the work itself.

The remaining project was divided into sections:

— Work that had already been completed
— Experiments required to answer the central question
— Experiments that would strengthen the story but were not essential
— Tasks dependent on collaborators or shared resources
— Steps with significant technical uncertainty
— Decisions that would need to be made if the first approach failed

Next to each section, Alex wrote the assumption behind the estimate.

This takes four weeks if the assay remains stable.

This depends on receiving samples by October.

This estimate assumes one repeat, not three.

This step may need to be redesigned if the first condition fails.

This experiment was added after the original project plan.

The timeline became longer as the assumptions became visible.

It also became more honest.

What Changed When the Timeline Became Specific

At the next meeting, Alex brought the revised plan.

“The estimate I gave last time was too short,” Alex said. “I was answering based on what I thought the timeline should sound like, not what the remaining work actually requires.”

The PI looked at the document.

Alex pointed to the sections with the greatest uncertainty.

“This part depends on the collaborator. This part assumes the method works without another round of optimization. And these two experiments were added after we changed the direction of the project.”

The conversation shifted.

Instead of asking whether Alex could move faster, they started asking what the project actually needed.

Which experiments were essential?

Which ones had become part of the plan because they would be interesting, rather than because they were required?

What could proceed while the samples were delayed?

At what point would they stop optimizing the current method and choose another approach?

The PI removed one experiment from the immediate plan and postponed another until the central dataset was complete. They agreed to revisit the timeline after the next decision point rather than treating the current estimate as a promise that could not change.

Nothing about the project became easier during that meeting.

The assay was still uncertain. The samples were still delayed. The previous year of work could not be recovered.

What changed was the relationship between the work and the timeline.

The schedule was no longer being asked to prove that Alex was progressing at an acceptable speed.

It was being used to identify dependencies, make decisions, and plan around reality.

Alex still saw other people’s announcements.

But they no longer carried the same authority.

A four-year defense was a fact about someone else’s path.

It was not evidence that Alex had failed to follow it.

The Habit: Build Timelines From Conditions, Not Comparisons

The habit is not to stop noticing other people’s milestones. That is probably unrealistic in an environment where progress is discussed constantly and careers are built around visible markers.

The habit is to interrupt the moment when someone else’s milestone becomes a deadline for you.

When you find yourself thinking, I should be further along, ask:

According to whose timeline?

Then ask the more useful questions:

What has shaped mine?

What work is actually left?

What assumptions is my estimate based on?

What is within my control, and what depends on someone or something else?

Has the scope changed without the timeline changing with it?

A working timeline should include more than dates.

It should identify uncertainty.

Instead of writing:

Complete experiments by December.

Try:

Complete the core experiments by December if the assay remains stable and samples arrive by October. Reassess after the first dataset. If the method continues to fail, decide whether to redesign or remove the experiment.

The second version may feel less confident.

It is actually more useful.

It tells you what the estimate depends on, when the plan should be revisited, and what decision will be required if the assumptions no longer hold.

That is what a timeline is supposed to do.

A Note on What This Isn’t

This is not a habit about moving slowly without accountability.

It is not permission to avoid deadlines, stop planning, or explain every delay as something outside your control. Research still requires decisions, follow-through, and an honest assessment of whether the current approach is working.

It is also not a claim that all timelines are equally reasonable.

Sometimes a project is drifting because the next step has not been defined. Sometimes perfectionism has expanded the work beyond what the question requires. Sometimes a difficult decision is being postponed. Sometimes additional support, training, or clearer expectations are needed.

A realistic timeline should make those problems easier to see, not easier to avoid.

The distinction is between accountability and comparison.

Accountability asks whether the plan reflects the work, whether commitments are being met, whether obstacles have been communicated, and whether decisions are being made when circumstances change.

Comparison asks why your path does not resemble someone else’s, even when the conditions, project, support, and goals are different.

One produces information.

The other produces pressure without necessarily producing clarity.

The habit is not to remove urgency from research.

It is to make sure the urgency belongs to the work in front of you—not to an invisible race you entered by overhearing someone else’s milestone.

For Supervisors and Mentors

Trainees do not build timelines in isolation.

They build them within projects whose scope is often shaped by supervisors, funding decisions, publication expectations, collaborator commitments, and changing scientific priorities.

When a trainee consistently underestimates how long the work will take, the problem may not simply be poor planning. They may have learned that only the most optimistic estimate sounds acceptable. They may be trying to protect themselves from appearing slow, uncommitted, or less capable than their peers.

Ask what assumptions sit underneath the date.

“What needs to be true for this timeline to hold?”

“Which parts are technically uncertain?”

“What depends on another person or resource?”

“What has been added since the original plan?”

“What would we remove if the central question could be answered without it?”

These questions do not lower the standard.

They make the standard visible.

Supervisors also have a responsibility to acknowledge when the project itself has changed. A trainee should not be held to the original completion date after the question has expanded, the method has changed, or additional experiments have been added without a corresponding discussion of time.

And comparison should be used carefully.

“Another trainee completed this in six months” may sound like useful context. Without accounting for differences in experience, project maturity, technical support, and access to resources, it may communicate little more than an expectation to reproduce an outcome under different conditions.

A timeline should be a shared planning document.

It should help the trainee and supervisor see where the project is going, what could disrupt it, which decisions are approaching, and what support is needed.

It should not become a silent test of whether the trainee deserves to be there.

Other people’s milestones may help you see what is possible.

They cannot tell you what your work should require, what your life should hold, or how quickly your path should unfold.

Notice the comparison.

Name the conditions.

Return to the work in front of you.

That is not a hack.

That is a habit.

✨ Explore Career Season Self-Assessment, 5-Year Vision Map, and Impostor Syndrome Reality Check printables to help build a path that fits your race, not someone else’s.

Stories are fictionalized or composite narratives, created to illustrate common challenges and patterns in research life. They are intended for educational and reflective purposes and do not represent any specific individual or institution.