Adam Niedzielski

Programming is about people

Make your meetings more async

| Comments

Working at GitLab – fully remote, asynchronous and distributed company – was a valuable experience. One of the most important things that I learned was the approach to meetings. In fact, remote meetings at GitLab were far more effective than most of on-site meetings that I participated in. Now I’m back in an office, but I think that many principles and rules can be applied in an on-site company as well.

Create live editable agenda

Every meeting has an agenda attached. If the agenda is empty 30 minutes before the meeting, the meeting gets canceled, because there is nothing to talk about.

The agenda is a document that can be edited live (for example Google Doc). Everybody can add points to the agenda, prefixed with their name (Kate: at the beginning of the line). It’s okay to add your item before existing ones, and to add sub-items, and sub-sub-items.

The “discussion” in the agenda can start way before the meeting happens. You can see what other folks want to say and immediately add your arguments below. Some of the meetings at GitLab had a complete debate a week before the actual meeting.

This approach reduces the pressure to be physically present in the meeting. If you can’t attend that’s totally fine. Just add your points to the agenda with John (not in the meeting): and somebody will read them during the meeting.

Requiring an agenda also helps with rejecting meetings where everybody is unprepared. We have a certain problem, but nobody had time to research the topic? We probably shouldn’t have a meeting now – we will waste time of 5 people. Let’s do the research first and talk later.

Invite many, but make participation optional

Invite many people to the meeting, but make it super clear that their participation is optional. There may be people who want to learn about a given topic even though it’s not their usual area of expertise. And maybe your backend developer can give valuable input on the new UI for your iOS app, because she knows how the API is structured. You never know who might be interested in the meeting.

On the other hand, there is nothing worse than sitting in a meeting that you’re not interested in. Let people decide on their own if they should attend or not. Make not attending a meeting a 100% valid choice.

Find time that works for most

Don’t try to find the time that works for everybody. This approach doesn’t scale as the team grows. In fact, at GitLab it was even hardly possible, because people work across (almost) all timezones.

Finding the time that works for “all important people” is also elitist. It divides your company into people that have “something important to say about this topic” and all the rest. Everybody can contribute valuable points to the discussion, not matter their seniority in the company.

Remember, it’s okay to skip a meeting. You can add your points to the agenda before. And you should trust your team to make a good decision even when you’re not physically there.

People also take time off or get sick. Don’t wait for them with a meeting. If you can’t imagine having a meeting without person X then you probably have a bottleneck in your organisation. What if this person has to take 3 months off or leaves the company?

Start on time

Start on time. Period. Not excuses, no other meetings running late. People prepare mentally for a meeting. They won’t start a new bigger thing 5 minutes before the meeting. If your meeting is running 10 minutes late and includes 6 participants that’s a whole hour wasted.

Follow the order in agenda

Once you have the agenda you simply follow the order in the agenda. The current speaker hands over to the next person in the agenda.

This eliminates the problem of people interrupting each other, sidetracking and more “aggressive” speakers dominating the discussion.

It’s also very introvert-friendly, because it separates “signing up for speaking” from “speaking”. Adding your point to the agenda is easy, because it’s a text-based interface and it happens before the meeting. And then during the meeting you’ll be asked to speak by a previous speaker. No necessity to “fight” to speak.

Editing the agenda can also happen live during the meeting. If you want to reply to the current speaker, add your item below theirs when they are still speaking.

Make action items

When I was a student and I attended some basic management courses I often laughed at the term “action item”.

You can call it as you want. I’ll go with “action item”, because I changed my mind since then. The important thing is that every action item has to have a person responsible. If there’s no person responsible, nobody will do anything.

A meeting without action items is 30 minutes wasted. It’s a discussion without conclusions. An action item can be for example: update company handbook, update description of the task in the issue tracker or create a new task.

Record the meeting

The meeting should be recorded and the recording made easily available within the company. This allows to catch up on the meeting for people who could not attend. It reduces the pressure to be physically present in the meeting even further.

Avoid if possible

The last rule of effective meetings is to avoid them if it’s possible. Always start the discussion in the text format. Submit a pull request that changes your company policies or describe a new frontend architecture in the technical documentation. Chances are that people will agree with you or that you can reach a conclusion by commenting on the pull request. Congratulations, you’ve just saved your company a lot of money!

However, when you notice that you’re going back and forth in the text-based discussion, schedule a meeting. Now there’s the right time to synchronise and talk in person.

Did you enjoy this post? Sign up to my newsletter to get the next bits!

agile, async work, meetings, remote work, software engineering

« ETag tracking and Elixir