handbook / Team

Group Meetings

Why we meet

It’s important to meet regularly, both one-on-one and as a full group. We’re all biased by our own way of looking at a problem, and that way isn’t always the right or the most efficient one. Talking to someone else, especially someone outside your immediate project, is one of the fastest ways to catch that.

We run three kinds of meetings every week. All of them are conducted in a semi-formal to formal register.

Group calendar

Meeting dates and times are kept on a shared calendar, embedded below. If you don’t see it, or need edit access, ask in the group channel.

(to set this up: create a group calendar in Google Calendar, open its Settings, turn on “Make available to public,” then copy the calendar ID from “Integrate calendar” and paste it into the src= above in place of REPLACE_WITH_CALENDAR_ID. Set the timezone the same way, e.g. Europe%2FBerlin. If you’d rather not depend on Google, an alternative is to keep an .ics file in this repo that people can subscribe to directly, and optionally render with a small JS calendar widget.)

1:1 meetings

A weekly slot between you and me. Use it to discuss the next step of your project, pitch an idea, troubleshoot something that’s stuck, or talk through anything career-related.

Come with a short list of what you want to cover; it makes the 30 minutes go a lot further. A one-line agenda (“update on X, stuck on Y, want to discuss Z”) sent beforehand is enough.

Subgroup meetings

These are for people working on the same or closely related project areas to sync directly with each other, without waiting for the full group meeting. If two or three of you are using the same method, the same dataset, or are otherwise close enough that one person’s dead end could save the others time, meet regularly.

A few practical notes:

• Frequency and format are up to the subgroup. Weekly or biweekly, 20–30 minutes, whatever matches how fast the work is moving. Set your own cadence and revisit it if it stops being useful.
• The point is a shared idea, not individual status updates. Use the time to compare notes on a common problem, catch duplicated effort early, or work through something none of you could solve alone. If everyone is just taking turns reporting what they did this week, it’s probably better handled asynchronously.
• I don’t need to be in every subgroup meeting, but I’m happy to join occasionally, or you can loop me in afterward with a short summary if something worth flagging comes up.
• If a subgroup meeting surfaces something that affects the wider group (a shared tool, a common bug, a method worth others knowing about), bring it to the next group meeting.

(add specifics once subgroups are established: who’s in which one, and their regular time slot)

Group meeting

This is when the whole group meets together. The general format is:

• A short presentation on a research article the presenter found interesting (their own find, or something shared by someone else).
• A presentation on research progress from the same person.
• Depending on group size, occasional shorter presentations, e.g. from dissertation students.

The date is announced on the group calendar and shared in the group channel.

Code of conduct

Presenter. Use this time to discuss your project and get feedback from the group and from me. The group may come from fairly different backgrounds, so be ready for feedback delivered at different levels of formality and criticism, and in different scientific “dialects.” Aim to present your ideas in 30 minutes or less — it’s a real skill to say something in as little time as possible, and it’s worth practicing. It’s completely fine if you don’t have enough results to fill the slot, especially if your last turn wasn’t long ago; in that case we’ll just spend more time discussing rather than presenting. Total meeting time won’t exceed 1 hour.

Attendees. Everyone is strongly encouraged to participate. There’s a reason for the old saying that there are no stupid questions, only stupid answers — ask freely. At the same time, respect the presenter’s dignity when raising criticism, suggestions, or disagreements. The goal of every exchange is to improve the research and help each other, and the way we interact should reflect that.

A few practical resources

• Ten Simple Rules for Productive Lab Meetings (PLOS Comput. Biol., 2021) — a good short read on structuring group meetings so they stay inclusive and useful, not just a status report.
• Twenty-two easy ways to power up your lab meetings (Nature) — a collection of small format tweaks (round-robins, rotating roles, etc.) other groups use to keep meetings from going stale.
• The Situation–Behavior–Impact (SBI) feedback model — a simple structure for giving feedback that stays specific and factual rather than personal: say what happened, what was actually said or done, and what effect it had. Useful for anyone giving comments in group meetings, not just for the PI.

(add any group-specific resources here, e.g. a shared slide template, a rotating-presenter schedule, or a link to the shared calendar/channel)