Meetings

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:

  1. 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.
  2. 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.
  3. Open Google Calendar, tap the “+ Create” icon then Event.
  4. Enter the meeting details, set time and time zone (if needed), and add invitees, or location
  5. Add links to the agenda or documents relevant to the meeting.
  6. 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.
  7. Tap Save.

Internal meeting scheduling

  1. 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 invite.
  2. Prefer this strategy over negotiating meeting times via chat – This can save a lot of communication overhead, especially when scheduling with multiple participants.
  3. 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.

Meeting format

  1. Meetings must be scheduled using Google Calendar and should have a zoom link included
  2. 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.
  3. Meeting requests will remain ON HOLD if the above format is not completed (Example: missing documentation, agenda, etc)
  4. 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.
  5. Meetings start right on time, and must be “speedy meetings.” This means they end 5 minutes prior to a 30-minute slot or 10 minutes prior to an hour slot
  6. 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.
  7. 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 managing agendas.

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.

Meeting ettiquette

  1. Always record meetings so they can be re-watched later, or viewed by anyone who wasn’t there.
  2. 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 counterparts down.
    When in doubt, show up a couple of minutes early. If you were late, the meeting will have been recorded.
  3. 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.
  4. 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.
  5. 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.

  1. Everyone has the agenda doc open. Agendas can be “rolling” or “by date”
  2. Discussion flows linearly through the doc – from the top down if organized “by date” and from the bottom up if considered “rolling”
  3. 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.
  4. 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.
  5. Use numbers instead of bullets so they are more easily referenced in conversation.
  6. 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.

Rolling agenda

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 needed.

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 it”.
  • 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 particular date
  • 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.

1:1 Meetings

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.

Pre-mortem

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:

  1. 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.
  2. 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?
  3. 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?
  4. 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 different action?
  5. 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 required.

Synura logo
Product Company
Features About
Pricing Handbook
Blog Contact
>> We're hiring! <<