The email arrives on a Tuesday. I have been following your work on this method with great interest and would love to explore a possible collaboration.
The recipient agrees the work is interesting. What they now face is an unbounded design problem: invent a project, work out who does which part, estimate whether it is worth a year of a student's time, and finish all of that before writing a reply.
So they do not reply. Or they send the warm, terminal sentence — do get in touch if you are ever in Boston — and both sides file it as a near miss.
The vague version asks the recipient to invent the project
That message contains no project. It contains an appetite for one. The recipient has to supply the question, the scope, the division of labour and the risk assessment — most of the intellectual work, done for free, for a stranger, before any commitment exists in either direction.
It is also unanswerable in the strict sense. There is nothing there to accept or decline. Declining an appetite feels rude, accepting one commits you to something unspecified, and the equilibrium between those is silence. The non-reply is not a verdict on you. It is the only move your message left available.
The general form of the problem is covered in asking a busy expert for help. What follows is the version for people proposing joint work.
Propose an object and a split
Two short paragraphs do most of the work: what the joint thing is, and who does which half.
The object. Name what would exist at the end. A paper, a section of a paper, a preprint, a released dataset, a replication, a shared protocol. "Explore synergies" is not an object.
The split. Say which parts you would do and which you are asking for. "We have the cohort and the instrument time; we would handle preprocessing, fitting and the first draft; we need your method and your read on whether the calibration step survives our sampling."
People hesitate here because proposing the plan feels presumptuous, as though you were assigning work to a senior stranger. It reads the opposite way. A specific proposal is a draft the other person can edit, and editing is cheap where invention is not. Say so in a line: this is a starting proposal, not a fixed plan, so tell me what is wrong with it.
Then add the scale. "One paper, roughly six months, one postdoc on our side" tells the reader what they are being asked to underwrite. Without it they assume the largest plausible version, and the largest plausible version is easy to decline.
Write down what you bring and what you need
Make the two lists literally, before writing the email. What you contribute. What you request.
If the second list is long and the first is short, you are asking for a favour rather than proposing a collaboration. That is a reasonable thing to ask for, but say so — the mismatch is what makes recipients wary. A favour framed as a partnership reads as either naivety or a negotiating move, and both cost you.
For requests aimed at data or code, the hidden cost is rarely secrecy. It is support. Somebody has to find the version you need, remember which preprocessing was applied, and answer your questions for the next three months. So name it: which artifact, which version, what you will do with it, whether anything gets redistributed, and how much help you expect to need.
Have the credit conversation while it is still cheap
This is the conversation everyone defers and a good number later regret.
Expectations around authorship, ordering and credit differ sharply between fields, between countries, and between labs down the same corridor. So the common failure is not open disagreement. It is two people assuming different defaults, each confident theirs is obvious, neither mentioning it.
The fix is unglamorous. Write your assumptions down in the first email, marked as assumptions, and invite correction. You do not have to settle anything; naming the categories is most of the value. Who appears on the author list and roughly in what order. Who takes corresponding-author duties. What happens to the data afterwards. What happens if the work turns into two papers rather than one.
Doing it at the start is arithmetic. At first contact neither side has invested anything, so disagreeing costs an email. After eight months of shared work the identical conversation costs a working relationship and sometimes the paper. Stating an assumption plainly is a small skill with a large payoff here.
Anything touching institutional agreements, data-sharing terms or ethics approvals is a question for your research office rather than a matter of writing style.
Say what happens if they decline
Two sentences at the end, doing more than politeness. If this is not a fit, no explanation needed. We will go ahead with the smaller version and cite your method.
The first removes the cost of saying no. People sit on requests because declining feels like it needs a justifying paragraph, and writing that paragraph is more work than not replying — how to say no in writing is the other side of it. Give someone a free exit and you convert silence into information.
The second tells them what they are actually deciding. "We proceed without you" and "the project dies" are very different propositions, and the recipient cannot tell which they are holding unless you say.
The review-request variant
Asking someone to read a draft is a different shape: a pure favour, no credit attached, no shared object at the end. It needs four things the collaboration request does not. The scope — the whole thing, or section 4. The kind of read — is the argument sound, is the method right, is the framing wrong. A cap on effort stated by you rather than discovered by them. And an honest deadline. "An hour, not a line edit, by the 20th if that works, and silence is a fine answer" is a complete request. The engineering equivalent is in asking for a technical design review.
What a briefing does with this
A RelayLink briefing is a fixed set of fields, and this request maps onto them unusually well.
The ask carries a response shape, review and decision among the options, so "yes or no on the collaboration" and "read section 4" stop being differences of tone. Options considered carry a status of chosen, leaning, open or rejected. Decisions carry a confidence level and whether they are reversible. Open questions is a field of its own — exactly where "who is corresponding author" belongs, rather than in a paragraph readers slide past.
Assumptions arrive labelled as stated by the sender or inferred by the sender's AI, which earns its keep precisely where people are vaguest. The credit discussion is also the one you most want on a durable thread — correspondence you can re-read in eighteen months rather than reconstruct from two memories of a corridor conversation.
A recipient with no RelayLink account gets an ordinary email carrying your note, the TL;DR and a link to the full briefing, and can answer by replying to it. Writing to someone who already has an account works differently, and the consent model explains why.
The honest limit
The format carries no attachments — there is no file field in it at all — so where the draft is the artifact, the preprint or the dataset has to live somewhere the reader can reach.
The deeper limit is not fixable by any format. Writing the two lists sometimes reveals that the proposal is one-sided, and a structured briefing makes that visible rather than disguising it. Better to learn it before you send, which is more than the vague version ever tells anyone.
To turn a proposal you have already worked through into something a stranger can answer in one sitting, connect your assistant.