How to Build a Research Writing Team That Actually Helps

Academic writing looks like solitary work — one person at a desk, producing a manuscript others will eventually read. In reality every strong article is a team production, and its quality is decided long before anyone opens a draft: by when people are brought in, what they are asked to do, what they get in return, and whether anyone said out loud who does what.

None of this requires charm or connections. It requires treating academic writing collaboration as something you design, not something you hope for. Here are the four decisions, in order.

Decision 1: The right person, at the right stage, for the right thing

Academic writing is not a solo act followed by a group review. It is a staged collaboration, and the most common mistake is treating it as one or the other.

Most PhD students do one of two things. They work alone until they have a complete draft, then hand it to everyone at once — asking people to review something that may need rebuilding from the ground up. Or they involve collaborators from the very beginning, before there is anything concrete to respond to. That second one is what a colleague of mine called asking a donkey to be a unicorn — expecting people to contribute to something that does not yet exist in a form they can engage with.

The alternative is to bring the right person — and the right part of that person — in at the right moment. That means knowing two things about each collaborator: what they are good at, and what they want from the work (acknowledgement, co-authorship, engagement, a favour returned).

The five stages of collaboration

There are five natural stages where working with co-authors adds value, each needing a different contributor:

1. Research question — a field expert, briefly. A short email or fifteen-minute chat: does this seem interesting to you? You are not asking for commitment or a detailed review, just a quick sanity check from someone who knows the field. Low cost for them, high value for you.
2. Power calculation — a statistician. A technical task with a specific deliverable: can your sample support your question? Bring them in with a clear brief — your research question, your design, your expected effect size if you have one.
3. Argument (skeleton draft) — a clear reader. Someone who can tell you whether the logic holds. This does not have to be a field expert. A fellow student, a writing group, a colleague from a neighbouring discipline. The question is simple: can you follow this? Does it make sense? Content expertise is not required. Clarity of mind is.
4. Content (paragraphs written) — field experts, selectively. Assign each to the sections they know best: one reads the introduction, another the methods, another the discussion. Nobody reviews the whole paper.
5. Final pass — everyone, once. The major decisions are made. This review is for consistency, completeness, and polish. Not rebuilding.

📄 Free: Grab the Collaboration Request Template — a one-page fill-in for Where / What kind of feedback / Depth / Will they see it again? / What NOT to do. It turns "what do you think?" into a request people can actually answer well. Download it here.

I once watched this go wrong for a student I knew. They had a supervisor who knew the field well and was available throughout. But the student wanted to show independence, so they wrote the entire article — research question to conclusion — without involving the supervisor at all, then sent it over for a final check.

The supervisor was not impressed. The argument was structured in a way they would have redirected early; the research question was framed wrong; several content decisions needed rethinking. They sent it back asking for substantial revisions. The student felt their work was not respected; the supervisor felt handed a finished product they were expected to rubber-stamp. Neither felt the collaboration had worked, and the relationship took time to recover.

Staged collaboration is not about involving people less. It is about involving them when their contribution is most useful — and most possible to act on.

Decision 2: Give people a chance to be good

Everyone you ask for help wants to help you. The problem is that a vague request makes it almost impossible for them to do it well.

When you send a draft and ask "what do you think?", you have handed someone a task with no brief. Some skim it and send two lines. Some spend three hours on every sentence — on things that will change anyway. Neither is their fault: the request never told them what good help looked like. A specific request is not a demand; it is an act of respect.

The five-element request

• Where. Which section or paragraphs — not "the paper" but "the introduction, paragraphs two through five." Especially important when different experts get different sections.
• What kind of feedback. Be explicit about the type, because these are different tasks:Asking for all four at once is asking for too much. Asking for one, clearly, gets you something you can use.
  • Analyses: are the statistical choices sound?
  • Flow and logic: can you follow the argument? Does each paragraph lead to the next?
  • Content and citations: is the field represented accurately? Are the right references here?
  • Line editing: is the language clear and precise?
• Depth. A light read for overall impressions is different from a close read with tracked changes. If you are not at the final draft, say so — otherwise someone may invest in line edits you will discard next revision.
• Will they see it again? Someone who knows a revision is coming can flag concerns briefly; someone on their only pass needs to be thorough.
• What NOT to do. Say what is out of scope: Do not comment on the structure — that is fixed for now. Do not worry about the references — I will clean those up later. Boundaries protect everyone's time and prevent frustration when feedback cannot be acted on.

If you are unsure what to ask for, or from whom, ask your supervisor. A clear referral — "ask Åshild specifically about the diagnostic framework in paragraph three" — beats a general "run it by the team."

I have a colleague who understands this better than anyone I know. He is extraordinarily good at delegating: every task he gives feels designed for the person receiving it — specific enough to be achievable, important enough to feel meaningful. Because he does this consistently, his papers attract careful, enthusiastic co-authorship. People enjoy working with him; they feel they contributed something real. The opposite is just as reliable: give collaborators no clear task and they hedge, turn cautious, and come to see you as a burden. You stop getting their best work — not because they do not want to give it, but because they were never given a way to.

