A while back I was finishing a paper with a few coauthors, extending an earlier result of ours to a more general setting. The key step, the thing that made the whole proof work, was, once you saw it, almost embarrassingly simple to state. It reframed a technical problem as something much more standard, and once reframed, the rest followed in a fairly direct way. That kind of idea feels inevitable in retrospect.
Which is exactly the problem. While we were finishing our writeup, another group posted a preprint using a closely related idea to reprove a special case of our earlier work and push it in its own direction. As far as anyone can tell, this happened independently, nobody had seen anybody else’s unpublished work.
Nothing bad came of it, in the end. We reached out, described the overlap honestly in our introduction, and had a genuinely friendly exchange with the other authors, who were gracious and quick to sort out attribution on all sides. In the course of that exchange it also came out that the underlying idea was older than either of our projects, tracing back a decade or more. Priority on the real substance of each paper was never seriously in question.
But it easily could have taken more time and energy to sort out than it did, for reasons that had nothing to do with the mathematics. That part is worth thinking about carefully, and it’s not just a story about finished papers and coauthor logistics. It applies just as much to a single clean lemma sitting in a thesis chapter draft, or a nice observation you’re saving to mention at the next group meeting instead of writing down. The stakes scale with career stage, but the instinct that causes the problem doesn’t.
Simple ideas don’t stay unique for long
Here’s the thing about a genuinely good, simplifying idea: its quality is exactly what makes it findable by someone else. A deep, technically difficult result might be safe to sit on for a long time, because few people are positioned to reconstruct it independently. A clean reformulation that makes a previously hard problem easy, the kind of idea where a competent person in the field could plausibly land on it once they see the right framing, is the opposite. Simplicity is not a reason to relax about timing. If anything it’s a reason to be a little more careful about it.
Mathematics has a long, well-documented history of this, theorems proved twice within months (or weeks or days!) of each other, techniques rediscovered in different subfields before anyone notices the connection. This wasn’t really a story about two groups colliding by coincidence, either. Once we started comparing notes, it turned out the same underlying idea had already surfaced, independently, in more than one earlier piece of work by more than one set of people, over a span of years, in slightly different contexts. That’s not bad luck, it’s what tends to happen when a field has a natural next step sitting in plain sight. If an idea is genuinely useful, it’s reasonable to assume someone else, possibly someone already halfway there from an unrelated project, is not far from finding it too.
The real content of a paper is very rarely the existence of a clever trick; it’s what gets built once the trick is in hand. But that distinction only protects you if it’s written down clearly, and it’s much easier to write down calmly before there’s any question of who was first, rather than after.
What slowness actually costs
To be precise about what the delay cost here, since it’s tempting to either dramatize or shrug it off:
- It didn’t cost us the result. The substance of our paper had no real analogue in the other one. That was never seriously in dispute.
- It cost us a clean narrative. Instead of citing related work in the ordinary way, we had to write a paragraph carefully describing an overlap, accurate, fair, and a little more work than it would have been to just not need it.
- It cost time and attention that had nothing to do with mathematics. A round of emails, some careful cross-checking of references, an extra clause in a cover letter. All manageable, none of it what anyone particularly wanted to be spending time on.
- It introduced avoidable risk. This time it resolved gracefully, because everyone involved acted in good faith and communicated well. It didn’t have to go that way. There were several points where a less careful description, a slower reply, or a referee drawing the wrong conclusion could have made things genuinely unpleasant, for reasons unrelated to the quality of anyone’s work.
None of this is really a story about “losing” a result. It’s about the fact that delay quietly converts a simple, administrative act, post the finished paper, into something that has to be actively and diplomatically managed after the fact, in public, on a timeline you don’t get to choose.
The AI angle
One thing that’s changed since the last time I thought hard about this problem: the gap between “I see the idea clearly in my head” and “there is a complete, correct, well-written draft” is much smaller than it used to be. A good idea used to take weeks or months to turn into a postable paper, writing up lemmas carefully, checking edge cases, producing clean notation, drafting the introduction, formatting references. Used well, AI tools can now compress a lot of that mechanical distance. That doesn’t replace the mathematics, the idea still has to be right, and someone still has to think hard about it, but it does remove a lot of the friction that used to separate “I have the key insight” from “this is ready to share.”
That cuts both ways. It means the tools are available to close the gap between insight and posted draft much faster than before, which is mostly good news if you use it well. But it also means that gap is shrinking for everyone else at the same time. If a simple, findable idea used to have a natural multi-week buffer before anyone else could plausibly turn it into a finished paper, that buffer is getting shorter. The lesson isn’t to panic about it, instead it’s to recognize that the tools that help you move a clean idea to a finished draft quickly are exactly the tools that lower the cost of independent discovery converging in public at nearly the same time. Speed used to be optional. It’s becoming more load-bearing.
What I’d do differently
Post early, revise in public. A preprint isn’t a finished monument; it’s a timestamp attached to a paper. If the core argument is correct and complete, get it up and keep polishing afterward. The version that matters for priority is the one with the timestamp.
Treat “we have a solid draft” as the finish line, not the midpoint. It’s tempting to keep working on a paper, including one more generalization, one more clean remark, one more careful pass, while it stays unshared. Every week it sits is a week someone else gets a free shot at the same idea.
Be upfront, early, about the clock. Collaborators are busy and juggling many things, and a slower pace on any one project is completely understandable and not a reflection on anyone’s effort or care. What I’d do differently is say clearly and early, as a shared observation rather than a complaint: this particular idea feels simple enough that someone else could plausibly find it too, so let’s treat the calendar as part of the mathematics on this one. That’s a fair, collaborative thing to raise, and better raised in week two than in week twelve.
It’s worth being honest that this is an easier sentence to say as the senior person on a project than as the junior one. If you’re a postdoc or student working with a PI who sets the pace, “let’s move faster” can feel like a harder thing to volunteer. A lower-friction version of the same move is to ask, plainly, “is there anything blocking us from posting a draft version now and revising after?,” which raises the same concern without requiring you to be the one who owns the timeline.
Use the tools that shorten the idea-to-draft gap. If a good chunk of the delay between “I understand this” and “this is ready to post” is mechanical, writing up, checking, formatting, that’s exactly the part where modern tools can help the most, freeing up time for the collaborative, genuinely human parts of the process: discussing ideas, checking each other’s reasoning, deciding what the paper should say.
On generosity and speed
It’s worth naming something honestly. Running a project as a genuine collaboration, giving each coauthor real ownership of their part, on their own timeline, rather than just writing the whole thing and asking for a rubber stamp, is, I think, the right way to do joint work, and it’s exactly what made this project enjoyable and worth doing with these particular people. It also has a cost that’s easy to underweight: every added dependency adds latency, and in a fast-moving field, latency is a kind of risk, even when everyone involved is doing careful, good-faith work at a reasonable pace.
There’s a real tension between running a project generously, as true joint work, and running it as fast as possible, and I don’t think there’s a clean resolution to that issue. I don’t think the right takeaway is to collaborate less generously. It’s to be more explicit, early and kindly, that speed itself is sometimes part of what a project needs from everyone involved, and to lean on whatever tools are available, including AI-assisted drafting, to shrink the mechanical part of the timeline, so that generosity toward collaborators and urgency about posting don’t have to trade off against each other as much as they used to.
In the end, this story has a good ending: honest attribution on all sides, a warm resolution, two pieces of work that are more different than alike. Good endings aren’t guaranteed, though, and the version of this that goes badly isn’t hard to imagine. The lesson isn’t “work alone” or “rush your collaborators.” It’s narrower: if you know an idea is simple and powerful, that’s not a comfortable place to let it sit. Post it.