Remote Collaboration
Managing Research Software Projects
Greg Wilson
2026
Learning Objectives
- Identify the specific failure modes of distributed research software
teams.
- Explain what async-first management means in practice.
Failure Modes of Distributed Teams
- Review latency: PRs waiting over two days discourage
contribution.
- Synchronous-first culture excludes anyone who cannot attend the
meeting.
- Invisible contribution: review and triage leave less trace than
code.
- Trust has to be built deliberately without incidental contact.
- Data-access constraints: code may travel but data may not.
- Seasonal absences from teaching, fieldwork, and conferences
vary.
Async-First in Practice
- Async-first does not mean no meetings.
- Meetings are for things that genuinely need real-time
discussion.
- Decisions are written down before they are acted on.
- Code review responses are expected within two days.
- Status updates are written, not spoken.
- Questions asked in writing get answers in the same thread.
Mixed-Mode Meetings
- Virtual meetings broaden participation across geography and career
stage.
- But in mixed-mode meetings, people in the room dominate by
default.
- If you cannot have everyone in person, have everyone remote.
- All-remote meetings are usually shorter.
- And fairer, if the moderator does their job properly.
What about AI?
-
LLM meeting summarizers can produce accurate action-item lists
-
LLM summaries flatten nuance and lose hedging language
-
Relying on LLM summaries loses the social texture that reveals struggle
Communication Audit (10 min)
- What is the longest a pull request or issue comment has gone without
a response in the last three months? What time zone was the contributor
in?
- When are your regular meetings scheduled? Which contributors can’t
attend at that time without rearranging their workday?
- Where are decisions made? Are they accessible to contributors who
weren’t in the meeting?
- Which contributors haven’t engaged in the last month? What do you
know about why?
Design a Communication Structure (10 min)
Design a communication structure for a team with contributors in at
least three time zones. (Use your own project, or use Jess’s team:
Toronto, Rabat, Warsaw, and Seoul). Specify:
- How often synchronous meetings happen and when (rotate or
fixed?).
- How decisions are made for things that can’t wait for a
meeting.
- What the expected response time is for code reviews and issues.
- How contributors who miss a meeting find out what was decided.
Compare your structure with a partner’s. Identify one thing they
included that you missed.