On this pageWe're an all-remote company that allows people to work from almost anywhere in the world. We hire great people regardless of where they live, but with GitLab team members across more than 60 countries, it's important for us to practice clear communication in ways that help us stay connected and work more efficiently. Show
To accomplish this, we use asynchronous communication as a starting point and stay as open and transparent as we can by communicating through public issues, merge requests, and Slack channels. We also place an emphasis on ensuring that conclusions of offline conversations are written down. When we go back and forth three times, we jump on a synchronous video call. We communicate respectfully and professionally at all times. Effective & responsible communication guidelines
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. Everyone is a moderatorIf 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 you are not comfortable reaching out to the individual directly, please reach out to your direct manager or People Business Partner to discuss. Communicating Potentially GitLab Sensitive Topics(This guidance supplements and overlaps with GitLab's SAFE Framework, the guidance on the use of the internal handbook, and the additional guidance on this page. We ask our team members to consider the factors below in their communication. ) As GitLab matures, we want to continue to foster discussion while evolving our communication guidelines so that topics that are potentially GitLab sensitive are discussed in appropriate forums. This is particularly relevant as team members heavily leverage async modes of communication including merge requests, issues and epics, and in Slack communication. Words have impact long after they are written, and even when you're communicating internally, the manner in which you speak with one another should be viewed through an external lens. For additional information, please review our Guidelines for communicating effectively and responsibly through text. Confidentiality levelsAt GitLab, we are public by default, but some information is classified as internal or limited access. Please see the confidentiality levels handbook page for details on this. Examples of Potentially GitLab Sensitive Topics
The above examples overlap with the GitLab's SAFE Framework examples. We recommend you to further review that page for more information and context. What are the risks?
We encourage communicating risks to GitLab, its team members, or customers in a synchronous 1:1 setting. Determining Which Communication Forum To UseThe table below outlines an overview of different communication forums at GitLab, and the considerations team members should think through related to potentially GitLab Sensitive topics when determining which forum to leverage.
When in doubt, you can reach out to your People Business Partner and/or your leadership team directly. External communicationKey practices to consider during any meeting are listed below.
Communicating with media and industry analystsGitLab team members are not authorized to speak with the media or analysts on behalf of our company unless authorized by our Marketing department. Unless authorized, do not give the impression that you are speaking on behalf of GitLab in any communication that may become public. This includes posts to online forums, social media sites, blogs, chat rooms, and bulletin boards. This policy also applies to comments to journalists about specific matters that relate to our businesses, as well as letters to the editor and endorsements of products or services. For more, please visit the Corporate Communications handbook section. Paid external speaking requestsGitLab as the leader in all remote work creates opportunities for our team members to receive requests from external 3rd parties to participate on panels, blogs or news publication or articles. Recently our team members have been approached by external 3rd parties looking to pay or compensate GitLab team members for their time to discuss GitLab remote practice to help them guide a client. Other third parties may contact GitLab team members to provide subject matter expertise that they may have by virtue of their role at GitLab. As in any request we ask that team members verify who they are speaking with to make sure the source is indeed a valid and legitimate request. Always remember that you represent GitLab and if any question makes you uncomfortable or gives you a pause on whether you should answer then we recommend that you do not answer. A third party's questions regarding GitLab financials, sales, compliance, executives or specifically where the company is heading should be treated with the most caution. We want and encourage all team members to be remote evangelists and this can be done without giving very specific information about GitLab. If you have any concern about a request please reach out on slack to #external-comms Social mediaPlease see our team member social media policy. Start with a Merge RequestWhen possible, it's best practice to start a discussion with a Merge Request (MR) instead of an issue. An MR is associated with a specific change that is proposed and transparent for everyone to review and openly discuss. The nature of MRs facilitate discussions around a proposed solution to a problem that is actionable. An MR is actionable, while an issue will take longer to take action on.
Scaling Merge Requests through "Manager Mention MRs" (formerly Consolidated MRs)Some merge requests that involve a big decision or change tend to collect a large amount of feedback. As GitLab grows in size, it is unrealistic for a single person to respond to potentially hundreds of comments. To remain efficient in these MRs and to make it scalable, it is important for the DRI to receive a clear signal of input that is shared on the merge request. Some MRs may be marked as "Manager Mention MRs" by clearly designating them as such at the beginning of the MR description with the following code block:
Additionally, add the We tried Manager Mention MR’s for the first time in a recent announcement (2021-03-03) but this did not work well and we are working on making it better. We're starting with a more thoughtful and transparent process in our communications cadence and approach going forward, including all directs and people managers getting a few days’ notice before important company-wide changes are announced to all team members. This will allow all directs and people managers to feel more enabled and better understand the why behind big changes in order to scale communication to team members. For all managers: It is important to ground yourself in the contents of the changes before the announcement goes live to all team members. If a team member tags you in a Manager Mention MR, it is your
role to respond candidly and thoughtfully to their question or comment. If the line of questioning in the Manager Mention MR gets out of your depth, ask the DRI to help answer. If a team member comments without a manager tagged, the comment will be closed with a link to this handbook section or closed without comment. In a situation where a team member leaves a wildly inappropriate comment in the Manager Mention MR, you should feel empowered to delete comment and talk to your team member 1:1.
Consider subscribing to the label
For team members: Check if the MR you are about to comment on has the
MRs should not start out as a Manager Mention MR as we prefer communication to be direct. They should only be designated as such after the number of comments on them grows to a level that is unsustainable for the DRI. An exception to this is compensation changes and other company-wide announcements that can be sensitive/contentious in nature since they have historically generated many comments. When an MR is changed to be IssuesIssues are valuable when there isn't a specific code change that is being proposed, such as:
When utilizing issues, it is still important to maintain focus by defining a single specific topic of discussion and the desired outcome that would result in the resolution of the issue. Issues should not be open-ended or go stale due to lack of resolution. For example, a team member may open an issue to track the progress of a blog post with associated to-do items that need to be completed by a certain date (e.g. first draft, peer review, publish). Once the specific items are completed, the issue can successfully be closed. Below are a few things to remember when creating issues:
Pro Tip: When creating a Merge Request you can add
Internal communicationInternal communication is any work related communication at a company. Internal Communication includes conversations between team members, wider team discussions, or internal announcements. At GitLab, everyone can contribute to the effectiveness of Internal Communications to support aspects of GitLab culture, such as intentional transparency and engaging people in open dialogue. Since we believe that all team members must be Managers of One, most communication is handled by the relevant group, but we know that some communications are more sensitive and contentious than others. In those cases, the DRIs may want to engage the Internal Communications function. Informal communicationInformal communication is made up of interactions between co-workers that are unofficial in nature and focus on building social relationships outside of the normal hierarchy of a typical business structure. In other words, it's what happens when we get to know each other and talk about anything other than work. Informal communication is a vital part of GitLab culture, and we've listed 20+ ways to engage. Asynchronous communicationIn an all-remote setting, where team members are empowered to live and work where they're most fulfilled, mastering asynchronous workflows is vital to avoiding dysfunction 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. 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. Top tips and best practices
How to make a company wide announcement
Ask Me Anything meetingsAsk Me Anything meetings can be a useful opportunity for team members to meet a new leader, learn more about an existing team member, or gain clarity on a recent change.
Fireside ChatsFireside chats are informal conversations between a host and a guest. The guest is typically a new leader, board member, or guest speaker. They are a useful opportunity to learn specific information about these individuals and their professional careers and personal interests. Fireside chats allow the audience to learn more about the guests in a casual and approachable setting. Format: In advance of the call, the host will prepare questions and share them with the guest. During the call, the host will moderate the conversation with the guest, by verbalizing the prepared questions. There is specific amount of time reserved at the end of the agenda for questions from attendees. Smart note-taking in meetingsNote taking helps us to work with people asynchronously as team members can add their thoughts to an agenda in advance of a meeting and understand what was discussed if they cannot attend. It also offers a record of what was discussed that can later be referenced. While it may not be feasible to capture all words said in a meeting, focus on noting speakers and their key points. Extensive note-taking should not happen at the expense of correct note-taking. At the end of the meeting, try to clearly capture key takeaways, next steps, and DRIs. While a designated person may be the primary person responsible for note-taking in a specific meeting, all team members should feel empowered to chip in. Note-taking can be a lot for a single person to stay on top of–especially when there is a fast moving conversation with many speakers. Team members can contribute by helping with notes, correcting anything that is incorrect (names, abbreviations, etc.), and adding key details that were important but missed. Use discretion in taking notes if sensitive topics are being discussed. For example, do not takes notes on not-public information if the agenda may be available to an audience who should not be privy to this information. In a conversation, a person may ask for folks to stop taking notes. When this happens, note-taking should stop for the duration of the discussion unless there is verbal confirmation that note-taking should resume. When you suspect that note-taking should resume, but it has not been verbally confirmed, please ask for the confirmation before typing. If you have any questions about what may or may not be a sensitive topic, please
refer to our SAFE Framework or reach out via the Posting in #company-fyigraph TB everybody{{"Do you want to reach the entire company?"}} important{{"How important is it?"}} permission{{"Do you have permission Posting in #company-fyiOur companywide announcements channel is #company-fyi. It is an announcement only channel, meaning that communications need to be approved before they can be posted. To minimize noise, announcements made in
In order to post or have a message posted in Examples of what should not go in #company-fyi (as per new group guidelines):
The above should all go in the new #whats-happening-at-GitLab channel
(formerly the Posting in #whats-happening-at-gitlabDue to the volume of posts in the Slack channel, we recommend that you do not use #whats-happening-at-gitlab as a sole location for important announcements as information might get lost or muted. Examples of important items include but are not limited to:
Top misused termsPlease see our Top misused terms page. Asking "is this known"If something is behaving strangely on https://gitlab.com, it might be a bug. It could also mean that something was changed intentionally. Please search if the issue has already been reported. If it has not been reported, and you are sure it is a bug, please file an issue. If you are unsure whether the behavior you experience is a bug, you may ask in the Slack channel #is-this-known. If you know which stage of the DevOps lifecycle is affected, it is also okay to ask in #s_{stage}, for example #s_manage. When you ask:
Multimodal communicationEmploy multimodal communication to broadcast important decisions. To reach our distributed organization, announce important decisions in the company announcements Slack channel, email the appropriate team email lists, Slack the appropriate channels, and target 1:1s or other important meetings on the same day, with the same information. When doing this, create and link to a single source of truth: ideally the handbook, otherwise an epic, issue, or Google Doc. The email or Slack message should not be the source of truth. When referring to email that recipients should have received, reference the sender and subject of the email so it's easy to find. For example, "You should have received an email from Jane Smith with the subject 'Training Seminar Details'". Effective communication competencyCompetencies are the Single Source of Truth (SSoT) framework for things we need team members to learn. In an all-remote organization effective communication is key to exchanging knowledge, ideas, and information. Effective communication at GitLab:
If you would like to improve your skills or expand your knowledge on topics relating to Communication at GitLab, check out our resources:
Skills and behavior of applying effective communication as a Team Member:
Skills and behavior of applying effective communication as a People Manager:
Numbering is for reference, not as a signalWhen taking notes in an agenda, in the handbook, or on our OKRs, keep items numbered so we can refer to Item 3 or 4a. The number is not a signal of the importance or rank of the subject unless explicitly stated to be such. It is just for ease of reference. Cross linkLinking should not be in one direction. We should go beyond deep-linking to create a richer web of links that can surface content and ensure people consider all pages when making updates. When linking one page to another, try to link back as well. Instead of only linking from Page A to Page B, both link Page A to Page B and link Page B back to Page A. For example, the Live Doc Meeting section of the All Remote Guide links to the Live Docs Meetings page. The Live Docs Meetings page links back to the Live Doc Meeting section of the All Remote Guide. Acknowledgement Receipts (ACK)In order to effectively communicate an important change to hundreds of distributed employees, we occasionally use an ACK process. To prevent overuse, this should only be used by a member of the exec team. Anyone may ask an exec to sponsor one. As a guideline, we'd expect no more than one per quarter to be sent out. Too many ACKs lose power. To initiate an ACK process:
In informal acknowledgement scenarios, such as on Slack or on issue comments, it is common practice to use the following:
Presentations
Video and presentation tips with Lorraine LeeOn 2022-01-20, the L&D team hosted Lorraine Lee for a live speaker series on video and presentation techniques in an all-remote workspace. Key points addressed in the training include:
Watch the replay below: Say thanksAs we continue to build on inclusion, recognition is a key and transformative tactic. Thanking team members provides an opportunity for them to be recognized for their contributions, influences engagement behavior, and acknowledges to team members their work is seen. By saying thanks, you are contributing to and supporting the value of DIB.
Values emojiAdd Values emoji reactions to thank you messages in the
As a second iteration, we will add these custom emoji to GitLab to enable tanuki values reactions in issues and MRs. As a later iteration, we will begin tracking the number of emoji reactions for each value through the Reacji API and update this page with our findings! Communicate directlyWhen 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 and they might have to complete their own assignments and inform the reporting lines. Effective ListeningIt is estimated that listeners will filter out or change the intended meaning of what is heard in 70% of all communications. Source. Myths about Listening
Tips for Effective Listening
Being Assertive There is a delicate balance between being confident enough to be assertive of personal rights and boundaries while respectful of others.
Not sure where to go?If there is something that you want to discuss, but you do not feel that it is a reasonable option to discuss with either your manager or CEO, then you can reach out to any of the other C-level GitLab team members or our board member Bruce Armstrong. Social callAt GitLab, social calls are considered an important way to foster culture while organically creating connections between team members with similar interests or hobbies. These calls happen three times a month at varying times to ensure that team members in all timezones are able to take part. We currently have one open or random topic room along with three topic specific ones based on the
most popular channels within Slack i.e. Previously social calls never had a set agenda however participants are now encouraged to document discussion points or questions in the relevant Google Doc - this is to ensure those considering attending have an overview of what to expect along with offering those who were unable to attend an opportunity to scroll back and review points of interest. The use of a document also serves to ensure that everyone gets a chance to contribute to the conversation. Social call attendance is not mandatory however the sessions do serve as a great way to get to know fellow team members, take a break or (depending on your region) start the day on a fun note. Monthly call cycle
All social calls are in the Team Meetings Calendar - the sessions are titled Talkative Tuesdays - GitLab Social Call and once you have opened the invite you will see a brief introduction followed by the three topics all of which have unique links for both Zoom and the respective Google Doc. Being mindful of those who will be taking part, team members are asked to join on time and mute their microphones when they are not speaking. Social calls are not moderated and with this in mind all those who take part play this role and should feel free to chime in if and when necessary. If you have any questions around the Social Call schedule please be sure to engage with the People Connect Team via the #people-connect channel. Feedback and suggestions are welcome and can be documented in the comments section of this issue. Using call attendance data along with feedback and suggestions provided by team members call topics will be reviewed and if necessary adjusted on a quarterly basis. Mindfulness Call
Walk and Talk callsA Walk and Talk call is when team members step away from their computers and get outside for a meeting. The difference between a coffee chat and a Walk and Talk call is that a Walk and Talk call be held with people that you interact with frequently at GitLab. It could be social in nature or focused on a specific problem/topic that needs to be discussed. If it's a problem-solving focused discussion, the outcome should be captured in a merge request. It should not be used if the problem being discussed requires screen sharing or detailed note taking. There are great physical and mental health benefits to a walk and talk call. There are also benefits with increased focus and creativity. A Walk and Talk can also help prevent Zoom fatigue. The team members can use Zoom on their mobile device with the audio only function, or call one another from their preferred mobile device. A walk and talk call should be agreed to in advance to ensure that the local weather is compatible for a walk in both locations and that the walk and talk call fits into both team members’ schedules. We’ve created a Slack channel #walk-and-talk-meetings where, if you'd like, you can share pictures from your walking meetings. Release retrospectives and kickoffsAfter GitLab releases a new version on the 22nd of each month, we have a 30-minute call a few days later reflecting on what could have been better:
We spend the first part of the retrospective meeting reviewing the action items from the previous month. On the 8th of each month (or the next business day), we have a kickoff meeting for the version that will be released in the following month. The product team and other leads will have already had discussions on what should be prioritized for that release. The purpose of this kickoff is to get everyone on the same page and to invite comments. Both the retrospectives and kickoffs are live streamed to our GitLab Unfiltered YouTube channel and posted to our Unfiltered YouTube channel. Random
Scheduling meetings
Cross-regional Working Hours RecommendationsThe following chart shows some helpful suggestions/considerations for scheduling across multiple regions while being respectful of common working hours. EMEA/AMER
APAC/AMER
EMEA/APAC
Guidelines for vendor meetings
Meeting introduction guidelinesIntroductions can be helpful during some external meetings, such as executive sales calls. In those meetings, use these guidelines:
In this example, the introductions would be:
Focus FridaysThe goal of Focus Fridays is to maximize efficiency by creating designated meeting-free space within our weeks for focused work, which also aligns with our push to operate asynchronously. Other benefits include reducing potential burnout, and being more thoughtful both in and about the meetings on the other days of the week. Guidance for Focus Fridays includes:
You are encouraged to talk to your manager for guidance on how best to embrace Focus Fridays on your team and with your individual schedule. Consider joining #focus-fridays in slack and share how you spent your Friday including what has worked for you and what has not worked. Managers are encouraged to provide coaching and guidance. Focus Fridays began as an experiment in the Northern Hemisphere Summer/Southern Hemisphere Winter of 2020 which ran through 2020-09-07, at which time E-Group evaluated the effectiveness on productivity and morale. They found the impact to be a positive one and extended the program until 2021-04-30. On 2021-04-26, the E-Group met and reviewed the feedback issue and found the overall sentiment from the team is that Focus Fridays are instrumental in helping folks concentrate and give space for creative thinking, encourage asynchronous work, and nurture team member well-being. E-Group decided to keep Focus Fridays permanently. Meeting Cleanup DayOn February 14, or the Tuesday after if this day falls over the weekend or on Monday, we have an annual calendar cleanup day. This is a day when all team members are encouraged to look at their calendars and reassess the value and frequency of recurring meetings. The goals are to increase team member efficiency as team members stop attending low value meetings and reassess how to make continuing meetings more productive. Team members should be empowered to:
When cancelling a meeting, a team member can copy and paste this message to send to attendees: I evaluated the need for this meeting as part of Meeting Cleanup Day. I have determined that the meeting is no longer needed. Please get in touch if you have any concerns. When changing the cadence of a meeting, a team member can copy and paste this message to send to attendees: I reassessed this meeting as part of Meeting Cleanup Day. I have determined that the meeting no longer needs to happen as frequently. Please look for an updated meeting invite and get in touch if you have any concerns. If you are a team member who intends to decline a meeting, the asynchronous communication section of the handbook has some good suggestions for what to say when you decline. Meeting Cleanup Day is intentionally a few weeks after the start of the new fiscal year. The CoS to the CEO will launch this initiative annually a week in advance through posting in the Common meeting problemsMeetings are incredibly expensive since they require synchronous time. The most common meeting problems can all be addressed by following the above guidelines around scheduling meetings. Some of the most common meetings problems are outlined below:
No presenting in meetingsIf you are hosting a meeting, it's okay not to have a presentation or have a pre-recorded presentation. What's not okay is doing the presentation during the session because you are taking valuable synchronous time away from the attendees, which could be asynchronous. It is easier to watch YouTube in more locations than joining a Zoom call. A recording makes content more accessible, prevents confusion, and increases participation for team members that prefer consuming content asynchronously. Meetings take up valuable time and resources for the company. They are expensive since they require synchronous time. In the video below, GitLab CEO Sid Sijbrandij explains why there are no presentations in meetings. Make a pre-recorded video presentation on our Unfiltered YouTube channel, and attach it to the meeting agenda. At least 24 hours in advance of the meeting, announce in Slack Channels that the meeting has a pre-recorded video, and all attendees are advised to watch beforehand. Use the meeting time for Q&A versus presenting information to the audience with slides. Pre-recorded presentations enable the following:
There are times when presenting during a meeting is needed. This may occur when adding more context to a specific topic on slides. If this is the case, consider the following:
Indicating availabilityIndicate your availability by updating your own calendar using Google's "out of office" feature and include the dates you plan to be away in your automated response. Note that this feature will automatically decline any meeting invitations during the time frame you select.
Video calls
HeadphonesAs a remote company we strive to have the highest fidelity collaborative conversations. Use of a headset with a microphone is strongly suggested. Reasons to use headphones:
Leave the no headphones to:
Suggested headphone models can be found in the handbook under spending company money. If you want to use your Bose headphones, that is fine, but please ensure the microphone is active. Note taking
You are the manager of your attentionYou are the manager of your attention, and you decide when you do or don't pay attention in a meeting. You will always have more work than time in your life. If you get invited to a meeting you don't think you should go to, you should decline the meeting. It is better to cancel than to show up and not pay attention. On the other hand, not every part of a meeting is relevant, but it can sometimes be helpful to have more people in a call. If you only have one discussion point, if possible, try to reorder the meeting agenda to have your point first and then drop from the call. If you get asked a question when you're not paying attention, it is an okay use of time to repeat a question every now and then. If training is required for one's role, team members should plan to give the training full attention–especially if engagement in discussions or breakout rooms is required. If training is 'nice to learn' or 'optional' for team members, multi-tasking can be done at the team members discretion. We don't use the first 15 minutes of a meeting to read the materials like they do at Amazon. You can use the start of a meeting to review the materials for the meeting if you need to, given you do not have to be paying attention, but that should not delay the start of the meeting for the people that already have questions based on the materials. Meetings start on time at GitLab. Do not use your camera to signal you're not paying attention; cameras should always be on. Do not ask meeting attendees to pay attentionThere are too few hours in a week, so we expect each team member to manage their attention. If you're hosting a meeting, don't tell people to give you their attention or stop multi-tasking. Respect each team member's agency over their time. Instead of demanding attention, earn participants' attention by organizing and facilitating meetings so they are compelling to attendees. First post is a badge of honorYou should take pride in being the first person to add a question to a meeting agenda, however unlike the First post meme we do want the first post to be more than just "First!". The meeting DRI will be happy to see there is a question ready before to kick off the meeting. The Meeting DRI should remember to thank the person for asking the first question. Do not do a countdown before ending a callNever do a countdown or say something like. "I'll give it x seconds", people are very unlikely to ask a question if you do that. Either ask for a question, wait for a question, or end the call. Hybrid calls are annoyingIn calls that have remote participants everyone should use their own equipment (camera, headset, screen). When multiple people share equipment the following problems arise for remote participants:
The people sharing equipment also have problems because they don't have their own equipment:
The disadvantages for remote people are much greater than for the sharing people and hard to notice for the sharing people. The disadvantages cause previously remote participants to travel to the meeting to be in person for a better experience. The extra travel is inefficient since it is time consuming, expensive, bad for the environment, and unhealthy. Theoretically you can have multiple people in a room with their own equipment but in practice it is much better to be in separate rooms:
User communication guidelines
Writing style guidelines
Communicating dates and time
VisualsMany times an explanation can be aided by a visual. Whenever presenting a diagram, we should still allow everyone to contribute. Where possible, take advantage of the handbook's support for Mermaid. If you are new to using Mermaid or need help troubleshooting errors in your Mermaid code, the Mermaid Live Editor can be a helpful tool. Where taking advantage of Mermaid isn't possible, link to the original in our Google Drive so that the diagram can be edited by anyone. Situation-Complication-Implication-Position-Action-Benefit (SCI-PAB®)Mandel Communications refers to SCI-PAB® at the "surefire, six-step method for starting any conversation or presentation." When you only have a few minutes to present your case or grab your listener's attention, this six-step process can help you communicate better and faster.
Example - The Management team asking for time to resolve a problem
Some examples can be found at SCI-PAB - Six Steps To Reach Your Audience. Company phone numberIf you need to provide the details of GitLab's contact information you can take the address from the visiting page for reference; or the mailing address of the office in the Netherlands if that is more applicable. If a phone number is required, leave this field empty by default. If that is not possible, then use the general number (+1-415-761-1791), but be aware that this number simply guides to a voice message that refers the caller back to contacting us via email. Organization code names
There are two types of code names:
Ubiquitous languageAt GitLab we use ubiquitous language to increase communication efficiency. This is defined in Domain-driven design as: "A language structured around the domain model and used by all team members to connect all the activities of the team with the software." We use it for activities in GitLab, even ones not implemented in software. By having ubiquitous words to identify concepts we prevent confusion over what is meant, for example we refer to parts of our organization as a function, department, or group depending on exactly what is meant. Make sure that domains don't overlap, for example organization size and deal size don't reuse words to prevent overlap. If a term is ambiguous don't use it, for example our hiring definitions have roles and vacancies but avoid the ambiguous word job. Make sure that projects and working groups have clear and direct names. Prefer "CI Spend Reduction Working Group" to "Project Raven Working Group". Make sure that people can infer as much as possible from the word, for example our subscription options allow you to know if someone is using self-managed or GitLab.com. Make sure terms don't overlap without clearly defining how and why, for example see our tier definitions. Keep terms to one or at most two words to prevent people from introducing ambiguity by shortening a term. When using two words make the first word unique because people tend to drop the second word more often. MECEFU termsMECEFU is an acronym for Mutually Exclusive Collectively Exhaustive Few words Ubiquitous-language. You pronounce it: MessiFu. Think of the great soccer player Lionel Messi and his kung fu or soccer fu skills. We want to use MECEFU terms to describe a domain to ensure efficient communication. MECEFU terms have 4 characteristics that help with efficiency:
An example of a MECEFU term is our sales segmentation:
One nit-pick is that the Medium of SMB and Mid of Mid-Market sound very similar. Simple languageSimple Language is meant to encourage everyone at GitLab to simplify the language we use. We should always use the most clear, straightforward, and meaningful words possible in every conversation. Avoid using "fluff" words, jargon, or "corporate-speak" phrases that don't add value. When you don't use Simple Language, you:
When you do use Simple Language, you:
Here's an example: Original sentence
A Simple Language sentence
Simple Language is important both when we're speaking to other team members and when we're representing GitLab to people outside the company. Be sure to use Simple Language in written communications as well. Our handbook, website, docs, marketing materials, and candidate or customer emails should be clear, concise, and effective. Corporate marketing maintains guidelines on GitLab's tone of voice.
Inefficient things shouldn't sound positiveFor example, do not suggest that you're "working in real-time" when a matter is in disarray. Convey that a lack of organization is hampering a result, and provide feedback and clear steps on resolving. Do not use a cool term such as "tiger team" when the existing term of "working group" is more exact. While cool terms such as these may be useful for persuading colleagues to join you in working towards a solution, the right way isn't to use flowery language. The last example is when we used 'Prioritizing for Global Optimization' for what we now call a headcount reset. When we renamed it we saw a good reduction in the use of this disruptive practice of moving people around. Deep DivesAs GitLab continues to grow, sharing knowledge across the community becomes even more important. The Deep Dives page describes initiatives we are trying to encourage. This aligns with how we work since everything at GitLab is public by default. We have a low internal email culture, as we see greater efficiency in other forms of communication (e.g. Slack). If you are emailing, please use the following guidelines:
SlackSlack is used for:
Use a bias for action to quickly move conversations that require collaboration and action out of Slack and into an issue. Only 90 days of Slack activity will be retained, so Slack should specifically NOT be used for:
Internal Slack messages between team members are still considered professional communication. Please do not use or add emoji's to Slack that are of a political, religious or of a sexual nature. You can refer to the Religion and politics at work section of the handbook. When in doubt do not use or add the emoji. If you have any concerns about an emoji that was used, please reach out to the author or if you are not comfortable doing so please reach out to your People Business Partner. Avoid direct messagesNote: We don't use the term private message, because these direct messages are not inherently private like a phone call or private letter. The messages are potentially accessible by Workspace admins or via Backups. Slack refers to these types of messages as direct messages themselves. When using Slack for work-related purposes, please avoid direct messages. Direct messages discourage collaboration. You might actually be contacting the wrong person, and they cannot easily redirect you to the right person. If the person is unavailable at the moment, it is less efficient because other people cannot jump in and help. Use a public channel and mention the person or group you want to reach. This ensures it is easy for other people to chime in, involve other people if needed, and learn from whatever is discussed. If someone sends you a work-related direct message, it is okay to let them know you'd like to take the conversation to a public channel, linking to this section of the handbook. The process might look something like:
If you find yourself getting a lot of direct messages that should go in a public channel, consider changing your Slack status to an attention grabbing emoji and set it to something like:
If you must send a work-related direct message, don't start a conversation with "Hi" or "Hey" as that interrupts their work without communicating anything. If you have a quick question, just ask the question directly, and the person will respond asynchronously. If you truly need to have a synchronous communication, then start by asking for that explicitly, while mentioning the subject. e.g., "I'm having trouble understanding issue #x, can we talk about it quickly?". Do not use group direct messagesUse private channels instead of group direct messages. Group direct messages are very hard to maintain, track, and respond to. They also have a key limitation in that you can't add people to the conversation. This is a hindrance to collaboration and transparency. Consider whether the conversation can take place in a public channel. If not, please use a private channel instead. This channel may have a short-term purpose. It is acceptable to leave the channel and/or archive it if you are no longer an active participant or the channel is no longer in use. Why we track % of messages that are not DMsFor all the same reasons that we want to avoid direct messages, use public channels, and be handbook-first, we track the % of messages that are not DMs. As we grow headcount, we exponentially increase the lines of communication- 3 people have 3 communication lines, 4 have 6, and 41 have 820. As a result, there is a natural tendency for people to prefer private channels of communication. The intentions are good, as people are looking to reduce noise for others, but this can lead to the same problems as described elsewhere on this page, notably:
Slack is our primary source of chat communication and is where many personal interactions happen. We want to continue to encourage folks to build personal relationships with one another which will often happen over DMs. We know that DMs will always exist. We don't want to eliminate them. We set a target of Slack messages that are not DMs being at least 25% of messages. At the time that we set this target, it was <20% of communications. Everything at GitLab is a work in progress, so if we see a culture shift where Slack is not where work is occurring, thus inflating the amount of communication that is personal that is occurring, we can always change this KPI, but the steady growth of Slack messages paralleling the number of team members does not seem to suggest that is the case. The previous KPI (% of messages sent in public channels) was about public channels but since some necessary parts of the business occur in private channels (discussions around comp, hiring, talent acquisition- and we do A LOT of hiring), this version of the KPI makes more sense. Earlier in our history, 50% of all communication was in public channels. Note: Some of these charts require data from a sheetload file that needs to be manually updated. To self-serve data for a chart with missing data, please visit Slack's workspace administration page. It provides guidance on how to access Slack's analytics dashboard for a particular workspace. If this data is required in the charts below, you can ping the #data channel for a refresh. If this becomes a common request, we may choose for the manual step to become regularly scheduled. Use public channels
Be respectful of your own timeYou should try to avoid information overload in order to be productive and efficient with your time. While it can be tempting to read every message in every Slack channel you subscribe to, it’s very challenging, not expected, and not necessary. One method for avoiding Slack overload is to focus your Slack reading on Starred channels and Threads. Starred channels are like "favorites" and allow you to follow messages from those channels easily. Threads consist of any conversation in which you are mentioned and allow you to easily track conversations in which you have direct involvement. Use your notification settings liberally. Depending on how you use Slack this could range from limiting notifications to critical messages outside of your working hours to turning off Slack notifications entirely. Find the right balance for you and stick to it. Be respectful of others' timeStart by understanding what we mean by respecting time. We should err toward putting material into channels over DMs and public channels over private channels even though we understand that this will generate more messages that can be read by more people. Respecting time is not about reducing the overall volume of channel messages that team members receive. It's about making sure that messages are targeted, expectations for asynchronous responses are clear, and we are communicating with consideration. The following tips provide ways to work respectfully with others given this context:
Managing noise and creating focus in SlackSlack can be a disorderly place in its default state. Consider implementing the below to add structure and focus, but remember that there will likely be more useful information shared on Slack than you are able to ingest and process on a daily basis, regardless of your approach. While an intentional effort to organize is important, remember that it's impossible to know everything. As a team, we may spot information that is missed by others, and we should surface that information when pertinent as we strive to see others succeed. For managing Slack channels, consider blocking a set period of time to review certain channels that makes the most sense for you (i.e. multiple times a day, daily, weekly). Organizing your Slack sidebar by priorityConsider using Slack's Starred channel function to spotlight three categories of channels, its
Mute function to quiet channels which are pulling your focus away too often, and most importantly, its Mark all messages as read function (easily toggled by pressing An example of three spotlight channels approach is below. Slack allows you to organize your sidebar of starred channels with custom sections to visibly raise or lower their priority level, giving you control over what you see first.
Manage your Slack notificationsBelow are helpful links to best practices and tips on managing your notifications and reducing noise in Slack. We encourage you to regularly check your notification settings to ensure you get more notifications of what is important/relevant to you, and less of what isn't.
Set aside time to work through notificationsBuilding dedicated time into your day can help minimize the distractions that Slack can create. Consider using a 15 or 30 minute block in your morning or afternoon to enjoy a cup of coffee and catch up on messages you might have missed. When the time you set comes to an end, close out of the Slack app and move on to your next project. Having a set end time can help you feel more in control, and serves as a reminder that it's impossible to know everything General guidelines
Getting in touch with the e-groupTo get in touch with the e-group on Slack, you can use the following channels. When in doubt, you can use the general
Key Slack channelsThe alphabetically sorted starter list below spotlights a few of GitLab's many Slack channels in an effort to provide guidance to team members regarding the best places to ask specific questions and/or engage in discussion on a variety of topics. See Slack's Help Center for instructions on browsing all available channels. Learn more in our Chat handbook section.
QuestionsIf you have a question that you can’t find the answer to in our handbook (or you need help finding something in the handbook) team members across the company are here to help. If your question relates to one or more of the following topics, go directly to the subject matter experts/source in the designated slack channel to ensure your question is addressed. Are you a subject matter expert in your role or knowledgeable in a topic-specific channel on Slack? Add the topic and channel to the grid so team members know where to go if they have questions on that topic.
If your question doesn’t relate to any of the above topics:
SlackbotsWe have a few slackbots to help us with frequently asked questions and other slackbots that directly help us to remain inclusive in our language and align closely with our Diversity, Inclusion and Belonging Value. The following list is reflective of the ones we use for Diversity, Inclusion and Belonging and the suggested changes to use. This list is representative, not complete; terms will be added and removed as we iterate on the list. As a GitLab Team Member, you can view the active slackbots that we use in Slack, under: GitLab > Customize Your Workspace > Slackbot.
Yerbo Slack AppYerbo is a mental well-being tool that helps teams track burnout and monitor risk through science-based questions and take action to build a healthier work-life. The free version of the Yerbo Slack app is available for team members. To start using Yerbo as an individual, search for and click the app in Slack. For quesitons or to provide feedback, reach out in the #yerbo-app Slack channel. How the Yerbo app works1x per week, the app sends a message to users and asks them to complete a 2-minute self reflective survey. Answers are aggregated over time and display in a personal dashboard where team members can view their potential risk of burnout and take action to improve. Learn more about how the app works by watching this video. Below is a screenshot of the in-app dashboard view. Read more about how GitLab combats burnout, isolation, and anxiety in an all-remote workplace. Why are we upgraded to the Plus tier?We upgraded tiers to improve efficiency and security with the ability to use Okta to login into Slack. This will help us scale by improving provisioning and deprovisioning of our corporate systems. This upgrade will also allow us to improve the auditing requirements where identity management is in scope. The Plus tier also includes announcement only channels, 99.99% guaranteed up time, 24x7 support with guaranteed response in four hours or less, and the ability of Corporate Export. When would GitLab use Corporate Export?The times this feature would be used would be to comply with certain obligations. Corporate Export must be enabled by Slack in accordance with Slack’s policy, which can be found here. Examples of instances where GitLab may need to use this feature may include, but are not limited to, those situations listed in Slack’s documentation. Are my direct messages and private channel conversations completely private?No. The Slack Workspace Owner has the ability to export data from all direct messages and private channel conversations for the maximum retention period set by GitLab, which is currently set for 90-days. All messages that are older than 90-days cannot be exported by the Workspace Owner or any other Team Member at GitLab. While messages are not actively monitored, GitLab reserves the right to monitor its software for the reasons stated in its Employee Privacy Policy, including, but not limited to, the safety and protection of our Team Members, the protection of our intellectual property, and the exercise or defense of legal claims. Please keep GitLab values in mind when communicating directly with other team members. If you have a confidential personal issue that you do not feel comfortable discussing via a business-provided internal communications tool, it is recommended to use a personal form of communication such as a text message or phone call. For additional questions, please address in the issue. Need to add a new app to SlackGitLab has chosen to restrict the ability to install apps, and we have a process to approve or restrict certain apps for our workspace. In order to add a new app to Slack, you need to create a vendor approval issue. Once that's approved by all parties, please request approval to add the app to Slack:
Please note that this is only required for new apps that have not been reviewed or approved. If your request is to add a new process or update an existing process for how an application works in slack, please refer to our Business Technology Change Management process. Emergency chatSlack is downTo use the "Slack Down!" group chat on Zoom:
Once service is restored, go back to Slack. Zoom is downTo use Slack calls:
Once service is restored, go back to Zoom. Slack and Zoom are downJoin the Slack Down! room on Hangouts Chat. Once service is restored, go back to Slack and Zoom. Google DocsNever use a Google Doc / Presentations for something non-confidential that has to end up on the website or the handbook. Work on these edits via commits to a merge request. Then link to the merge request or diff to present the change to people. This prevents a duplication of effort and/or an out of date handbook. Pageless is the GitLab preferred formatGoogle Docs Pageless format is the preferred format for company documents that won't be printed. If a document is likely going to be printed (for example, a contract) the older paged style is acceptable. See Good practices and helpful tips for help navigating the pageless format. Link sharingIf you do need a Google Doc, create one with your company Google Workspace (formerly G Suite) account and set the visibility and access controls according to the following guidelines. The recommended defaults when sharing a document for GitLab internal purposes is setting visibility to On - GitLab and access to Can Edit to ensure everyone can contribute! Note: To our knowledge, it is not possible to set the default to Can Edit and you have to change the permissions from View manually. We hope that Google adds this capability in the future.
Reference Google's documentation on Link Sharing to learn more. Good practices & helpful tips
How to publish a Google Doc
How to deprecate a Google Doc
ZoomGitLab uses Zoom as the primary video collaboration platform for internal and external communications. Some of our customers and partners have different preferred tools and to facilitate the communication with those parties, GitLab provides licenses for WebEx and MS Teams. This service is only provided to team members that have a business need to host meetings and where Zoom is not accepted. It is not efficient for GitLab to use multiple video conferencing tools, however we encourage the use of the most popular ones among our customers and partners when needed. E.g.; Zoom, WebEx, MS Teams, Skype, etc. To request access to those tools, create an access request and provide a justification for access. Usage guidelinesPlease visit the Tools and Tips handbook for Zoom usage guidelines. Using Zoom for personal connectionCOVID-19 is impacting how team members connect and communicate with family. Due to school closures, parents are tasked with being responsible for their children while at home. Family and friends first, work second is an important Diversity, Inclusion & Belonging operating principle. To that end, we are encouraging GitLab team members to allow their children to connect with other children around the world. During this time of physical distancing, GitLab team members are welcome to use Zoom to connect with family if other options like FaceTime, etc. are not an option. Please ensure that attendees who are not GitLab team members have their own Zoom account. To ensure GitLab does not incur toll charges, please use Internet-based voice when possible. Zoom webinarsPlease visit a detailed guide covering everything you need to know about hosting or participating in a GitLab webinar. Google CalendarWe recommend you set your Google Calendar access permissions to 'Make available for GitLab - See all event details'. Consider marking the following appointments as 'Private':
There are several benefits and reasons to sharing your calendar with everyone at GitLab:
If you add blocks of time spent on recurring tasks to your Google Calendar to remind yourself to do things (e.g. "Check Google Analytics"), consider marking yourself "Free" for those events so that coworkers know they may schedule a meeting during that time if they can't find another convenient time. Posting or streaming to YouTubeSee the YouTube page for options and instructions for posting recordings and live streaming to our YouTube channels. GitLab Communication knowledge assessmentAnyone can test their knowledge on GitLab Communication. To obtain a certificate, you will need to
complete this knowledge assessment and earn at least an 80%. Once the quiz has been passed, you will receive an email with your certificate that you can share on your personal LinkedIn or Twitter pages. If you have questions, please reach out to our L&D team at Daily Sync Escalation ProcessGitLab has a specific process to follow in crisis situations to ensure effective communications. Details can be found in the internal handbook. Avoid using Git in Project NamesAvoid using Git in the naming of internal and external company related programs (BagGit, GitFit, Gitty, GitIt, etc.). Referencing Git creates an inaccurate perception that GitLab has a narrow focus. While GitLab started as a source control platform, it has become The DevOps Platform. When handling an incoming telephone call regarding a patient progress report you should?Chapter 13. When answering a phone call in the medical office the medical assistant should?Answering the telephone in a professional manner involves answering within two to three rings, so the caller is not left waiting. If taking multiple calls, proper etiquette suggests that you give the first caller priority unless the second caller has an emergency.
Which of the following guidelines should you follow when placing an outgoing telephone call?What should you do before placing an outgoing telephone call to a patient.. verify correct phone number.. allow enough time for someone to answer.. ask if you have called at a convenient time.. What is the best response to a patient who calls to ask if he or she can use a medication that was prescribed for a previous condition multiple choice?CHAPTER 14. |