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 item | Time in a 45-minute session | Purpose |
|---|---|---|
| Why we are meeting | 3 min | Context for the topic and who is answering |
| The main update or change | 12 min | What changed, why, and what it means for teams |
| Pre-submitted questions | 20 min | Answer the most-asked questions first |
| Live questions | 8 min | Questions raised by the update itself |
| What happens next | 2 min | Where 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.
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.




