Everyone with a staff knows they need a staff meeting on a recurring basis, often weekly. And those who don’t have staff are themselves in other people’s staff meetings, making it one of the most common meeting types for anyone to attend. Sadly, there is often ambiguity around what they are for, making them annoying and inefficient.

What I Want out of Staff Meetings

The purpose of these meetings is twofold: 1) status updates, and 2) key decision making or the precursor conversations for decision making. I want status updates to be very efficient, well thought out, and delivered only for items that are really required. I want thoughtful conversation on key topics, and I want to cut short conversation when the topics are sufficiently discussed.

Meeting Format

A meeting should be formatted based on what you want out of it.

After years of iterating, my team and I have landed on a format that makes staff meetings useful and efficient for all attendees. We tried a lot of our own ideas, and took good concepts from others (Amazon’s study hall). This isn’t the last iteration (there’s room for improvement), but we’ve finally reached the point where they are highly functional.

Each meeting has a shared google doc. They live in per-team folders, and have the meeting date in the title. They contain a status update section, and proposed agenda for the meeting.

Before the Meeting

Before the meeting, team members fill out their status update section and also put agenda items in a list with their initials. Others can “second” an agenda item with their initials and we will only cover items that have received at least a second vote. There is a strong social contract enforcing preparation such that it’s rare that prep work is not done in time.

The First 10 Minutes

For the first 10 minutes of the meeting, everyone gathers in the room (real or virtual) and begins reading the status updates, silently, together. There are two main benefits of doing it this way. Firstly, the deadline for writing is clear, and the time to start reading is clear. The second is that this reading period ensures that everyone reads the full material, as it is often otherwise skimmed or skipped in the interest of time.

While reading the status updates, meeting participants comment on the updates (using google doc comments), add more agenda items, and second other items. This is all done silently.

The Discussion Section

After the silent portion of the meeting, the team begins the discussion portion of the meeting. First comes the commented portions of the status updates. Then we proceed down the list of agenda items (but only those that have at least two sets of initials by them).

During the discussions, notes are taken in the document, in-line. They are written in red text, and are classified rigidly into 3 types of note: action items (with responsible personnel), key facts, and decisions.

The meeting ends on time (usually early), and anything unattended to becomes automatically added (without need for seconding) to the top of the agenda for the next meeting.

Sample Agenda

Here’s an example of an agenda:

Status

• Person 1
  • I did X
  • My team did Y
  • I’ve been thinking about Z Person 2: What about trying Zeta?
• Person 2
  • More status stuff
  • Cannot get Flooble to compilePerson 1: Have you tried –just-work-already?

Agenda

• Agenda item 1 (initials of proposer)
• Agenda item 2 (initials of proposer, of supporter, [initials of more supporters])
  • Decided: we will use a producer/consumer model for this component
• Agenda item 3 (name or proposer, name of supporter, [names of more supporters])
  • Key Fact: We will not be able to have this QA’d until QA finishes with this other team’s crunch project
  • Action Item: Bob will create an ASCII art logo for MongoDB while waiting for QA to free up.