NeuroTrailblazers banner

Lab Norms: What Nobody Tells You in the First Month

Asking for help, what a PI expects but will not say, how meetings actually work, escalation paths, authorship and credit including proofreading, and what to do after a mistake that affects someone else.

Where this starts

Module 02 is the taught version of this material: five hidden-curriculum scenarios, a role-and-expectation map, three communication scripts, a mentor support map, and an ethics commitment, delivered in 90 minutes and producing a personal lab navigation playbook. Do that first if you can. The playbook is the artifact; this page is not a substitute for it.

This page picks up where Module 02 stops. Its Part B gives you three script templates and asks you to customise them. What it does not do — because a worksheet cannot — is say why each clause is in the script, what happens when you drop one, and how the scenarios it lists actually play out. That is what follows.

Asking for help without appearing incompetent

The script, clause by clause

Module 02’s template:

“I have been working on [X] for [time]. Here is what I have tried: [list]. I am stuck on [specific point]. Could you [specific request]?”

Each clause does a job. Drop one and the request degrades in a predictable way.

“for [time]” — establishes that you did not ask immediately, and lets the other person calibrate how hard the problem is. Include it even when the time is short; “for about twenty minutes” is a perfectly good opening if twenty minutes is your agreed threshold. Never inflate it. Inflated numbers are the one part of this script that can actually damage you, because they are checkable.

“here is what I have tried” — two to four items, as a list. Its function is not to prove effort; it is to eliminate search space. You are telling the helper where not to look, which is what makes the request cheap to answer. A list of eleven things reverses the effect: it reads as flailing rather than as narrowing.

“I am stuck on [specific point]” — converts an unbounded request (“can you help me with the analysis”) into a bounded one. Unbounded requests are not refused, they are deferred, and deferral is indistinguishable from refusal on a deadline.

“Could you [specific request]” — name the size of the favour you want. “Point me at the right function”, “look at this for five minutes”, “tell me if this whole approach is wrong”. People say yes to bounded favours and postpone unbounded ones.

A fifth clause Module 02 does not include, and should:

“If this should be obvious, say so and I’ll go and read up on it.”

This voluntarily caps their effort, and it converts the exchange from a competence question into a routing question. It is also the sentence that makes asking safe in an environment you have not yet calibrated.

Agree the threshold in advance

The real question is not how to ask but when. Ask your supervisor directly, in week one:

“What’s the right amount of time to be stuck before I come to you? I’d rather use your number than guess.”

Answers vary enormously between labs and people — that is the point. Once you have a number, honour it in both directions. Asking after two hours because two hours was the agreed threshold is following an instruction, not admitting weakness, and you can say so in the message: “this is the two-hour mark we agreed.”

Ask in the public channel

Where a lab has a shared channel, ask there rather than by direct message. Three reasons, and the third is the one people who already know this norm are actually acting on: the answer becomes reusable, more people are able to answer, and your work becomes visible. A researcher whose questions are all in DMs is invisible in the record of who was doing what.

Why this is invisible

If your model of asking questions was formed in a classroom, asking means admitting you were not paying attention. In research it means the opposite: a question is a report on the state of a shared problem. Nobody announces the switch.

And the fear is not irrational. Some environments do penalise questions, and telling someone their worry is imaginary when it is not is worse than useless. Calibrate by observation in your first month: who asks, in what venue, and what happens next. If senior people ask questions in public and nothing bad follows, the environment is safe and you can move. If nobody ever asks anything, that is information too — route through a peer or a second mentor from your mentor map instead.

Four things not to do

What a PI expects but will not say

None of these will be stated. All of them are enforced.

  1. That “have a look at this” carries a deliverable and a date. Find out which: “Do you want a paragraph of impressions by Friday, or is this background reading?” Two possible answers, one question, no ambiguity left.
  2. That you keep a decision log, because they will not remember what they told you. After any meeting where something was decided, send five lines: date, what was decided, why, what you will do next, what you need from them. This single habit changes how you are perceived more than any other item on this page, and it protects you when the recollection later differs.
  3. That you bring a recommendation, not just a problem. “X is blocked. Two options: A or B. I would do A because it costs a week less and we can reverse it. Do you agree?” Being wrong in that format is fine. It is the transition the MERIT framework calls initiation, and supervisors watch for it explicitly.
  4. That silence is not consent. No reply to your email is not approval. If you need a decision, say what you will do by default: “Unless you tell me otherwise by Wednesday, I’ll go with A.”
  5. That bad news arrives early. This is a rule about you, not about the news. Module 02 states the underlying principle plainly: labs that punish errors get fewer error reports, not fewer errors — and the corollary is that a lab which does not punish them expects them promptly.
  6. That they cannot tell you are stuck unless you say so. The absence of a complaint is read as progress. Two weeks of silence followed by “I never got it working” is a worse event than five separate admissions of being stuck.
  7. That you own the logistics of your own meetings. Booking the room and sending an agenda 24 hours ahead is baseline, not initiative.
  8. That “this is interesting” sometimes means “I do not understand what you have shown me”. Follow up: “Which part would be most useful to go into?”
  9. That a suggestion made in passing is still a suggestion. If you decide not to do it, say so and why. Quietly not doing it is the version that damages trust.
  10. That casually phrased deadlines are real deadlines.

