The mission of GitLab’s Corporate Communications team is to amplify GitLab's product, people and partnerships in the media, via social media channels and through award wins. This team is responsible for global public relations (PR), social media, executive communications (speaking) and internal communications. Corporate Communications Job families can be found here.
This page is the single source of truth for corporate communications objectives/goals, contact information, messaging, PR/social media guidelines, approval processes, strategy and more.
The GitLab Corporate Communications team is responsibility for the following activities and communications channels:
As detailed in GitLab’s public CMO OKRs, GitLab’s corporate communications team seeks to elevate the profile of GitLab in the media and on social media, positioning it as a pioneer of remote work, increasing share of voice against competitors, and pulling through key narratives in feature articles.
The Corporate Communications team measures results using the following north star metrics:
Media and Awards:
Please visit our Get In Touch page for contact details.
Please use the
#external-comms Slack channel and please follow the Communication Activation Tree.
To mitigate a potential incident and/or if an incident has occurred, please follow the incident communications plan.
Speaking on behalf of GitLab via a public channel such as a media interview (in-person or via phone), on a podcast, in a public issue on GitLab.com, on a forum, at a conference/event (live or virtual), in a blog or an external platform is a significant responsibility.
As of September 13, 2021, all GitLab team members who speak with the media are required to first complete the GitLab Media Training and all GitLab team members who speak externally at a conference or event are required to first complete the GitLab Speaker Training. Both of these trainings have been designed to keep us aligned in representing the company following GitLab’s SAFE framework. Being mindful of how you say things within open issues, on social media, or at a booth during an event will help keep the company SAFE. We all represent the company.
If you are unsure whether or not you should accept a speaking opportunity, create a public issue to gather feedback/communicate a message, or provide comments representing GitLab please see below for guidance.
Being a designated company spokesperson on topics ranging from Company background to Remote Work to DIB to technical topics like CI/CD or security practices is a responsibility that should be taken with the utmost seriousness. While each team member represents the company and GitLab’s mission is to ensure "everyone can contribute," it is important to hone our list of designated company spokespeople. Spokespeople are SMEs, seasoned in their role (minimum 6 months at the company) and positioned to be at the company for a while for consistency (exceptions may apply).
Watching the above training courses are very important to ensure we are consistent with company narratives and messaging and key points are effectively delivered publicly.
If you are new to being a spokesperson for GitLab, the Corporate Communications team may ask you for video examples of past speaking engagements (events, webinars, tutorials, etc.) to assess the level of speaking comfortability. If you are new to speaking externally and/or do not have a video asset, the team may conduct a 15 minute practice interview to quickly assess if you meet the above criteria.
Media coverage is common and expected for growing companies. GitLab's transparent nature has led to some positive media coverage and community engagement on social channels and forums; however, it has at times resulted in negative criticism of the company — both valid and invalid. This is common and is expected to continue as the company continues to mature. To stay up-to-date on media coverage, flag any articles or podcasts you see or ask questions, please post in the
#newswire Slack channel.
Due to GitLab's unique company transparency and mission that everyone can contribute, team members may be approached by reporters, podcasts hosts, etc. to comment on the company and/or conduct interviews. If you are asked to be quoted or to provide commentary on any matter as a spokesperson of GitLab, please provide detail of the opportunity to the Corporate Communications team in the
#external-comms Slack channel before engaging. The Corporate Communications team may ask you to open an issue for further evaluation and engagement for the opportunity.
In the event that a media member, editor, or publisher offers a draft or preview of an article where you are quoted, please allow the Corporate Communications team 5 business days to review by posting in the
#external-comms Slack channel. The Corporate Communications team will ensure that the appropriate GitLab team member(s) review and approve in a timely manner.
Invited to Speak
If you are asked to speak on behalf of GitLab at an event, on a webinar or at a Meetup (and you are not already a member of the GitLab speakers bureau), please reach out to the Corporate Communications and Developer Evangelist teams to ensure that the opportunity aligns with GitLab objectives and key narratives. Inquiries should be initiated in the
#external-comms Slack channel before you accept the speaking invitation. Please allow 5 business days for evaluation. Opening an issue under Corporate Marketing to further collaborate on the opportunity may be requested.
Submitting to Speak
If you are planning to submit an event CFP or request to participate as a speaker for a webinar or Meetup (and you are not already a member of the GitLab speakers bureau), please ensure the opportunity aligns with GitLab objectives and key narratives. If you are unsure, please reach out to the Corporate Communications and Developer Evangelist teams. If accepted to speak, please take the training “Best practices for public speaking,” notify the Corporate Communications and Developer Evangelist teams via the
#cfp Slack channel w/link to the accompanying issue and ensure the teams have 7-10 business days to review your final presentations.
Executive Speaking Request
If you have an opportunity (webinar, fireside chat, conference, Meetup, etc.) that you would like to invite an e-group member to speak at, please create a GitLab issue within the Corporate Marketing group that includes the following: business case for e-group member, explanation as to why the topic is a perfect fit for the speaker (ex. something they personally worked on or company designated spokesperson for topic, etc.), extensive details regarding what they will need to speak on and full logistical details; including timing. Please plan 90 days minimum from time of open issue to time of speaking opportunity for preparation. Once the issue is created, please post in
#external-comms Slack channel for further assistance. Please allow the Corporate Communications team 5 business days to review your request.
Amplifying your Speaking Opportunity
When speaking at an event, on a webinar or at a Meetup, if you are open to being a spokesperson with media or creating a contributed article on your talk, reach out to the Corporate Communications team via the
#external-comms Slack channel.
For ways to amplify your speaking opportunity, check out the “How to make your content work harder for you” presentation.
Event Booth Staffing If you are staffing the GitLab booth at an in-person or virtual event, you are representing GitLab. Please follow the company’s SAFE framework when engaging with booth visitors and event attendees.
For analyst research-oriented requests, please consult the Analyst Relations handbook section and direct questions to the
#analyst-relations Slack channel.
For media inquiries that are more research oriented, please share the request and associated context in the
#external-comms Slack channel. An example of a research-oriented request is an invitation to participate in an interview to share more about one's day-to-day role at GitLab, specific tools teams use on a daily basis, how a team interacts and collaborates with other teams, specific products that are most helpful to them in their workflow, etc. The Corporate Communications team will evaluate for reach, awareness, merit, and potential conflicts of interest, and advise on a case-by-case basis.
Honorariums If the request has an honorarium offered (for example, a gift card or cash amount awarded for participation), please go through our Approvals for Outside Projects & Activities process to ensure a conflict of interest is not present.
You may be approached by external parties seeking to provide payment for a GitLab team member's time to discuss GitLab remote practice to help them guide a client. While this is not a traditional research or speaking opportunity (i.e. event or Meetup) it is still considered an external speaking opportunity. We ask that team members verify who they are speaking with to make sure the source is indeed valid and the request legitimate. Remember that you represent GitLab and if any question makes you uncomfortable or gives you a pause on whether you should answer, we recommend that you do not answer. Questions regarding GitLab financials, sales, compliance, executives or where the company is heading should adhere to the SAFE framework and be treated with caution, as should anything which is not already available in the GitLab handbook. We encourage all team members to be company evangelists and this can be done without sharing Not Public information about GitLab.
Please consult the Social Marketing Handbook for guidelines on how to represent GitLab on your personal social media platforms. If you are contacted on a social media platform and asked to share/retweet or provide commentary as a spokesperson of GitLab, feel welcome to provide detail of the opportunity to the social team in the
#social-media Slack channel.
You are welcome to write about your experience as a GitLab team member on your personal blog or for other publications and you do not need permission to do so, as long as you follow the company’s SAFE framework. If you would like someone to check your draft before submitting it, you can share it with the Corporate Communications team who will be happy to review. Please post it in the
#external-comms Slack channel with a short summary and allow 5 business days for review.
Posting in and discussions occurring within a public GitLab issue should follow the same guidelines as if you were posting about GitLab on social media, engaging with community members in a forum or conducting an interview with a media outlet. You are externally representing and communicating on behalf of GitLab.
When representing and/or communicating externally on behalf of GitLab, please follow the SAFE framework. Being mindful of how you say things within open issues will help keep the company SAFE. We all represent the company.
GitLab's Corporate Communications (PR/Social Media) team is the DRI (directly responsible individual) for the GitLab Master Messaging Document, Guide on Speaking About Remote work at GitLab and company Fact Sheet. These documents are regularly kept up-to-date and should be the single source of truth for all company information used for media interviews and award submissions.
GitLab's Corporate Communications and Product Marketing teams are the DRI (directly responsible individual) for the GitLab Master Company Deck. This deck is regularly kept up-to-date and should be the single source of truth for all company information used for external speaking presentations and engagements.
The communications team develops training and certifications for GitLab team members to build up their practices when representing the company with the media, at an event, or on social media. Visit our training page and consider taking a communications training to learn more about:
This process allows us to determine the best channel to communicate different types of updates and news to our users, customers, and community.
Please follow the instructions below to request a formalized announcement around any of the following:
Please submit a request via an
announcement issue template in the Corporate Marketing project before opening an issue for a blog post, for example. In the issue template, you will be able to provide additional information on the proposed announcement. As a general guide, below the team has outlined three levels for announcements based on the type of announcements and suggested communications activities associated with each tier. The Corporate Communications team will assess your request in the issue and determine how to proceed. If you are requesting a joint announcement and you are not part of the Partner Marketing team, please ensure you ping them on your issue.
If a channel or alliances partner has requested support of their press release with a quote from GitLab, please see complete a partner announcement issue template which includes details on the review and approval process as well as links to press release templates.
Guidelines and Approval Process
If you receive a vendor request for GitLab to act as a reference (case study, blog post, press release, GitLab logo on their website, etc.) for the product, service, and/or technology that your GitLab team is using, please refer to the below guidelines to see if the request meets the criteria for you to move through the approval process and notify the corporate communications (corp comms) team of the request.
Vendor Reference Criteria
Please ensure that the vendor meets the below criteria before proceeding with the approval process. If you have any questions on the below criteria or need clarification please reach out to Corp Comms via the #external-comms channel on Slack.
If the vendor has met the above criteria, please submit an issue in the Corporate Marketing project including the following information for review. Please title the issue
Vendor Reference Request: XYZ Company. Once the request has been submitted to the corp comms team, please allow for 7-10 days for review and approval of the request. The corp comms team will review all content and relevant info to ensure it follows the SAFE framework and route through the approval process.
Give more details on the vendor reference request:
GitLab's corporate communications team is the DRI (directly responsible individual) for writing all press releases that are issued by the company and routing through the appropriate approval process. The team has developed an issue template to help make the press release development and approval process more streamlined and consistent. If you have any questions on the press release process or how to make an announcement request, please reach out via the
#external-comms Slack channel or submit an
announcement issue template in the Corporate Marketing project (see Requests for Announcements section above).
If you would like to use a GitLab public issue to communicate an update to customers/users or gather feedback from customers/users, please complete the
announcement issue template with the details of the specific request and draft of the issue announcement copy. The Corporate Communications team will review the request details and issue copy, as well as recommend other relevant teams (product, product marketing, legal, etc) to loop in for review before posting the public issue.
In some cases, it may be more appropriate and efficient to communicate with users in a public issue. Below are some examples of the types of communications that may suit an issue as opposed to a blog post, press release, or email, for example:
Using a public issue has a few advantages:
Below are some examples of using an issue to communicate something with GitLab's audience. Feel free to use these examples as a template for your issue.
At a minimum, your issue should:
user communicationlabel applied.
We can spread the word about a public issue in the same way that we would promote a blog post or press release:
We can promote other items this way as well: for example surveys, landing pages, or handbook pages.
GitLab team members will find embargo and announcement guidelines in a confidential issue (must be logged in to access).
This answers the following questions.
pressand click on the
--- layout: markdown_page title: "Title of press release" description: "short sentence overview of press release' twitter_image: "/location/of/image.png" twitter_creator: "@gitlab" twitter_site: "@gitlab" twitter_image_alt: "Celebrating GitLab's press release about xx with fun emojis" ---
twitter_image_alt would be the three, net-new tags needed to be custom to every single release.
twitter_site would be static with the value "@gitlab".
twitter_image:section above and to merge the release. If the team has previously discussed the work, the social team may have already created a sharing image. If not, they will need to create it from this mention. The social team will add the data necessary to the MR for social sharing and merge the press release.
When you have added a press release, be sure to update the index page too so that it is linked to from /press/#press-releases.
datathen to the
press_releases:, then scroll to the most recent dated press release.
Recent Newssection with the most recent listed at the top. Display 10 articles at a time. To avoid formatting mistakes, copy and paste a previous entry on the page, and edit with the details of the new coverage. You may need to search online for a thumbnail to upload to
images/press, if coverage from that publication is not already listed on the page. If you upload a new image, make sure to change the path listed next to