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

Pods help us hold one another accountable, think through difficult situations, and improve projects. They normally have three members and rotate every quarter. People without sustained ownership of a research project may remain outside a cycle or opt in when useful.

Weekly accountability

Use existing standups and Group OS updates. Do not automatically add another meeting.

  1. Commit — Name one concrete outcome and what would count as done.
  2. Notice — Read podmates' updates. Notice blockers, repeated deferrals, overload, or drift.
  3. Close the loop — Say what happened and point to the result. A miss is information, not blame.
  4. Decide — Recommit, renegotiate, or escalate rather than letting work drift.

Pods can also give early feedback, review code, and help turn vague work into a clear project, brief, or review item.

Peer coaching

Use peer coaching when something repeatedly slips, remains unclear, produces a surprising result, or rests on an uncertain assumption. The case does not need to begin as a polished question.

One person is the case owner. The other two are consulting peers; one keeps time. Follow the speaking boundaries so that the pod understands before it advises and the owner retains the decision.

  1. Case presentation · 10 min · case owner only — Situation, people involved, the owner's position, attempted solutions, and the core difficulty.

  2. Interview · 10 min · everyone — Ask only for missing facts, information, relationships, and interdependencies.

  3. Hypotheses · 10 min · consulting peers only — Offer tentative causes, influences, feelings, and observations—not diagnoses. The case owner listens without responding and may turn their chair around. Alternatively, they may step out while peers develop their hypotheses, then return to hear them before resonance.

  4. Resonance · 5 min · case owner only — Say what was comprehensible and which hypotheses shed new light.

  5. Possible solutions · 20 min · consulting peers only — Generate options, consequences, alternatives, and incompatibilities.

  6. Action planning · 5 min · case owner only — Choose a feasible action, the evidence it should produce, and a review date.

Record only the agreed action, evidence, review date, and requested escalation. Pod conversations are confidential by default and are not performance evidence.

This sequence is informed by structured case-consultation methods. For a practical example of the same progression from clarification through hypotheses to action, see Peer group consulting.

Monthly project session

Reserve two hours and rotate the project owner so that every member has one project reviewed during the quarterly cycle. The owner shares the project page and a short review note at least 24 hours beforehand.

  • First hour — review: purpose, changed evidence, bottleneck, strongest rival explanation or failure mode, uncertain consequential assumption, direction, next milestone, and escalation.
  • Second hour — work together: inspect data, stress-test an analysis, map rival explanations, design an experiment, or unblock an artifact. End with an artifact or decision rather than silent parallel work.

Record the review verdict, next milestone with owner and date, key risk or assumption, and anything that should go to Group Day or Kevin.

Check the system

At every Group Day, check whether pods are:

  • closing weekly commitments;
  • completing one substantial project review per member;
  • producing useful decisions, artifacts, or changes in direction; and
  • escalating blockers that cannot be resolved inside the pod.

Use that evidence to resolve problems during the cycle. At the end of each quarterly cycle, review the format itself and adjust the next cycle. The aim is a useful learning system, not compliance with a ritual.

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.