Chapter 9. Collaboration vs Competition
When the science in that collaboration was good, but the communication was completely absent.
Note: Most of my posts are free for everyone. However, “Mochi doesn’t care about your h-index” is currently behind the paywall for paid subscribers. If you’re not subscribed yet you can try the paid subscription anytime to fully immerse in this and future deep-dive chapters.
Still, there’s still plenty of useful content visible even without a subscription, so I’d encourage you to read through what you can. You might find a few ideas you can use right away.
Two researchers I know well spent nearly a year building something genuinely exciting together. They had complementary methods, overlapping questions, and enough mutual respect at the start to commit to a joint paper. That’s exciting, right ?
However, well, there will always be a however, there were a few things left unspoken. Things like:
Who would be corresponding author was left unspoken because raising it felt premature.
Who would make the final call on disputed analytical decisions was never agreed because they assumed consensus would emerge naturally.
Who owned the code repository,
How frequently they would meet,
What pace of progress was acceptable (& obviously what not),
What would happen if one person’s other commitments slowed things down…
None of it was discussed at the beginning (and well, that’s a bad thing eh?).
Several months later, what had started as genuine intellectual partnership had quietly curdled into a territorial standoff. Both of them knew it, but neither of them said anything until a draft was already on the table and the resentments had calcified. After a while, the paper eventually got published. And you know what, both of them privately told me they would never work together again.
The science in that collaboration was good. But the communication was completely absent.
The training we actually received
Scientific culture does not train researchers for collaboration. It trains them for competition, and it does so consistently. From the first course where grades were distributed on a curve, through the PhD years where the unspoken norm is that your peers are simultaneously your intellectual community and your rivals for a shrinking number of positions, into the career stage where two labs working on the same question creates an anxiety that is never openly acknowledged but shapes nearly every decision about when to present, when to publish, and how much to share at conferences.
It is a rational adaptation to a real selection pressure. The system rewards individuals, allocates credit to individuals, and ranks individuals against each other. Collaboration, in that environment, requires a kind of trust that the training system never builds and the incentive structure actively undermines.
And yet, the work itself increasingly demands it. Computational biology, the field I spend most of my time in, barely exists as a solo enterprise anymore. The questions worth asking require wet lab expertise, statistical expertise, domain knowledge across multiple systems, and access to datasets that no single group can generate alone. The frontier of science has moved to territory that requires teams, and the teams are composed of people who were trained, individually, to be suspicious of each other (LOL)
Someone who replied to a post I wrote on Facebook about research life said it plainly. Communication, collaboration, listening, and conflict resolution are sometimes as important as technical ability in the modern research environment. The image of the scientist solving problems alone is not just inaccurate, they wrote. It is actively harmful to people who enter research expecting that doing the technical work well will be sufficient. Technical ability usually gets you into the room, but communications between people carry you farther in life, I think.
Subs cho Tứng nhé :). Và hãy cân nhắc donate tiền cà phê để Tứng gửi đến bạn những bài viết chất lượng hơn nha <3
Where collaborations actually break down
Most failed collaborations do not collapse in one day or two. They dissolve quietly, through accumulated avoidance. I personally think that the avoidance is almost always about one of these three things:
The first is authorship. The norms are supposed to govern this. Most fields have some version of contribution-based authorship standards, and most researchers are aware of them in the abstract. What almost never happens is an explicit early conversation where everyone involved says, plainly, what they expect their position on the author list to be and what level of contribution they understand that to require. Instead, the assumption is that this will work itself out, and then it does not, and by the time the draft exists the stakes are too high for anyone to raise the issue without it feeling like an accusation.
Having the authorship conversation early is not a crazy thing, trust me. It is the minimum professional courtesy a collaborator owes to someone they are asking to invest significant time in a joint project. The conversation does not need to be long, but it needs to be explicit. You simply name what each person will contribute, what the expected author order is, and under what circumstances that order might change. Doing this in the first month of a collaboration takes 30 minutes tops, no more. Please don’t wait.
The second thing that dissolves collaborations is unspoken working-style differences. Some researchers work in concentrated bursts and then go quiet for weeks. Others need regular contact to feel the project is alive. Some people want every decision discussed in a meeting before any work proceeds. Others find meetings a distraction and prefer to discuss decisions after someone has already tried something. None of these styles is wrong, but any combination of mismatched styles, left unnamed, produces a situation where one person feels abandoned and the other feels micromanaged, and both experiences feel personally attacked.
The fix sounds embarrassingly basic but almost never happens. At the start of a collaboration, ask how your counterpart likes to work. How often they want to check in. How they prefer to receive feedback. What their expectations are around response times. Whether they want to be consulted on decisions or informed after the fact. Then say the same things about yourself. Simple eh ?
The third breakdown is contribution concerns that become character conflicts. One person feels that the other is not pulling their weight. The concern about contribution becomes a theory about the other person’s character. The conversation that could have been about the work becomes, in the person’s head, a confrontation about integrity. And so it is never raised. The project continues. The resentment grows. Eventually something breaks, and it usually happens at the worst possible moment.
Looking back on my own early career, one of the things I regret most is not having access to genuine community. Not a professional network or an institutional affiliation, but the practical kind, where you can say you are stuck in an analysis and someone who has been stuck in exactly that place will recognise the problem, where you hear about a funding opportunity from someone who found it three days before the deadline, where someone with more experience will read your abstract and tell you what is actually wrong with it. That kind of community requires people who have benefited from it to build it deliberately for the people behind them.
Meetings that end with decisions
Every meeting in a collaborative project needs an owner/a host and a decision list. The owner is responsible for circulating a short agenda beforehand that distinguishes between items where a decision is needed and items that are informational. During the meeting, every decision item needs to end with
a person,
an action, and
a deadline date.
You know, not
“We should run the additional analysis.”
But
“XYZ will run the ABC analysis and share the output with the team before Thursday 6 July 2026”
A final two minutes at the end where the owner reads back the decisions and action items so everyone leaves with the same understanding of what was agreed. I think it is the minimum structure required to convert a conversation into a project.
How to give honest feedback without damaging the relationship
The persistent myth in scientific culture is that rigour and collegiality are in tension. That giving someone genuinely honest feedback on their methods requires either softening it until it loses its use or delivering it with a bluntness that puts the relationship at risk. Neither is true, but the myth produces a behaviour pattern where feedback between peers is either too gentle to be useful or delivered with a sharpness that reads as aggression rather than honesty.
Okay, that’s the free part done. Yes, I know stopping here is a little brutal 💀 But the most useful bits are behind this wall. If you’re curious enough to keep going, you know what to do. Currently, only paid subscribers get access to the full eBook
Thanks for reading, and whether you join or not, I hope what’s here is still useful.
