Skip to article
Bridge

How to run an all-hands meeting people can act on

An all-hands (or town hall) brings the whole company together to hear the same news and question leaders directly. It works when the agenda shows a clear purpose and anyone can ask a question, not just the loudest voice. It also needs a written record people in other time zones can read later.

Decide what this all-hands is for

Company-wide meetings drift into status reports when nobody decides their purpose. GitLab's public handbook gives reasons for its company-wide Ask Me Anything meetings, such as explaining a company-wide initiative and meeting new leaders. Pick one or two purposes per session:

  • Explain a change that affects everyone.
  • Introduce a new leader.
  • Share results and what they mean for priorities.
  • Answer questions on one topic.

When a written update is enough

If the content is one-way and nobody will have questions, a written update may serve people better than an hour of everyone's time. Save the live session for topics where hearing the reasoning and asking follow-ups changes understanding.

Build the agenda around questions

Put the agenda in the calendar invite from the start. GitLab asks hosts to list who will answer questions and open with why the session is happening. It also asks them to say how and where to ask questions.

That last step is the easiest to skip and matters most. If people don't know where to ask, many won't.

Open the question document a few days ahead. Leaders can then prepare real answers to hard questions, and people who can't attend still get heard.

Agenda itemTime in a 45-minute sessionPurpose
Why we are meeting3 minContext for the topic and who is answering
The main update or change12 minWhat changed, why, and what it means for teams
Pre-submitted questions20 minAnswer the most-asked questions first
Live questions8 minQuestions raised by the update itself
What happens next2 minWhere answers and follow-ups will be posted

During the meeting: answer in writing as well as aloud

Have a moderator read questions out and a notetaker write each answer under its question. GitLab documents every question and answer in the agenda. People who miss it can catch up, and attendees don't have to talk over each other.

If you can't answer something on the spot, say so and name who will follow up. Write that down too. An honest “we haven't decided yet”, with a date, builds more trust than a vague answer.

After the meeting: publish the record

Share the recording and the written Q&A with everyone invited, and post follow-up answers in the same place. GitLab asks hosts to add the recording link to the agenda within 12 hours.

If your audience spans time zones, GitLab suggests two sessions: one for the Americas and EMEA, and one for Asia-Pacific.

Sharing the record from Bridge

If you record all-hands meetings in Bridge, you choose who sees the completed meeting: specific people, the whole workspace, workspace groups (Business and Enterprise plans) or anyone with a public link.

Public-link readers can read the notes and conversation but can't edit or reshare them. Check the transcript before you choose that option.

What an all-hands can't do

An all-hands is a poor place to make decisions or handle a sensitive issue that affects a few people. Those need smaller meetings. It also can't replace managers explaining what a change means for their teams.

Use it to give everyone the same information at the same time. Then let teams discuss the details.

Sources & further reading