@@ -25,33 +25,21 @@ We communicate respectfully and professionally at all times.
1.**Focus on what we can directly influence.** There are many factors we can't directly influence and we should avoid spending time discussing those things. For example, we don't talk about our [market capitalization](/handbook/company/being-a-public-company/#market-capitalization) because aspects of this are out of our control. Instead, we should focus on how we can work together to achieve company objectives and grow [annual recurring revenue](/handbook/sales/sales-term-glossary/arr-in-practice/).
1.**Commit to [active and effective listening](/handbook/leadership/coaching/#essential-coaching-skills)**.
Embracing asynchronous communication and learning to use it effectively requires a mental shift. This can feel unusual or even uncomfortable for those who come from a colocated environment, where in-person meetings and communiques are the norm. Learn more about [mastering the use of the written word in an all-remote setting](/handbook/company/culture/all-remote/).
### Everyone is a moderator
If you see something that concerns you in Slack, Issues, Merge Requests, Video, Emails or any other forum, we encourage you to respectfully say something directly to the individual in a 1:1 format.
If there is an issue to raise regarding someone's communication or conduct, team members should follow the process for [raising communication concerns](/handbook/people-group/team-member-relations/#raising-communication-concerns) by sharing their concern with their manager or, if preferred, email Team Member Relations (teammemberrelations@gitlab.com) directly.
### Asynchronous communication
In an [all-remote setting](/handbook/company/culture/all-remote/terminology/), where team members are empowered to live and work where they're most fulfilled, mastering asynchronous workflows is vital to avoiding [dysfunction](/handbook/values/#five-dysfunctions) and enjoying outsized efficiencies and lifestyle flexibility. Asynchronous communication is the art of communicating and moving projects forward *without* the need for additional stakeholders to be available at the same time your communique is sent.
Asynchronous communication is the art of communicating and moving projects forward *without* the need for additional stakeholders to be available at the same time your communique is sent.
To learn more on when to use asynchronous and synchronous communication, examples of async workflows in practice at GitLab, core async behaviors, and to take an async knowledge assessment, visit [GitLab's guide to embracing asynchronous communication](/handbook/company/culture/all-remote/asynchronous/).
In distributed systems, async and sync communication aren't ideologies. They're tools, each with a job. Async messaging (queues, pub/sub, event streams) is how you scale. It decouples producers from consumers, absorbs bursty load, and lets services keep working when peers are slow or down. Sync calls (RPC, request/response) are how you coordinate when correctness depends on a fresh, agreed-upon answer right now: a payment authorization, a lock acquisition, a leader election. Build everything async and you get a system that scales beautifully but can't make a decision. Build everything sync and you get a system that's correct but brittle, where one slow node stalls the whole graph.
### Transparent Communication
The same pattern applies to how we work. Slack, docs, and GitLab issues are our async layer. They scale across timezones, create durable artifacts, and let people work without blocking on each other. That's most of the work, and it should be. But some decisions require a synchronous transaction. Aligning on a strategy shift, resolving a real disagreement, building trust with a new exec, debugging a problem where the context isn't yet legible enough to write down, these are the moments where the round-trip latency of async (a thread that takes four days and seventeen replies to converge) is worse than thirty minutes of sync. The failure mode of "async-only" is the same failure mode as an event-driven architecture with no synchronous endpoints. You get eventual consistency on decisions. Threads fork, context drifts, no one knows who decided what, and the work that needed a clean commit point becomes a slow-moving consensus problem instead.
As GitLab grows, multiple teams are working together to scale up our processes, policies and systems. Leadership DRIs also strive to make decisions that will directly or indirectly impact team members. In order to make sure we provide adequate communications on these incoming changes, the following communication matrix aims to provide guidance for both leadership and team member on what to expect for each type of change.
*Team Member Resource*: To learn more on when to use asynchronous and synchronous communication, review this full[overview of async vs. sync with additional guidance](https://docs.google.com/document/d/192o14Euw2n1v3enmXVuf-yvqb31HPwT7NAHqaenwaZc/edit?tab=t.0).
| Communication Type | Explanation of Why | Feedback Mechanism | Example |
|-----------|-------------|---------|---------|
| **Decision has already been made** | Within confines of SAFE, explain why this decision was made, and "What prompted you to make this decision" | Provide a link to an issue or similar where feedback can be submitted but with the understanding that the decision may not change in the near future | GitLab's New Operating Model |
| **Intent/Proposal discussion** | "Why" is explained in detail, with data where possible. Include "What are we looking for, Problem to solve, Here are all the options, go deeper" – what do you expect from others (based on what they can influence) | Provide a link to the issue or similar where feedback can be provided. Also share timeline by when feedback is gathered and provide updates on decision making process | Moving Friends and Family to End of Year (we've seen problems with XYZ so we'd like to move to end of year, and would like feedback on these specific / more targeted areas) |
### Everyone is a moderator
### Communicate directly
If you see something that concerns you in Slack, Issues, Merge Requests, Video, Emails or any other forum, we encourage you to respectfully say something directly to the individual in a 1:1 format.
When working on a problem or issue, communicate directly with the people you need support from rather than working through reporting lines. Direct communication with the people you need to collaborate with is more efficient than working through your manager, their manager, or another intermediary.
Escalate to management if you are not getting the support you need. Remember that everyone is a [manager of one](/handbook/values/#managers-of-one) and they might have to complete their own assignments and inform the reporting lines.
If there is an issue to raise regarding someone's communication or conduct, team members should follow the process for [raising communication concerns](/handbook/people-group/team-member-relations/#raising-communication-concerns) by sharing their concern with their manager or, if preferred, email Team Member Relations (teammemberrelations@gitlab.com) directly.
@@ -175,7 +175,7 @@ If you do happen to denylist a link or a domain, they can be modified in the Wor
If you see a team member share posts with multiple link previews that you think are distracting, in channels like `#whats-happening-at-gitlab`, consider acting in the spirit of [Everyone is a moderator](/handbook/communication/#everyone-is-a-moderator) and either:
-[Letting them know in a DM](/handbook/communication/#communicate-directly) that it's adding noise to their message.
- Letting them know in a DM that it's adding noise to their message.
- Reacting to their message with the `:consider-removing-link-previews-to-keep-the-channel-tidy-please:` emoji.