The conversation to have at week four

“I want to check I have your expectations right. Here is what I think you expect from me: [three to five items]. What is missing, and what have I got wrong?”

Write the list first, then read it out. The gap between what your supervisor believes they conveyed and what you wrote down is, per the education models page, the most useful diagnostic available in the orientation stage — and it is a diagnostic that only exists if someone writes the list. Usually that has to be you.

How meetings actually work

Lab meeting is a rehearsal for review, not an examination. The audience is trying to find the hole in the argument because that is the service they are providing. Someone attacking your null model is doing you a favour that a reviewer would otherwise do eighteen months later, in writing, to an editor.

“Any questions?” at the end of a talk usually means “we are at time”. It is a closing ritual unless the chair has spent effort making it something else. If you want to ask anyway, make it cheap: “One quick one — …” signals you know the ritual and are briefly suspending it.

“Any questions?” from a supervisor in a one-to-one means it literally. Always arrive with two. The absence of questions in a one-to-one reads as disengagement, which is the opposite of the impression the silence is usually intended to create.

Presenting a bad week. There is a format, and it is not an apology:

“Here is what I set out to do. Here is what happened. Here is what I think it means. Here is what I will do next. Here is where I want your input.”

A negative result presented as data is a completely different event from the same result presented as a confession. Module 02’s fourth concept — failure as data — is the principle; this is the delivery.

When you do not understand a word in a talk. Write it down and keep listening; look it up in the Connectomics Dictionary afterwards. But if three people around you look confused, ask, because you are then doing the room a service. Phrase it as “can you say what X means in this context?” — the words in this context remove any implication that you have never met the term.

One contribution per meeting is a reasonable target, and it can be a question. Silence does not count against you exactly, but it means that for the purposes of everyone’s memory you were not there.

Escalation: when something is wrong

Match the rung to the problem. Skipping rungs upward without cause damages your standing; staying too low for too long damages you in a different way.

Rung 0 — a technical problem. A peer first, then whoever owns the system. Nobody senior needs to hear about it.

Rung 1 — a scoping, priority or resource conflict. Your supervisor, with two options and a recommendation.

“I have been asked for both X and Y this week and I can do one properly. I propose X, because Y’s deadline moves and X’s does not. Tell me if that is the wrong call.”

Rung 2 — your supervisor is the problem, or the issue is about fairness, credit, or resources. You need someone with standing and no stake: a thesis committee member, the graduate chair or director of graduate studies, a second mentor. This is why Module 02 makes you build a mentor map containing at least one person outside your immediate team. The map is useless if you build it at the moment you need it.

Rung 3 — safety, harassment, research misconduct, data integrity. Institutional channels: an ombuds office, a research integrity officer, the relevant compliance office. These differ in one respect that matters more than any other, and it is the thing nobody tells you:

Before you describe the situation, ask: “Can you tell me what you are required to report, and what stays between us?”

Some roles are confidential; some are mandatory reporters and will be obliged to start a process the moment you give them details. Both are legitimate. But the difference determines whether you still have a choice afterwards, and you cannot un-tell someone. Ask first, every time, and ask it as a neutral procedural question, because it is one.

Write things down as they happen. Dated notes, factual, no characterisation — what was said, when, who was present. Keep them somewhere you control rather than on the lab drive or, if the issue involves the institution, on institutional accounts. Contemporaneous notes are worth vastly more than a reconstruction six months later.

Say the unfair part plainly. Escalating carries real risk to the person escalating, and the risk is distributed unevenly: someone whose visa is tied to their position, or who has one funding source and no second offer, is not making the same decision as someone with options. Advice that ignores this is worthless. What you can do regardless: build the mentor map before anything is wrong, find out what recourse your institution actually offers while you have no reason to use it, and talk to one person outside the situation before you talk to anyone inside it.

