Meetings are an important part of how we work together, and this page describes our approach to ensure we have few but effective meetings.
Scheduling meetings in Google
To schedule Zoom meetings from within Google Calendar:
- Ensure that you have Zoom installed as an add-on to your Google account. Open
Google Calendar, click the settings cog in the top right corner, and then
select the “Get add-ons” option.
- Search for the Zoom add-on and click the envelope and calendar combo icon to
install. Now you’re ready to schedule your first Zoom meeting.
- Open Google Calendar, tap the “+ Create” icon then Event.
- Enter the meeting details, set time and time zone (if needed), and add
invitees, or location
- Add links to the agenda or documents relevant to the meeting.
- Tap Add conferencing and select Zoom Meeting (you may be prompted to sign
into Zoom). Google Calendar will add a Zoom Meeting to your meeting details.
- Tap Save.
Internal meeting scheduling
- Use the Google Calendar to
find a meeting time
feature to coordinate meetings with Synura team members. Enter the
@synura.com emails for each participant into the “Meet with…” box in Google
Calendar and the calendar availability for each participant will appear in
your view. Then, when you select a meeting time, those participants will
automatically be invited and a video conference will be attached to the
- Prefer this strategy over negotiating meeting times via chat – This can save
a lot of communication overhead, especially when scheduling with multiple
- It is important to
set your working hours
in Google Calendar and block out any personal time/events/PTO so that team
members do not inadvertently schedule a time when you are not available. Many
team members use the free tier of reclaim.ai to
synchronize personal event times (without event details) into their work
calendars. It is also common practice to block out time for focused work.
External meeting scheduling
When scheduling external meetings, provide external participants with a
Calendly link to schedule with the relevant internal
participants. If you need a Calendly account, reach out in #help via Slack.
- Meetings must be scheduled using
Google Calendar and should have a zoom link
- All meetings must have an agenda in a shared Google Doc that’s linked in
the Description. Items for discussion must be listed in the agenda prior to
the start of the meeting. If client-facing meeting, set time zone to local
time to prevent meeting shifts due to daylight savings. If internal meeting
with multiple team members, then use the time zone for the organizer of the
meeting unless needed otherwise.
- Meeting requests will remain ON HOLD if the above format is not completed
(Example: missing documentation, agenda, etc)
- When a meeting has no agenda for a few weeks, it should be reviewed and a
decision should be made on whether to cancel or restructure it.
- Meetings start right on time, and must be
This means they end 5 minutes prior to a 30-minute slot or 10 minutes prior
to an hour slot
- All teammates should have the meeting notes open during the meeting and add
questions or comments in the doc in real-time. Done well, this is much more
effective than using Zoom chats.
- The bi-weekly team meeting is a ritual that focuses on community-building
rather than efficiency and operates under a different approach to setting and
All non-1:1 meetings are optional
Because we record and take notes in every meeting, and are generally an
async company, all meetings are
optional. If you find yourself scheduling a meeting that everyone declined, take
it as a sign that the work can be done asynchronously. Consider recording
yourself presenting the topic and then share it with the attendees. They can
record videos back or just reply in Slack/issue/MR/etc.
- Always record meetings so they can be re-watched later, or viewed by anyone
who wasn’t there.
- At Synura, meetings start whether you’re there or not. Nevertheless, being
even a few minutes late can make a big difference and slow your meeting
When in doubt, show up a couple of minutes early. If you were late, the
meeting will have been recorded.
- It’s okay to spend the first minute or two of a meeting being present and
making small talk if you want. Being all-remote, it’s easy to miss out on
hallway chatter and human connections that happen in
meatspace. Why not use this
time together during the first minute to say “hi”? Then you can jump into the
topics being discussed.
- Turning on your camera allows for more complete and intuitive verbal and
non-verbal communication. When joining meetings with new participants who you
might not be familiar with yet, feel free to leave your camera on or turn it
off. When you lead or cohost a meeting, turn your camera on.
- In an all-remote company, “face time” matters. Remember: even if someone’s
calendar is open, they have other work to do. Limiting (or batching up)
internal meetings can enable longer, uninterrupted stretches of deep work.
Note taking during meetings
Taking notes during meetings provides structure to the call itself, but also
makes it possible for teammates who are not available (or at a different
timezone) to follow what happened and stay aware. Those who are not in the
meeting should have access to the information, but not have the obligation to
review the notes unless explicitly informed that part of the discussion was
relevant to them.
- Everyone has the agenda doc open. Agendas can be “rolling” or “by date”
- Discussion flows linearly through the doc – from the top down if organized
“by date” and from the bottom up if considered “rolling”
- Add your name to the agenda as a way to signal that you’d like to speak. This
helps prevent talking over each other and overcomes the slight delay that is
experienced with videoconference.
- Each teammate adds their point or question in real-time during the call.
Always add your point below others’ that the linear flow is maintained.
- Use numbers instead of bullets so they are more easily referenced in
- Each person’s point should be a separate bullet so that you don’t type on the
same line as a teammate.
NOTE: The general rule is that Google Doc agendas are for real-time
collaboration, and a general scratchpad is attached to a meeting. It is expected
that every task that needs to be done after the meeting ends (the task that was
discussed in the call), gets a separate issue. This means that the person
responsible for the task is responsible for creating an issue and copying the
issue back into the google doc. Once the issue exists, the rest of the
discussion continues in the issue and not in the Google doc. The only exception
here is if the issue contains items that need to be discussed again, at which
point a question is asked in the agenda, with the link to the existing issue.
Using “rolling” vs. “by date” agendas
Rolling agendas are used for 1:1s with the CEO and are suggested for most 1:1
interactions. They are valuable to ensure the completion of topics (because
those topics are removed as soon as they are done) and don’t lend themselves
well to sharing context with others.
“By date” agendas are organized as notes per meeting and have a persistent
record that can be shared with other participants. These are well-suited to
meetings that may benefit from asynchronous participation or where notes may be
referenced by people who were not present for the conversation. They work well
for team meetings. These notes still should be considered “ephemeral” and action
items moved to GitLab issues.
Some of our meetings (and all CEO 1:1s) have a “Rolling Agenda.” This means that
the document is formatted as a numbered list, with each number representing a
topic to discuss. New items are added to the bottom of the document, and in each
discussion, we work from the bottom and proceed as far up the list as we can.
Once an item requires no more discussion it will be deleted. If we don’t make it
to a topic in one conversation it remains there for the next one, or until
Labels for agenda topics
It’s recommended to prefix an agenda item with the name of the person who added
it and a label indicating its purpose. Here are the labels and their meanings:
- DISCUSS - a topic that needs some discussion, explanation, or resolution.
- DONE - a topic that was previously marked TODO has been resolved and can be
cleared by the person who originated the topic. Also used for a decision that
has been made that requires no further discussion or communication. (Use TODO
for decisions that need to be communicated to another party.)
- FYI - a “broadcast message” that you want to vocalize but don’t expect needs
much time. The expected response is either a clarification question or “got
- HELP - share a problem to solicit input on ways to approach it. No need for
resolution, and usually ends with “thanks for the input; I’ll follow up
shortly with a recommendation”
- ISO_DATE - (e.g. “2021-01-20”) a way to postpone discussion of a topic until a
- MOVE - conversation about the topic has been moved to a GitLab issue or epic
- THANKS - call out for great work or appreciation
- TODO - this requires action from one person. May also be used to note
decisions that have been made that require communication with another party.
- In a 1:1 context, TODO will be assumed to be the direct report, instead of
the manager. i.e. it is shorthand for ‘==> Report’
- In a 1:1 context, DOTO can be used as a shorthand for ‘==> Manager’
- The top-level item should be marked TODO and one of its sub-bullets should
be prefixed with ‘==> Person’ to indicate who has the action item
- WONT - to indicate that action was planned, but later decided not to be done.
The topic should be cleared by its originator.
Removing old items from a rolling agenda
The intent of the rolling agenda is for it always to reflect the topics that
need to be discussed, or discussed again. This may be a topic that has gotten
put on the back burner or one that had been agreed to have a follow-up (a TODO)
and needs confirmation from the person who requested it.
To keep the list only to active topics and prevent it from getting overwhelming,
it’s important to remove topics that no longer need discussion. It’s actively
discouraged to use the rolling agenda from retaining notes of what’s been
discussed. Notes of anything important should either be added to the handbook or
moved into a GitLab issue. This ensures that their context is available to
others, and at the time they’re ready to address the issue.
Here’s how to approach cleaning the agenda document:
- Each topic should be preceded by the name of the person who added it. This is
the person responsible for removing the item from the list
- If you added a topic and don’t need to discuss it further, just delete it.
This is common for FYI or THANKS.
- If a topic had previously been marked with DISCUSS, TODO, or DOTO, it should
first be marked as DONE or MOVE or WONT to communicate to the other person
what its status is. This allows them to confirm that they agree no further
action is needed. Once discussed in the next agenda (or viewed
asynchronously), the item can be removed. Remember: only the person whose name
precedes the item can remove it.
CEO has weekly 1:1 meetings with each of his direct reports. They use the
rolling agenda format. Each 1:1 starts with a <10-minute recap from the
direct report of “FYIs and Concerns”. The purpose of this is to efficiently
bring the CEO up to speed on the most important context for the rest of the
discussion. They also serve as a practice for efficient and succinct
communication and as a means to verify that the direct report is on top of the
right set of issues. Each topic in the “FYIs and concerns” should be a sentence
or two, and may entail a quick clarification or question. Items that need more
discussion than that should be called out as separate agenda topics.
Meetings are an important aspect of effective collaboration. They are also an
expensive investment of teammate time, and (especially importantly) the
synchronous time that can be scarce when working across disparate time zones.
The following norms aim to establish efficient and effective practices.
A “pre-mortem” is a structured brainstorming technique to clarify our thinking
around an important and time-sensitive effort. For instance, the deployment of
new software during a site visit. The technique encourages us to imagine that
we’ve completed the project unsuccessfully, and use that hypothetical scenario
to find improvements in the plan.
The process is:
- Document a reasonable plan to deploy the software and share it with the team
ahead of time. During the meeting (or in advance) imagine that we’ve finished
deploying the software according to the plan and since have discovered that
we did not achieve the desired results.
- Describe the scenario that comes to mind, with specifics – e.g. In what
way(s) did we fall short? What’s the situation? What has been communicated?
What are the metrics we’re seeing?
- Work backward from that scenario to hypothesize some of the early
manifestations or signs that pre-dated the failure – e.g. in (hypothetical)
retrospect, what were the early signs? Did we have a “bad feeling” or was it
a surprise? When did we (or could we) have realized it wasn’t working?
- Now, consider some of the strategies that could have averted that scenario –
e.g. was this failure avoidable? What could we have done differently that
might have worked better? At what point in the process should we have taken a
- Articulate some of those strategies and see if some are reasonable to
incorporate into the current best plan
Virtual coffee talks
To keep a personal connection with how people are doing, the CEO holds virtual
coffee talks with each person in the company. The aim is to do these at least
once per quarter and more often as time permits. These do not have a formal
agenda, but you are encouraged to share your thoughts about what’s working well
and what could be improved culturally. We’ll use the 1:1 Agenda document to
collect thoughts if there are specific topics. Preparation is welcome but not