Gitlab hero border pattern left svg Gitlab hero border pattern right svg


Welcome to the GitLab Marketing Handbook

The GitLab Marketing team includes multiple functional groups: Sales Development, Community Relations, Corporate Marketing, Content Marketing, Marketing Operations, Product Marketing and Digital Marketing Programs.

On this page

Marketing Handbooks

GitLab Marketing Purpose

We GitLab

GitLab's ambitious vision is to become best-in-class in every DevOps software category, from project planning and source code management to CI/CD, monitoring, and security so that organizations can break free from complex DevOps toolchains. The GitLab Marketing team is here to:

Data informed decisions

One of the ways marketing (except for community relations) measures its effectiveness is to seek to optimize pipe-to-spend. We measure the pipeline created that can be attributed to a certain campaign. Most campaigns will be linked to a group (field marketing, content marketing, etc.). The spend will include the direct spend (advertising) and the indirect spend (team members time). While pipe-to-spend is not perfect, we are currently using full-path attribution.

Integrated Campaigns

The Marketing department's effort is organized into Integrated Campaigns. An Integrated Campaign is a communication effort that includes several campaign tactics such as blog posts, emails, events, advertisements, content on, videos, case studies, whitepapers, surveys, social outreach, and webcasts. An Integrated Campaign will have a campaign theme that summarizes the message we are communicating to our market.

We track Integrated Campaign results in Salesforce and costs associated with Integrated Campaigns in Netsuite. In Salesforce, Integrated Campaigns are tracked as parent campaigns and campaign tactics are tracked as campaigns. A campaign tactic will have a Type and Type Detail to identify the category of effort for the purpose of identifying what types of marketing investment are most efficient in terms of the ratio between customer acquisition cost (CAC) and customer lifetime value (LTV).

Active integrated campaigns

Just Commit

🎯 Target personas

Level: VP, Director, Lead, Head
Function: Applications, Development

🔑 Key Messages - 3 Pillars
P1: Modern application architecture



P2: Reduce cycle time



P3: Secure apps




Competitive campaign


Different marketing teams handle different aspects of Integrated Campaigns. Which team are you looking for? Here's what each does.

Marketing Project Management Guidelines

Marketing uses GitLab for agile project management including groups, projects, epics, roadmaps, issues, labels, and boards. Read through the documentation on each of these GitLab features if you are unfamilar.

Groups and projects

  1. The Marketing General Group houses all marketing projects.
  2. Labels should exist at the group level so they can be used across projects.
  3. The following are the approved marketing projects, CMO approval is needed to begin a new project.
  4. Issues should only be logged in team project (i.e. do no use marketing/general)
  5. Don't create groups with subgroups (use labels to segment workstreams within a team's project issue tracker.)

