GitLab Handbook: Communication

What it is

GitLab runs its company from a public handbook, and the Communication page is its guide to how people there write, meet and talk. GitLab is an all-remote company with staff around the world, so the page is especially detailed on written and asynchronous communication.

Sections include asynchronous communication, transparent and direct communication, communicating when using generative AI tools, handling sensitive topics, choosing which channel to use, meetings (including common meeting problems, shared notes and video calls), writing style guidelines, communicating dates and times, simple language, email, Slack etiquette such as avoiding direct messages and using public channels, and types of documents.

Why it matters in a first job

Most of your impact as a new engineer travels through writing: tickets, pull request descriptions, chat messages, status updates. The handbook shows what good looks like in a company that depends on writing. A few ideas worth adopting straight away:

• Low-context communication. Be explicit and give enough context that someone in another time zone, or someone reading later, can act without a follow-up question.
• Public channels over private messages. Questions asked in a team channel help the next person with the same problem, and more people can answer.
• Everyone takes notes. Shared, written meeting notes mean decisions do not live only in people's heads.
• Simple language. Short sentences and plain words help colleagues who, like many engineers, use English as a second language. GitLab states that all written communication there happens in English.

How to use it

Do not try to read it all. Read the asynchronous communication, meetings, writing style and Slack sections, then compare them with how your own team works. Your company's norms win where they differ, but the handbook gives you words for asking about them ("should questions like this go in the team channel?").

It pairs well with GitLab's separate guide to all-remote work, also in the Sefism library, if you are joining a remote or hybrid team.

Free vs paid

Free and public. The handbook changes often, as it is edited through merge requests like code, so some section names may move.

Is it worth it?

Yes. It is one of the few detailed, real-world descriptions of how a large engineering organisation communicates, and most of it applies to any team, remote or not.

Common questions

Is it only for remote teams? No. Office teams also rely on chat, tickets and documents; the habits carry across.

Should I suggest GitLab's rules to my team? Use them yourself first. If something would help the team, raise it in a retro with a specific example.