The social marketing team is responsible for the stewardship of the GitLab brand social channels. We’re accountable for the organic editorial calendar and work with partners across the community relations, digital marketing, talent brand, and other teams to orchestrate the social media landscape for GitLab.
Organic social media has a very particular way of succeeding. It's critical for the social team to lead the purpose and the OKRs that are focused on in order to align with best practices. While organic social media at GitLab may, at times, take requests from different teams with different objectives, it's important to remember that:
| Channels under the care of the social team |
|---|
| GitLab Brand Twitter |
| GitLab Brand LinkedIn |
| GitLab Brand Facebook |
| GitLab Brand Instagram |
| GitLab Brand GIPHY Channel |
GitLab Branded Social Channels include our company Twitter, LinkedIn, and Facebook which are managed in a more traditional manner. A potential Instagram channel will take more of an editorial look at remote life and work at GitLab, this is currently on hold. A little less “marketing-y” and more about building community. Our GIPHY account is mainly for new GIF content, which can be tied to larger initiatives. And lastly, our YouTube channel is a testament to the core of GitLab where everyone can contribute.
The social media team will often create our own content and campaigns for the sake of having fun and meeting our own objectives. This is also a critical part of a successful content strategy. If our social-first content is to align with a larger topic or talking point from GitLab, we will be sure to run our messaging by the DRI on the correct team.
While we're public by default, there will always be strategies and details that will need to be confidential to the teams working together. These grey area details are often moved to confidential status on a subjective basis and for the security and protection of the greater community, partners or other 3rd-parties, and for disclosure reasons. For these reasons, the links below are to confidential issues or epics, which we'll use to retain information and act as confidential handbook pages when needed.
Because the wider developer community utilizes Twitter as a platform to celebrate contributions, make feature suggestions, and share industry ideas, GitLab prioritizes this channel. We post to this platform first, and also more frequently.
On Twitter our GitLab community is our first priority. It includes those who contribute to our open DevOps platform, our GitLab Heroes, and folks who evangelize the industry. We take time to listen to their feedback, even when it is critical. We make space for fun. Through inside jokes, polls, or simple questions, our Twitter channel provides developers an opportunity to take a break and relate to one another. GitLab’s Twitter community is unique because we focus on engaging with their opinions. And delivering them tailored content they will actually find useful, or inspiring.
The GitLab Brand Twitter channel is establishing a sense of community through these activities:
How often GitLab should post depends on the platform and kind of content we are sharing. That said, Twitter does not operate like our other GitLab Social branded Channels. There are no strict frequency limitations on Twitter and we aim to post at least 3 times a day if not more. Content shared should prioritize the blog, releases, the hackathon, culture, the handbook, and All Remote content. These specific pages make up the majority of traffic driven from Twitter posts shared between October 2019-March 2020.
GitLab has a smaller audience on Facebook](https://www.facebook.com/gitlab) so its priority does fall below Twitter and LinkedIn. It is still important to maintain our presence. That's why we aim to post to this platform no more than 2 posts per day (if that). GitLab should prioritize posts around All Remote, third party content, and our culture (or Life at GitLab). We do have an obligation to always post important announcements, releases, and specific campaigns or events.
From the United States to India, our Facebook audience is a global one. Although our Facebook audience does see 15% of its fan base from the United States. And 51% of fans between the ages of 25-34 are the leading force of followers. Through the power of organic reach, our content has a high potential to also reach users between the ages of 45-54.
Facebook does not have the capability of breaking demographics down by title, however our particular audience participates in the following conversations: security, code, remote, CI, cloud, and CD.
How often GitLab should post depends on the platform and kind of content we are sharing. That said, Facebook does not operate like our other GitLab Social branded Channels. It is utilized less frequently and should prioritize culture culture, handbook, jobs, homepage, and All Remote content. These specific pages make up the majority of traffic driven from Facebook posts shared between October 2019-March 2020.
Our company page on LinkedIn shares a variety of content including third party mentions, releases, our blog, company culture, major integrated marketing campaigns, events (must include geotargeting if applicable), and All Remote content. The repost feature of LinkedIn is then used to broadcast company mentions (Example: partner tags GitLab in their post-we broadcast that to our page). Ultimately we use LinkedIn as an opportunity to expand in more detail on the content that we care about. How do we do that? By using a variety of formatted posts with more text, bullets, emojis, questions, quotes, and/or even stats.
From San Francisco to India and in between, our LinkedIn audience views our company page from across the world. Our visitors fall primarily under senior (43.23%) and entry level (30.03%). GitLab’s LinkedIn audience is also lacking the CXO, Owner, VP, Manager and Director level followers. So we are able to make the assumption that it is GitLab end users who follow us on LinkedIn. The following industries make up this audience: IT + Services, Computer Software, Telecommunications, Financial Services, Higher Education, and Program Development.
How often GitLab should post depends on the platform and kind of content we are sharing. That said, LinkedIn does not operate like Twitter and follows a 2-3 posts per day limit with the exception of timely announcements that must take place. Content shared should prioritize the home page, culture, the blog, hackathons and Heroes, Remote Work content, and the handbook. These specific pages make up the majority of traffic driven from LinkedIn posts shared between October 2019-March 2020.
In no way shape or form would our Instagram account mirror our other GitLab Branded Social Channels. In fact, it will take more of an editorial look, will be a little less “marketing-y” and be more about building community. We're rallying around a number of general topics. It does include remote work (All Remote), but more deeply about "Life at GitLab" (talent brand) and stories around living our values. For remote specific content we will try and steer clear of remote working stereotypes as a dominant theme. The data and Remote Work Report says that reasons and lifestyles for remote are different for everyone - so really, that's the remote story we want to tell.
Instagram will help the Social Media team tell big stories with small moments. For example, corporate produced events like Commit can use Instagram to provide live experiences and video content.
This is essentially being treated as a net new social channel since it had never been posted to. There is no current data available on our audience. However, we intend for our Instagram content to be consumed by gitlabbers, prospective team members, gitlab.com users, and those interested in remote work. The GitLab Instagram is targeting the #LifeAtGitLab, #AllRemote, #RemoteLife, #OpenSource, #DevOps, and #FutureOfWork conversations.
How often GitLab should post depends on the platform and kind of content we are sharing. That said, the Instagram Story feature will not have a frequency limitation and should be utilized as often as content is available. However, we will not over post Instagram wall posts. Instagram is a visual platform where GitLab can showcase the human side of our company and our brand. Each wall post on the GitLab Instagram account should tell its own story- and be a stand alone post. At initial launch, we will aim to post once a month as we gear up content to post 1X per week or biweekly
GitLab has a Medium publication, and all GitLab team-members may be added as writers! To be added as a writer to the publication, import a blog post that you authored on about.gitlab.com/blog to your personal Medium account, and submit it to the GitLab publication (by hitting edit -> submit to publication -> GitLab Magazine). the Social Marketing Manager will approve you as a writer and help finalize the post before publishing.
If you submit original content (i.e., not originally published somewhere else) to the publication for review, she may edit and publish your post. We want to highlight writers wherever possible, so we highly encourage you to import posts to your personal Medium.
Content/Execution
Content/Execution
While we look to the design team to provide integrated campaign assets and elements to use on social, many rapid design needs are fulfilled from the social team directly by Using Canva Pro. Canva Pro provides the social team with an easy-to-use tool on any device to quickly spin up designs. Social Media requires rapid responses and quick turnarounds, so to do we require the same of our designs.
While Canva does provide many pre templated layouts, we do not use those. The social team will build custom art using basic GitLab brand guidelines and best practices for social media. In the future, many templates and individual assets will be brand team approved, but we have not iterated far enough to work in a rapid process.
The elements the social team uses for our designs are mainly GitLab-owned. Icons, sketches, animations, etc. were usually created for non-social purposes and we've added them to our library to use for social media. We do use Pro-only elements on occasion, but strive to find elements we feel would not be used often by other brands.
While each channel has their own best sizes to use, and changes often, for the sake of scale and efficiency, we'll use the following dimensions unless otherwise noted.
Here's the strategy behind the decisions above:
The purpose of GitLab team members participating in 3rd-party events is to bring GitLab's message to the 3rd-party's audience and to gain more community. Therefore, it's contradictory for GitLab brand social channels to promote a team member speaker for a 3rd-party event. Periodically, if the speaking engagement is part of a critical campaign or would resonate with the zietgiest of the moment, we may tweet once for folks to register for the event. However, if you're the speaker, we encourage you to post to your own social channels so that your network can join the event. Share your post with the #social_media Slack channel and we'll like, comment, and maybe share your post!
New blogs are linked in the #content-updates channel, and then our team simply uses that as a notification that the blog is ready to schedule and share on social. Sometimes when it’s connected to a campaign or is particularly important, we’ll also get a ping about it in a thread from the original slack message.
If the blog is connected to an integrated campaign, it will be picked up in the social issues and epics for that campaign. If it is a part of a press release/announcement, we'll also be tagged in related issues through the PR workflow.
On a quarterly basis the social media team will identify the best performing blogs. The top 2-3 blogs will then be reintroduced and scheduled to publish on GitLab's Brand Social Channels.
GitLab Team Members are encouraged to write "unfiltered" posts, or blogs that do not go through an editorial process. This is an efficent way for folks from across the company to share ideas, hacks, stories, and more. However, because these blogs do not go through the traditional editorial process, we cannot promote them on our GitLab brand social channels. The editorial process is viewed as the bar to pass through in order for the company to support the writings we promote. The best way forward is to follow the plan as laid out in the Unfiltered Handbook. If you publish an Unfiltered post that you think could be a good fit for either the Editorial and PR teams, feel free to share it in the #content Slack channel. The social team does not own the approval of shifting blogs from Unfiltered through the editorial process and therefore cannot assist beyond this guidance.
We'll come across articles that are behind a pay wall from time to time, mainly when it's press coverage we're looking to share. We can still share these articles on our social channels, however, we'll need to disclose that there is a paywall in the copy of the social post, as to be transparent with our community. Clicks that come from folks who can't read the article aren't distinguishable from clicks where folks can read below the fold, so it's important to be clear about the differences.
Add the paywall disclosure copy to the very end of the copy. Consider using a line break to make this sentence explict to the community.
Because of limited API access, it's challenging to engage and respond with posts on LinkedIn that do not directly @mention the company page. However, you can use the following method.
Every specific LinkedIn post from a page or a person has its own URL, like this one. At the end of the URL, there is a string of characters at the end, like 6674298269985767424-4SEx/ from the example above. If you add the following to the end of the post URL when you are an admin of the GitLab LinkedIn page, you'll be able to engage and comment as GitLab.
?actorCompanyId=5101804
The URL example from earlier is
https://www.linkedin.com/posts/wilspillane_open-source-social-media-strategies-from-activity-6674298269985767424-4SEx/.
Adding the actorCompanyId to the url would look like
https://www.linkedin.com/posts/wilspillane_open-source-social-media-strategies-from-activity-6674298269985767424-4SEx/?actorCompanyId=5101804
This URL would allow for GitLab to comment and engage.
When an incident occurs, it may be appropriate for the social team to pause all brand channel social posts. This is called "going dark", and is a regular part of evaluating whether or not company messaging is appropriate to share at any given time. It is considered good practice to minimize the digital space brands occupy on social media during these times. This can help to not distract social conversation but can also reduce the probability of being accidentally caught up in conversation unintentionally, sounding tone-deaf, or otherwise coming across as insensitive.
When this occurs, time-sensitive posts will be the first to be rescheduled. In the event time-sensitive posts could not be rescheduled, the social team will do what we can to update our stakeholders on what posts won't be published. Non-time sensitive posts will be moved to Sprout drafts, which can then be rescheduled at a later time.
Going dark could have a negative impact on social metrics, depending on the severity and length of time we're dark. Going dark could also negatively impact specific CTAs if we're relying on organic social to perform. These considerations are a part of making the decision and will be communicated as often as appropriate.
It may be necessary to update copy or assets depending on cultural impact during an incident. The social team reserves the agency to do this as we see necessary, however, we will communicate the changes to our stakeholders if we'd consider the changes to be major.
For GitLab status updates, folks can find info at the @gitlabstatus Twitter handle. This account is not managed by the social team.
Beyond general inquries and regular social engagement with our followers, we do not provide core support in private messages on social channels. We will instead direct followers to the GitLab forums for support.
Please use a derivative of this message:
Thanks for reaching out! In our spirit of transparency, we don't provide support here. Please add your question to the Q&A section of the GitLab forum, so that everyone can learn the answer. https://forum.gitlab.com/c/questions-and-answers/7
The above template is also located in Sprout for quick access