Issues, Milestones, and Epics

  1. Each issue represents a discrete unit of work with a deliverable. For example 1 2 3
  2. Every MR should have an issue so that it can be tracked on issue boards.
  3. Milestones represent units of work to be completed within a specific time frame, sometimes referred to as sprints. They are comprised of multiple issues that share a common due date, and help break large projects into more managable parts.
  4. Epics represent projects that comprise multiple issues. (Don't use "meta" issues for this purpose. If you have have existing meta issue you can promote them to epics using the /promote slack command.)
    • Epics live at the group level (e.g. issue from multiple marketing projects can be added to an epic.)
    • Epics are labeled with a group label of the team that owns the epic.
  5. The top 3-5 strategic initatives are tracked in epics using the CMO label. (Don't apply the CMO label to other epics.)
  6. Roadmaps are used for time-based display of epics with a start and end date. (for example, events and time-based campaigns.)

Boards and Labels

  1. Each team has one or more boards to track ongoing workstreams.
  2. Generally, create a board for each function. (For example PMM has boards for Sales Enablement, Analyst Relations, Customer Relations, etc.)
  3. Each board uses a standard set of columns/labels so that folks can easily understand what is happening on another teams board.
  4. The board labels use group labels with status: and one of four statuses. Status labels are used on both issues and MRs:
    • Optional*:Status:Plan - work that is proposed, in an exploratory state. To exit the plan stage the work must be assigned to a DRI. The DRI accepts responsiblity for the task by changing the label from Status:Plan to Status:WIP and creating an MR if appropriate. The plan status is optional, as issues that don't require formal planning can be opened and labeled Status:WIP.
    • Status:WIP - work in progress that has been accepted and assigned to a DRI. Work in this stage should not be merged. Issues and MRs should be prepended with WIP:. At GitLab we allow reviewers to start reviewing right away before work is complete. Use MVCs: At any time, if the work is complete enough that merging would be better than what current exist the issue should be labeled with status:review and WIP: should be removed from the title.
    • Optional*: Status:Review - work has been completed enough that it is ready for formal review and approval. Work that is approved can be either merged or scheduled. The review status is optional. Work that doesn't require review can simply be merged/closed.
    • Optional: Status:Scheduled - work that is complete but should be scheduled for a future date. The scheduled status is optional as not all work will need to be scheduled.
    • closed - when work is delivered the issue should be closed.
  5. Don't duplicate status labels at the project level. Use group labels (at the Marketing Group level) as much as possible.

Marketing Rapid Response Process


There are times when a rapid response is needed to address M&A in the industry, competitive moves and other opportunities to newsjack. In order to effectively respond, GitLab marketing needs to monitor, create and publish quickly. Additionally, GitLab marketing needs to support GitLab executives with content, data and soundbytes for interviews, blog-posts, etc.


If a rapid response opportunity arises, please alert the head of corporate marketing (or CMO if head of corporate marketing is unavailable) via slack or text message who will then post a message with an @here alert in the #rapid_response public Slack channel (and tag CEO). The head of corporate marketing will propose a recommendation on how to best proceed with an external company message and recruit the resources to accomplish the plan (this becomes the #1 priority for each resource, unless physically impossible or their manager provides a replacement). A template for a rapid response can be found here

The head of corporate marketing will assess the rapid response request within 1 HOUR (9amEST-6pmPST). Urgency will be assessed and will be determined to be 3 HOURS (ASAP) or 24 HOURS turnaround, and the action plan will be scoped accordingly - with a bias towards releasing an MVC as soon as possible, and iterating as more news becomes available. Any disagreements on urgency or action will be escalated immediately to the CMO for a final decision.

While each response will be a custom plan, the rapid response team will leverage appropriate resources to execute on the agreed upon plan. PMM/TMMs should be responsible for technical and product content and industry expertise and context, Content/Social will be responsible for writing and publishing, Web will be responsible for any non-blog web page changes needed, and Community will be responsible for monitoring and responding in public channels.

Marketing Team Functional Groups

Sales Development

Business Development Representatives (BDRs) focus on serving the needs of prospective customers' during the beginning of their buying process. When prospective customers have questions about GitLab, the BDRs assist them or connect them to a technical team member as needed. During the initial exploration if the prospective customer is interested in continuing their exploration of GitLab, BDRs will connect them to an Account Executive (AE) or Strategic Account Leader (SAL).

Sales Development Representatives (SDRs) contact people who work at large organizations to uncover or create early stage sales opportunities for GitLab SALs. Account researchers arm the SDR team with insights about the accounts they are prospecting into including contact discovery, understanding enterprise-wide initiatives that GitLab could assist with, and ensuring accurate data quality of accounts and contact in

Position Description Handbook

Field Marketing

Field marketers focus on understanding the specific needs of the geographic regions where GitLab operates. They manage marketing activities, such as events and sponsorships, tailored to the needs of the region where the activity takes place.

Position Description Handbook

Marketing Operations

Marketing operations focuses on enabling the GitLab marketing organization with marketing technology, process, enablement and insights. They are responsible for evaluating, deploying and administering marketing systems, documenting and improving administrative processes, and analyzing our marketing data to ensure marketers are held accountable to continuously improving their work. Marketing Operations owns the tech stack used by Marketing.

Position Description Handbook

Corporate Marketing

Corporate Marketing is responsible for PR/communications, the stewardship of the GitLab brand, corporate events and the company-level messaging/positioning. The team is the owner of and oversees the website strategy. Corporate Marketing creates global marketing materials and communications and supports the field marketing teams so they can execute regionally while staying true to the GitLab brand.


Content Marketing

Content marketers focus on understanding our audience of developers, IT ops practitioners, and IT leadership. They create useful content for GitLab's audiences, and ensure that the content is delivered to the right audience, at the right time, and in the right way.

Position Description Handbook

Digital Marketing Programs

Digital Marketing Programs focuses on executing integrated campaigns, with a digital-first mindset. They are responsible for executing, deploying, and tracking emails and supporting both sales and marketing in outbound mass communications.

Digital Marketing Programs includes online marketing, focused on managing online advertising, website experiments, and search engine optimization (SEO). Online advertising is aimed at increasing the volume of relevant traffic to GitLab's marketing site, website experiments are focused on improving web traffic-to-form submission conversion, and SEO is aimed at ensuring our marketing site ranks for the search engine keywords our audiences care about.

Position Description Handbook

Community Relations

Community Relations includes community advocacy, code contributor program and evangelist program functions. The team is focused on answering the following questions:


Product Marketing

Product marketing is GitLab's interface to the market. The market is made up of customers, analysts, press, thought leaders, competitors, etc. Product marketing enables other GitLab groups such as Sales, Marketing, and Channel with narrative, positioning, messaging, and go-to-market strategy to go outbound to the market. Product marketing does market research to gather customer knowledge, analyst views, market landscapes, and competitor intelligence providing marketing insights inbound to the rest of GitLab.


Marketing Production

Meetings and structure

These are just the required meetings for team members and managers. Of course, meetings are encouraged when it expedites a project or problem solving among members, so the team and company. Don't be afraid to say "Hey, can we hangout?" if you need help with something.

Weekly 1:1 (New hire: First month - managers with all direct reports)

Meeting goal: For manager to help new team member onboard quickly.

Run time: 30 minutes

All managers should have a weekly 1:1 with their direct reports in the first month of employment, starting with the first day of employment where possible.

The first meeting should run as follows:

The agenda of the following 1:1s should be the same as the recurring Bi-weekly 1:1s with time set aside to answer any questions about onboarding.

From the second month on, all managers should have twice monthly (bi-weekly) meetings with all of his or her direct reports.

Weekly 1:1 (All Directors with CMO)

Meeting goal: For CMO to provide direction, help prioritize and receive feedback from all Directors.

Run time: 30 minutes

All directors should have weekly meetings with the CMO.

The meeting should run as follows:

Weekly 1:1 (Managers with all direct reports)

Meeting goal: For manager to remove roadblocks and help prioritize so team member can be effective.

Run time: 30 minutes

All managers should have weekly 1:1 meetings with all of his or her direct reports.

The meeting should run as follows:

Bi-weekly Marketing Function Call (All Marketing team members)

Meeting goal: Provide visibility and alignment across the Marketing team and provide forum for cross-functional discussion and Q&A.

Run time: 60 minutes

The Marketing team meets bi-weekly to review announcements, strategy developments, company updates; per functional area, review metrics, prior period accomplishments and blockers, review upcoming key activities; and have a forum for roundtable discussion and Q&A.

The meeting should run as follows:

Quarterly 1:1 (All members of Marketing Team with CMO)

Meeting goal: For CMO to help with any questions and career path discussion.

Run time: 30 minutes

All members of the marketing team who are not direct reports should meet with their executive management (CMO) once every quarter. If questions or concerns arise, please don't hesitate to reach out directly for an impromptu discussion via chat, email or phone call.

The meeting should run as follows:

Quarterly Marketing Planning Meeting (Marketing Leadership Team - CMO + Directors)

Meeting goal: Planning for the upcoming quarter

Run time: Two Half Day sessions

CMO builds agenda and assigns ownership for each section.

The meeting should run as follows:

Marketing team SLAs (Service Level Agreements)

When working remotely in a fast-paced organization, it is important for a team to agree on a few basic service level agreements on how we would like to work together. With any of these, things can come up that make it not possible to meet the SLAs, but we all agree to use best effort when possible.

Marketing Handbook Updates

Anything that is a process in marketing should be documented in the Marketing Handbook.

How to contact marketing

Requests from other teams

Social (@GitLab only, @GitLabstatus is managed by Infrastructure)

Everyone posts their own social updates, to the extent possible. If you want to request that something in one of these categories be posted, reach out to the point person below. They reserve the right to say no to your request, and copy in all of these categories may be adjusted by a marketing team member to ensure consistency in our brand voice.

Blog post editing


Marketing Newsletter

Marketing sends out a bi-weekly newsletter to our newsletter subscribers on the 10th and 25th of each month.

To add a content suggestion please find the Newsletter issue in the Marketing project and add your suggestion(s) as comment(s) to the issue in the format outlined on the issue description ( See example ). The title of the Newsletter issue will be formatted as follows: Newsletter MM/DD.

Content suggestions can be submitted up to 5 business days before the send date to ensure there is enough time for Content and Marketing Programs Manager's (MPM) review and set up workflow.

Anyone in the company can add suggestions, but the Marketing Program Manager in charge of the newsletter program ( see division of MPM duties ) will determine the final content of the newsletter. As a rule, we try to have a good balance of content, with a variety of blog posts, webcast landing pages, and product/company updates. The newsletter on the 25th will always lead with the release post for that month.

Other Newsletter

To request a newsletter to be sent to an audience outside the newsletter subscribers , please create an issue in the Marketing project, using the newsletter issue template.

Newsletter requests should be submitted no less than 5 business days before the intended send date to ensure there is enough time for Content and Marketing Programs Manager's (MPM) review and set up workflow.


We are happy to sponsor events and meet-ups where a marketing benefit exists, subject to approval by Field Marketing Managers. These sponsorships may be in cash or in kind, depending on individual circumstances.

Organizational or project sponsorships may also be considered where a marketing benefit exists. Typically, these sponsorships will be in kind - e.g., developer time commitments, or subsidized / free GitLab licenses.

Cash sponsorship of projects or organizations may be considered only in exceptional cases - for example, if a project or organization that GitLab depends on is struggling to survive financially.

New Ideas for Marketing Campaigns or Events

Note: The Marketing Team owns content on marketing pages; do not change content or design of these pages without consulting the Manager, Digital Marketing Programs. Marketing will request help from product/UX when we need it, and work with them to ensure the timeline is reasonable.

Chat Marketing channels

We use our chat internally as a communication tool. The Marketing channels are as follows:

Marketing email alias list