Collaborating Across Institutions and Time Zones

Distributed collaborations rarely fail because the research was wrong. They fail because nobody was sure who was doing what, a draft sat with someone for two months, and the project quietly stopped being anyone's priority.

These are coordination problems, and they are solvable with a small amount of structure agreed at the start. For distributed research groups, employee monitoring software is one category that makes questions of transparency, consent and expectations especially concrete.

What to settle before starting

An hour, once, and it prevents most of what follows.

Who does what, specifically enough that each person could describe their part.

Authorship and order, by whichever convention applies, agreed explicitly. See authorship.

Who drives. Every project needs one person whose job is that it moves — chasing, scheduling, deciding when something is finished. Without a named driver, distributed projects stall by default.

How often you meet, and who arranges it.

Where things live. One shared location, one current version.

What the timeline is, with dates that mean something.

What happens if someone's circumstances change — a new job, a leave, a change of priorities. This happens on most multi-year projects and it is much easier to discuss in the abstract.

Write it down and send it round. A short email after the first call. Not bureaucracy — the reason anything remembered by several people gets written down.

The practices that keep it moving

A regular short call beats an occasional long one. Thirty minutes fortnightly maintains momentum; a two-hour call every quarter is a project restart each time.

Same time, standing, in the calendar. Rescheduling each occurrence is how the cadence dies.

Rotate the awkward hour. If one participant always takes the call at 6am, that participant will gradually disengage, and it will look like a lack of interest.

Short written updates between calls. Two lines each: what I did, what I am stuck on. This is where most of the value is, because it surfaces blockers before the next call.

End every meeting with who does what by when. Written, in the notes, with names. A meeting that ends in general agreement produces nothing.

Set a deadline for feedback on drafts. "Comments by the 14th" gets comments; "let me know what you think" produces silence for six weeks.

Working across time zones

Find the real overlap and protect it. In a spread-out collaboration there may be one hour, and it should not be spent on things that could be written.

Use the calls for what needs discussion — decisions, disagreements, unblocking. Not for status, which belongs in writing.

Write more than feels necessary. In an asynchronous project, anything not written does not exist for half the team.

Be explicit about response expectations. "I will reply within two working days" prevents both anxiety and the assumption that silence means agreement.

And be careful with silence. In a distributed group, someone who has gone quiet may be blocked, overloaded or disengaged, and there is no corridor in which to notice.

Files and versions

Small problem, large amount of wasted time.

One current version, one location. Whatever tool — the discipline matters more than the choice.

A naming convention, agreed once.

Version control for code, always, in fields where that applies.

Say who is editing what to avoid two people revising the same section in parallel.

Keep the decision log. Why the sample was constructed this way, why the measure changed. In a collaboration this is more important than in solo work, because the reasoning lives in several heads and none of them is complete. See a research record that survives you leaving.

When it stalls

Most collaborations stall at least once. What matters is noticing.

Name it directly. "This has been quiet for two months — is it still something we want to do?" is a kind question, not an accusation, and it usually produces an honest answer.

Distinguish the causes. Someone overloaded, someone whose priorities changed, a technical blocker nobody mentioned, or a project that has quietly stopped being interesting. These need different responses.

Reduce scope rather than abandoning. A smaller paper that appears beats a larger one that does not.

Give people a route out. Someone who no longer wants to be involved should be able to say so without it being a failure. A collaborator who is not contributing and cannot say so is worse for everyone than one who withdraws cleanly, and the authorship question should be settled honestly when it happens.

Power differences within a collaboration

They exist even between colleagues — seniority, institutional resources, who holds the funding, who is on a permanent contract.

The person with less power will not chase. If a senior collaborator sits on a draft for three months, a junior one frequently cannot say so.

So the senior person sets the norm: respond on time, say when you cannot, and make it explicitly acceptable to be chased.

And check who is doing the coordination work. It is real work, it is invisible, and it tends to accumulate on the most junior person or on whoever is least able to decline.

The short version

Settle roles, authorship, driver, cadence and location at the start, and write it down.

Regular short calls beat occasional long ones, and every meeting ends with who does what by when.

Rotate the awkward hour, or you will lose that person gradually.

Name a driver. Without one, distributed projects stall by default.

And when it goes quiet, ask directly — it is a kind question and it usually gets an honest answer.

For an independent authoritative reference, consult the Open Science Framework for infrastructure for transparent research practice.