Skip to content

How We Collaborate

The Core Principle

If nobody can see your work, nobody can help you.

Research can feel solitary, but isolation is where projects drift, assumptions go unchallenged, and people get stuck longer than they need to. We make our work visible — not because we want oversight, but because visibility is how we support each other.

This means: share work in progress, not just finished work. Open draft PRs early. Post updates before they're polished. Mention what you're stuck on, not just what you've solved.

The unfairness of late feedback

Asking for feedback on something finished that someone is seeing for the first time is unfair — to both sides. The reviewer can't meaningfully shape the work, and the author is unlikely to act on deep feedback at that stage. Share earlier, when feedback can still change the direction. This is better for everyone.

Pods

Everyone belongs to a rotating pod of 3. Pods rotate every quarter.

Purpose

Pods exist to:

  • create visibility across the group
  • reduce isolation
  • provide early feedback
  • review each other's work (including code review)
  • notice when something is drifting or staying vague for too long
  • create a small, regular space for collaborative work

Why pods of three?

With pairs, too much depends on one relationship working well. If the chemistry is poor, or one person is much more active than the other, the structure becomes fragile. A pod of three gives more stability: it is easier to keep momentum if one person is busy, quieter people have more than one point of contact, and there is more opportunity to see different approaches and workflows.

A pod of three also makes it easier to combine different roles: one person may work directly on a task, another may question assumptions, and a third may bring a different perspective or connect things to another project.

Weekly pod responsibility

Pods do not get their own extra weekly meeting. The weekly responsibility can be handled around the existing group rhythm — for example through a short conversation directly after a standup, or by reacting to each other's async updates.

The expectation is that pod members:

  • keep an eye on each other's progress
  • notice and call out when someone seems stuck, overloaded, or diverging from communicated project goals (for this, pod members should read the project briefs of their pod members)
  • point out if something should become a project, brief, or review item
  • give lightweight feedback on PRs or work in progress when relevant

Monthly pod session

Each pod has one longer session per month, normally around 2–4 hours, with two parts:

1. Project review (60 min)

Each month, the pod chooses one project from a pod member to review more seriously. The owner circulates the brief, or a short incubate note, beforehand.

The pod should discuss:

  • What is the question?
  • What is the current bottleneck?
  • What should happen in the next month?
  • What evidence would make us pivot, narrow, or stop?
  • What should be brought to Group Day?

2. Collaborative work block (at least 120 min)

The second part is interactive collaborative work. The goal is to put your brains together on a concrete problem in a way that makes different ways of thinking and working visible.

This does not mean all three people must literally code on the same thing at once. Choose the format that creates the most useful interaction: two people working on a task while the third questions assumptions, or all three debugging, designing, writing, or reviewing together.

This is not meant to become silent parallel work. It should be a setting where you can see different approaches, workflows, and habits, and where it feels easier to ask small or half-formed questions that you might not ask otherwise.

Pod output

At the end of each monthly session, the pod writes down:

  • one concrete next step for the reviewed project
  • one question, concern, or insight for Group Day (if relevant)
  • any accountability item (e.g., a brief that still needs to be written, a review that should happen)

Mentoring

New group members, less experienced members, and anyone who wants more structured support should have a named mentor.

PostDocs and final-year PhDs serve as mentors. Their role is to help with prioritization, communication, turning fuzzy work into clearer project plans, and noticing early if someone is drifting or overloaded. Mentoring is not technical support — mentors do not need to be deep in the technical details. Learning to mentor without knowing all the details is itself a valuable skill.

Kevin will discuss mentoring assignments with postdocs and final-year PhDs in one-on-ones.