The longer treatment is on Conflict.

Authorship and credit

The conventions, stated

Nobody will explain these to you, and everyone assumes you know them.

Conventions differ by field, and connectomics inherits from two traditions at once: laboratory biology, and very large collaborations where contributor lists run to hundreds. Do not assume the convention from the last paper you read.

The mechanisms that make the conversation easy

Two things exist specifically so that credit does not have to be negotiated as a status question:

Proofreading contributions specifically

This field has an unusually strong precedent: the FlyWire whole-brain connectome credited its 287 proofreaders as co-authors (Module 02, FlyWire case study). That precedent is real and it is worth citing. It is also not universal — plenty of projects acknowledge proofreading rather than authoring it, and sometimes that is the right answer.

So ask, in advance, in these terms: what volume or level of proofreading contribution earns authorship on this paper, and what earns acknowledgement? A project that has an answer will tell you. A project that does not has just been prompted to decide, which is itself worth doing before anyone has invested six months.

The script, and when to use it

Have this conversation before you start, when it is cheap.

“Before I start on this — can we agree how authorship works for this piece? My understanding is that if I do [scope of work], that would be [position]. Is that right?”

“Before I start” makes it a planning question rather than a claim on completed work. “My understanding is” proposes a position and offers an easy correction, which is far easier to answer than an open question. Naming the scope keeps the conversation about work rather than about status.

Then send the follow-up email: “Thanks — writing down what we agreed so I don’t misremember: …” That is not distrust. It is the decision-log norm from the previous section, applied to the highest-stakes decision you will make in a project.

When it goes wrong

Module 02’s fifth scenario — your annotation work appears in a paper without credit — is common enough to plan for. The first move is always the direct, low-temperature question that assumes an oversight, because most of the time it is one:

“I think my annotation work on X is in this paper — was I on the author list? I may well have missed it.”

If that does not resolve it, you are at rung 2 of the escalation ladder, and you should have your dated record of what you did and when. Be clear with yourself about which was promised: acknowledgement instead of authorship is sometimes the correct outcome, and sometimes a breach of an agreement, and those are different problems.

Credit you owe

Cite the dataset, with its version. Cite the people whose annotation you built on. Public availability removes the access barrier and not the attribution obligation — the point Module 02 makes about provenance, and the practical mechanism is in provenance and versioning.

When you have made a mistake that affects someone else’s work

Concealment is the only unrecoverable move. Every other version of this is survivable, and several versions of it end with people trusting you more than before.

Report before you have fixed it, not after

This is the instruction people find hardest and it is the one that matters. Somebody may be building on the wrong number right now. The cost of the error is a function of elapsed time, not of the state of your repair work. Waiting until you have a clean fix so that you can deliver the bad news alongside the good news is optimising for your own comfort at their expense.

The four-part script

  1. What happened. One sentence. No preamble, no apology yet.
  2. What is affected. Specifically: which figures, which numbers, whose work, since when.
  3. What you have done so far.
  4. What you propose, and what you need.

Worked, in this field’s terms:

“The input counts I sent you on the 14th were computed against materialization version 943, but the cell list came from 917, so around 30 of the 200 cells resolved to different objects. That affects Figure 3 and the numbers in Table 1. I have re-run everything against 943 and I am checking the ID churn now. I can have corrected numbers by Thursday — do you want the corrected table first, or a note on what changed?”

Why there is no apology in position one. An apology at the front makes the listener manage your feelings before they can act on the information, which delays the only part that is time-critical. Apologise once, briefly, at the end, and then stop; repeated apology transfers the work of reassuring you onto the person you have just inconvenienced.

Then convert it into a protocol change

Write two lines on what would have caught it. In the example above, the answer is norm 1 and norm 2 from Technical practice — pin the version, report the churn — and the fix is a notebook header block, not more care.

This step is why the counter-intuitive thing happens. A person who reports an error fast and returns with a protocol that prevents its recurrence is, afterwards, more trusted than someone who has never visibly made one, because their reliability is now something the lab can see the mechanism of.

If the error is in the published record

The obligation runs to the record, not to the lab’s convenience. Corrections and retractions exist and are used by serious groups without career catastrophe. Raise it with the corresponding author immediately, in writing, with the specifics. If it is not acted on, that has become a research-integrity question and belongs at rung 3.

The five-minute version