Collaboration Tools Every Researcher Should Know (and How to Actually Use Them)

1. Pick a Stack Before You Pick Tools

The reason most lab tooling discussions go nowhere is that people argue

about Notion vs Obsidian or Zotero vs Mendeley as if the choice mattered

in isolation. It does not. What matters is whether the five layers of

research work — writing, code, data, communication, and references — have

one canonical tool each, and whether those tools survive the next student

rotation. A great tool nobody else in the lab uses is worse than a

mediocre one everyone defaults to.

Decide the stack first, then the specific tools. Write it down. Two

sentences per layer is enough: "We write papers in Overleaf, code lives

on the lab GitHub org, datasets sit on the shared S3 bucket, async

communication in Slack, references in Zotero with the lab group library."

That paragraph is the single most useful artifact a research group can

produce. Without it, every new student rebuilds the stack from scratch.

2. Writing: Overleaf for Submissions, Docs for Drafts

The split most productive labs land on: Google Docs (or Notion) for

early drafts, outlines, and brainstorms — Overleaf or local LaTeX +

GitHub for anything heading to a venue. The reason is that early-stage

writing is paragraph rewriting, comment threads, and reorganization,

which Google Docs does better than any LaTeX tool. Late-stage writing

is equations, references, and figure placement, which only LaTeX does

properly. Trying to do both in one tool means losing one of them.

If you are using Overleaf, pay for the institutional or Pro plan that

gives you Git integration. The free plan caps collaborators and makes

version history painful. Set up a convention for tracked changes:

either "use Overleaf's review mode" or "wrap revisions in

\\todo{} and \\edit{}" macros — pick one and stick with it. Mixed

conventions inside one document cost more time than the writing itself.

3. Code: GitHub Is the Default, but Discipline Is the Point

Use GitHub (or your institution's GitLab) and stop debating. The choice

of platform matters less than three discipline issues that 90% of

research repos fail at: meaningful commits, a working README, and one

command that reproduces the main result. If your repo cannot be cloned

and run by a new student in under 30 minutes, it is not collaboration —

it is a backup of your laptop.

Two practices to standardize across the lab. First, a top-level

reproduce.sh (or Makefile target) that runs the pipeline from raw data

to main figure. Second, a CONTRIBUTING.md that says "before pushing,

run X" and is honestly only 10 lines. The point is not best-practice

theater; it is the next student inheriting the project. The single

best test of a research repo is whether someone who joined the lab last

week can reproduce Figure 3 without messaging you.

4. Data: Stop Emailing CSVs

The single most common collaboration failure is data on someone's

laptop. The fix is one shared storage location and a naming convention.

It does not matter whether you use S3, Google Cloud Storage, an

institutional NAS, or Dropbox — pick one and make it the only place

raw and processed data lives. If your lab has compute clusters, the

storage layer is usually decided for you; just write down the path

conventions.

For datasets that change over time, DVC (Data Version Control) is

worth the setup cost. It works alongside git and lets you version

datasets the same way you version code, with the actual bytes living

in your shared bucket. The alternative is filename suffixes like

data_v2_final_FINAL.csv, which is how labs lose six months of analysis.

DVC has a learning curve of a few hours; the payoff is months of saved

"wait, which version of the data did I use" investigations.

5. Communication: Slack Is Fine, but Async Is the Skill

Most labs settle on Slack (or Discord for the cost-conscious; Mattermost

for the self-hosted-conscious). The platform matters far less than

whether the group has rules about what goes where. Without rules, the

DM volume explodes, public channels become noisy, decisions get lost,

and new members cannot find context. The fix is a one-page channel

guide: which channel is for what, and what does not belong in DMs.

The async skill is more important than the tool. A well-written

asynchronous message — context, the specific question, what you have

already tried, what response you need — gets a useful answer in hours.

A vague "got a sec?" DM costs the recipient a meeting. Teach this

pattern early to new lab members; it compounds. The same applies to

decisions: write them down in a channel, not a DM, so the next student

can search for them in a year.

6. References: Zotero Group Libraries Are Underrated

Pick one reference manager for the whole lab. Zotero is the safest

default in 2026: free, open-source, with group libraries that let

everyone share one bib file, and a browser connector that captures

papers in one click. Mendeley still works but Elsevier's ownership

makes long-term trust uncertain. Paperpile is excellent if your lab

lives in Google Docs but locks you in.

The trick that most labs miss: maintain a single lab group library

organized by project, and export the .bib file directly into your

paper repo with a script. That way, every paper draws from one

canonical reference list, citations stay consistent across drafts, and

a new student inherits five years of curated bibliography on day one.

Without this, every paper rebuilds its bibliography from scratch and

the same paper gets cited with three different formatting variations

across the lab.

7. Meetings and Notes: The Layer Most Labs Forget

Meetings without notes are work that did not happen. Pick a meeting

notes home — Notion, a shared Google Drive folder, a wiki, or even

one markdown file per meeting in the lab repo — and make it the

default. The format matters less than the habit. Three sections is

usually enough: agenda (sent the day before), decisions (written

during), action items (with owner and date).

Two specific patterns to copy. First, individual one-on-one notes:

each student keeps a single rolling doc with their advisor, organized

by date, that both can edit before meetings. This eliminates the "wait,

what did we agree last time?" loop. Second, a "decisions log" channel

or page where the lab records non-obvious choices ("we standardized on

PyTorch over JAX in March 2026 because…"). Future students will thank

you when they inherit a codebase and want to know why.