Give people a chance to be good. Be specific about what you need. (The same discipline helps when you are on the receiving end of vague notes — closer to responding to reviewers, a topic for another post.)

Decision 3: Make the exchange explicit

Before you ask someone for help, spend a moment on why they would say yes. This is not cynical — it is practical. People collaborate for different reasons: co-authorship and the publication it brings, reciprocity (they help you now, expecting help later), or the genuine pleasure of feeling useful. Knowing which one is driving someone shapes how you frame the ask.

Then be explicit about what they will get. The most common currency is co-authorship. If someone's contribution warrants it — and most journals require a meaningful intellectual contribution — offer it clearly and early. If it does not, say so, and name what you will offer instead: an acknowledgement, a return favour, a recommendation, or simply gratitude for a bounded task. The goal is that neither of you carries a different assumption into the work.

Where the contribution is significant and ongoing, put something in writing — not a contract, just an email confirming what each person contributes and receives. Such agreements feel unnecessary until the moment they are needed. And do not assume a small task is a burden: a statistician who checks your power calculation in twenty minutes and tells you it is solid has had a small, satisfying interaction. That is not nothing.

The failure mode: the four-hour questionnaire

The failure mode is the unspoken assumption. Someone asks "can you help with this?" The colleague says yes, assuming co-authorship. The requester assumes it is a favour with no credit. Neither says it out loud. The paper comes out, the colleague's name is in the acknowledgements, and they feel taken advantage of.

I experienced the other side of this once. A colleague asked me to write the code for a questionnaire they were building, framing it as a quick task — and genuinely believing that, because they did not know what it involved. It turned out to be a hundred items long, each with its own response scale, a mix of numeric and string variables, branching logic. It took me four hours.

That is not unreasonable work. But there was no discussion of what I would get, no reciprocity, no acknowledgement of the scope once they saw it. The next time they asked me for something, I said I did not have time. I did. I just did not want to repeat the experience.

That erosion is quiet and hard to repair. It comes not from bad intentions but from an unclear exchange at the start. Make it explicit, and the collaboration has a foundation. Leave it implicit, and you are building on assumptions that may not match.

Decision 4: Share the plan and hold it loosely

Of all the places research collaboration goes wrong, role clarity fails most quietly — not through conflict but through assumption. Everyone assumes everyone else knows what they are doing and when. Nobody says anything. Work gets duplicated, or falls through the gap between two people who each thought the other was handling it.

Being explicit about who does what, when, and to what standard can feel awkward — too corporate, too formal. In practice, most people respond positively. When you arrive with a clear plan you are not imposing; you are leading. Hand a collaborator a thoughtful plan and ask "does this seem reasonable to you?", and most say yes, relieved someone took charge.

The plan need not be elaborate. It names who is responsible for which tasks, at which stage, and by when. If you follow the five stages above — field expert for the research question, statistician for the power calculation, writing group for the argument, experts by section for content — that structure already tells you how to divide the work. Write it down. Share it.

The thing to avoid is rigidity. A work plan is a guide, not a contract. Studies change; availability changes. When it needs to change, replan — openly and without drama. What damages collaboration is not changing the plan, but treating the original agreement as something to hold over people rather than update together.

The twelve hours nobody needed to spend

I learned the cost of unclear roles directly once. A colleague and I were writing an article together. We divided tasks at the start, but loosely — with no explicit assignment of who would handle the statistical analyses. We were both competent with the methods; we each assumed the other might not get to it; we both started on it independently.

When we compared notes, we had each spent six hours running the same analyses. Twelve hours of combined work, for one task that needed doing once. It was not a disaster — the analyses were done, and done well — but twelve hours came entirely from a conversation we did not have at the start. Five minutes of role clarity would have saved half a working day.

Name who does what. Write it down. Share it early. And when the plan needs to change, change it together.

The pattern across all four

A writing team is not a list of names on a byline. It is a set of agreements: who is brought in at which stage, what each person is asked to do, what they receive for it, and who owns which task. The pattern across all four decisions is the same: vagueness is the enemy. The vague invitation, the vague request, the vague exchange, the vague division of labour — each feels polite in the moment, and each quietly costs trust, time, or both. Specificity is not bureaucracy. It is how you give people a chance to be good.

Your team's first real assignment comes immediately: before any data is collected, someone has to answer whether the study can even answer its own question. That is the power calculation — a good subject for another day.

📄 Free: The Collaboration Request Template turns the five-element request into a one-page fill-in you can paste straight into an email: Where / What kind of feedback / Depth / Will they see it again? / What NOT to do. Download it here and use it on your next draft.

Your turn: what's your worst "we both did the same task" collaboration story — the twelve-hours-of-duplicated-work moment a five-minute conversation would have prevented? Hit reply and tell me. I read every reply.