Developer Advocacy
Developer Advocates build GitLab’s technical brand with deep, meaningful conversations on engineering topics relevant to our community.
Welcome to the Developer Advocacy Handbook
QuickLinks
Team Workflow
Issue Templates
Issue Boards
Team Resources
Want to work with the team?
Mission
To support, grow, and engage the wider GitLab community through collaboration, content, and conversations.
Strategy
Developer relations and developer advocacy is an evolving, complex field.
Our team focuses on areas aligning with the company’s areas of interest including:
- DevSecOps: We want our work to speak to not only developers but all team members involved in the DevSecOps lifecycle to deliver working code to production: Product Managers, software engineers, system and DB administrators, designers, test engineers, security engineers, operations engineers, platform engineers, SREs, development managers and executives, etc.
- Enterprise: Developers and DevSecOps professionals in the enterprise have special constraints and needs. Often these are glossed over with easy “throw out your architecture and use this new shiny thing” - we won’t do that, we’ll acknowledge real-world challenges, legacy code, and enterprise constraints and help people solve those problems as well. When applicable, we switch roles into consulting and support.
KPIs
The FY25 Marketing Strategy (internal only) shows a Customer Journey with five stages: Awareness, Consideration, Conversion, Expansion, and Evangelism.
While our team can influence people at each stage, our key focus is on Awareness, Consideration, and Evangelism. The KPIs we use to measure our impact on these stages are:
- views from content published across owned and earned channels
- developers engaged through webinars, workshops, and industry events
We also look at Developer Relations influenced pipeline and active community members as performance indicators.
We recognize these KPIs don’t capture the impact of the diverse range of work that our team does but understand that tradeoffs can be necessary to effectively communicate our impact within GitLab.
OKRs
What fits in our strategy
When we are reviewing opportunities or requests for support, we must be able to answer yes to each of these questions to move forward with the work:
- Will this work support, grow, and/or engage GitLab customers and community members?
- Is there a measurable impact against one of our team’s KPIs? Because of GitLab’s global optimization subvalue, we’ll also consider requests that influence a company KPI or contribute to progress on an OKR.
- Has an issue been created to define the work and assign a DRI?
If the answer to any of the above questions is “no”, we ask the requestor to take one of the following actions:
- Make adjustments so we can take on the work.
- Find another team that is better suited to deliver the work.
- Come to an agreement that the work should not be done.
Team members and focus areas
We are members of the Developer Relations team.
| Team member |
Focus areas |
Languages |
Projects |
Technologies |
Resources |
Abubakar Siddiq Ango
Developer Advocate |
Program management, team content creation and repurpose. DevSecOps with a focus on the Cloud Native Ecosystem |
English, Yoruba, Hausa |
DevRel Bot, Campaign Manager, event support |
Kubernetes, CI/CD, PHP, Ruby, JavaScript, Rust |
Website |
Cesar Saavedra
Staff Developer Advocate |
DevSecOps with a focus on CD, GitOps, Kubernetes, GitLab Flow, Feature flags, GitLab Duo |
English, Spanish |
GitLab demos on YouTube, Analyst relations demos, Competitive Research, CD Overview, Feature Flags, GitLab Flow |
Kubernetes, GitOps, CI/CD, Java, AI |
|
Daniel Helfand
Developer Advocate |
DevSecOps |
English |
|
CI/CD, Kubernetes, Go |
|
Fatima Sarah Khalid
Developer Advocate |
Community Engagement, DevSecOps |
English |
LinkedIn Live, Community Engagement |
CI/CD, C++, PHP, JavaScript |
|
Fernando Diaz
Staff Developer Advocate |
DevSecOps with a focus on Security and Compliance |
English, Spanish |
GitLab demos on YouTube, Analyst relations demos, event support, Security and Governance tutorials |
Security, Kubernetes, CI/CD, Python |
|
Itzik Gan-Baruch
Staff Developer Advocate |
DevSecOps with a focus on CI/CD, Remote Development/IDEs and Value Stream Management |
English, Hebrew |
Product tours, Click-through demos, CI/CD components |
Remote Development, CI/CD, Value Stream Management |
|
John Coghlan
Director, Developer Advocacy |
Strategy and Planning in Developer Advocacy |
English |
|
|
Website |
Michael Friedrich
Staff Developer Advocate |
DevSecOps with a focus on efficiency with AI |
English, German, Austrian |
GitLab Duo Adoption, CI/CD components |
DevSecOps, AI, CI/CD, Python, Go, C/C++, Rust |
README, Talks, Portfolio |
William Arias
Staff Developer Advocate |
DevSecOps with a focus on AI/ML, Sec and Data |
English, Spanish |
Support Ticket Sentiment Analysis, Competitive Research, Analyst relations demos, End-to-end DevSecOps Platform |
CI/CD, AI/ML, Kubernetes, Security, Python, C |
|
What we do
Our developer advocate team can be summarized by the “Three Cs”:
- Content creation: This is what many often think of when thinking of the traditional role of developer relations: writing blog posts, delivering technical talks, participating in podcasts or panels, and sharing ideas and thoughts on social media. Content creation also includes assets co-created with other GitLab teams, inside and outside of Marketing.
- Customer and community engagement: Our team regularly engages with GitLab customers and the wider GitLab community when they have questions, concerns, and feedback. This happens during in-person and virtual events, webinars, and meetings and online via GitLab issues, the GitLab Forum, Hacker News, and other social media sites.
- Consulting: Within GitLab, our team represents the voice of the community. When other teams are working on changes or decisions that will impact customers and the community, we will educate them on our customers and community, advocate for their interests, and work to ensure that any potential impacts are clearly understood and addressed when communicating such changes. Our team also shares our knowledge of industry trends, emerging tools, social media strategy, and other skills to support our teammates in achieving their goals in alignment with GitLab’s Global Optimization subvalue.
Content creation
We build out content to help educate developers around best practices related to DevOps, GitLab, remote work, and other topics where we have expertise. Content includes presentations, demos, workshops, blog posts, and media engagements. Content creation also includes assets co-created with other GitLab teams, inside and outside of Marketing.
Please read the Content handbook to learn more about the content workflow, library and distribution with UTM tracking.
Customer and Community Engagement
Our team regularly engages with GitLab customers and the wider GitLab community.
The Developer Advocate team is the DRI for questions and strategy on the platforms below:
Given the Developer Advocate team’s understanding of our community and broad knowledge of GitLab, we will engage in the response of situations that require intervention to address urgent and important concerns of our community members. We have a documented process for how we manage these situations.
Consulting
Developer Advocates serve as consultants and subject matter experts (SMEs), leveraging their expertise and experience to support teams and customers with product features, new SKUs, and other topics.
Please read the Consultancy handbook to learn more about consultancy requests, decision matrix, and examples with GitLab Duo / AI adoption.
Other activities
Event support
The Developer Advocate team plays a key role in supporting events. We work closely alongside Corporate Event Marketing to provide strategic content and assistance for both corporate and third-party sponsored events. This collaboration ensures the success and seamless execution of various gatherings. To learn more please refer to the Events page.
Release Advocacy
Developer Advocates should always be prepared to promote our monthly release and engage in community response on release days given the historical performance of release posts on Hacker News.
We build our thought leadership and distribute our content on social media. See Developer Advocacy on Social Media to learn more about our strategies and become a GitLab advocate yourself.
Spokespersons
Developer Advocates are subject matter experts (SMEs) in their focus areas, and collaborate with the Corporate Communications team to provide media coverage in the form of interviews, podcasts, content by-lines, etc. Developer Advocates are GitLab spokespersons and are required to take relevant training as determined by the Corporate Communications team.
Our team uses different tools to grow and analyze our thought leadership, automate workflows, and improve written and presentation skills. See Developer Advocate Tools for a list of all of those tools.
Projects
Our team maintains projects to provide GitLab use cases for content creation (demos, recordings, blog posts, workshops, talks, etc.), help showcase technical concepts and research to customers, and automate our team processes. We work in public by default, so that everyone can learn and contribute. See Developer Advocate Projects for a list of all of those projects.
How we work
Find us on Slack
GitLab team members can also reach us at any time on the #dev-advocacy-team Slack channel where we share updates, ideas, and thoughts with each other and the wider team.
We use developer-advocacy-updates for content shares and other updates that don’t warrant generating noise in the larger channel. Many updates are automated using Zapier workflows
Team meetings
- Dev Advocacy team meeting (bi-weekly) - Agenda: search for
Developer Advocacy Bi-Weekly in GDrive.
- Developer Relations all-hands (monthly) - Agenda: search for
Developer Relations & Strategy | All Hands Agenda in GDrive.
- Dev Advocacy Showcase (monthly) - Agenda: search for
Developer Advocacy Showcase [monthly] in GDrive.
Reporting
We organize our work through documented team workflows, ensuring transparency and efficiency. Most of our results reporting is automated through triage bots and metrics collection.
Additional reporting is provided in the weekly Developer Relations report, search for Developer Relations - End of Week updates in GDrive.
Calendar
The Developer Advocate calendar provides insights into speaking engagements, important events, CFP timelines, and other dates. Learn more in our CFP handbook.
We run a monthly Community Newsletter to share developer-focused content, keep community members informed about upcoming events, and promote contributions within the community. The target audience for this newsletter is aspiring and existing GitLab contributors in our community. This newsletter will not be used to drive or generate leads.
Process
The Community Newsletter is scheduled to send on last Thursday of each month at 10 AM PT / 6 PM UTC.
Learn about the Developer Advocacy team's consultancy workflows and requests.
Learn about the Developer Advocacy team's content library, creation and distribution workflows.
CFP Resources
Event call for paper submission forms differ: Some require 1000 character abstracts, others prefer shorter biographies, or require you to fill in the talk learning goals. The Developer Advocacy team uses Google docs for maintaining CFP abstracts, @dnsmichi also uses a doc for the biography and headshot URLs as SSoT.
How we manage CFPs (Call for Proposals)
Our events list
Every year, developer advocacy prioritizes key events in our ecosystem for which we run the conference proposal (CFP) process. The event engagement with lightning talks, CFP submissions, etc. is organized in issues which are linked and summarized in a yearly strategy epic. You can also find a calendar view of our events below:
Given the developer advocacy team’s familiarity with our community and broad knowledge of GitLab, we regularly engage in managing situations that require GitLab to address urgent and important concerns of our community members.
Our team uses the Community response board to organize tasks.
Notification
- Upcoming announcement: To notify the developer advocacy team of an upcoming announcement, product change, or other news event that may elicit a response from our community, the DRI should comment to
@johncoghlan in a relevant issue or notify the developer advocacy team in the #dev-advocacy-team Slack channel. Please also apply the ~Community Interest and ~Community response labels to any relevant issues or epics related to this announcement.
- In-progress situation: To notify the developer advocacy team of an urgent situation that is in-progress, please tag the
@dev-advocates User Group in a Slack message in a Slack thread or channel where the situation is being discussed or the #dev-advocacy-team Slack channel.
- Please give the developer advocacy team as much notice as possible so we can help influence the messaging of the announcement, prepare responses for the community, and schedule coverage. See Scheduling below for more details.
- Please add the
Community response label to related issues, epics and MRs. Our team owns the label for the gitlab-com and gitlab-org groups. You can use this quick action: /label ~"dev-evangelism" ~"Community response" to apply the labels.
Preparation
- In alignment with GitLab’s efficiency value, the developer advocates will work with the Directly Responsible Individuals (DRIs) for the community response situation to help the DRI and other experts directly address the community feedback and questions.
- When possible, the developer advocacy team will typically collaborate with the DRIs on a list of expected questions/concerns from the community and draft responses. When available, we also include materials prepared for media responses, customer responses, or other materials related to the situation in our response preparation.
- For high-priority announcements and news, we will conduct a practice exercise alongside the DRIs to test our preparation.
- In many cases, we will want to direct the community to share their feedback in the GitLab Forum. By preparing a post that we can link to from a blog post, announcement, or community response will streamline how we gather feedback and manage responses. This post should be created by a Forum admin in advance as a private post which is published at the time of the announcement.
- Note: when a forum post is used for feedback, consider turning off comments on the blog to encourage discussion on the forum.
- When possible, please create an issue using the Community Response Plan template and add details to each section per the instructions in the template.
- This issue can be shared with stakeholders to gather more information from them and get sign off, as needed.
Forum Topic Preparation
- Define a forum DRI from the administrators and moderators listed in the forum about page.
- As response requestor, provide these details:
- Forum topic title. Can be the blog post title, or a neutral placeholder when urgent. The Discourse forum renders the topic as URL slug automatically.
- Final blog post URL. Does not need to exist yet.
- The forum DRI navigates to
+ New topic and selects Internal as category. This is a private category accessible by team members.
- Set the topic title and link the blog post URL which will later render a preview.
- Create the forum topic, and send the URL to the response requestor.
- Share the URL to the Forum Community Response Workflow handbook, providing instructions how to review and edit the topic on the forum.
Coordinate blog post publishing with forum topic publishing. This has a circular dependency on each other, and needs to be done in the same minutes.
Introduction
Developer Advocacy builds out their thought leadership through social media and community engagement. The tips and strategies shared here can be used by team members and the wider community to help build their own profile as an evangelist.
Topics:
- Education and Learning: Tips from own experience. Workshops, slides, blog posts, videos, etc.
- Events live tweets / tweet storms. Amplify talks with screenshots and messages.
- Release Evangelism: Share feature insights with personal views.
- Community best practices and GitLab insights.
- Contributions to GitLab and the cloud native ecosystem.
UTM Tracking
Developer Advocates at GitLab are encouraged to add UTMs for URL tagging and tracking to provide analytics and insights on how well content shares are performing. This method helps to verify KPI metrics.
Team Calendar
The Developer Advocacy Team calendar contains team member speaking engagements, important conferences, CFP timelines, and other important dates.
Developer Advocates should add new speaking engagements to this calendar as they are scheduled. The Developer Advocate Program Manager will manage team-wide events such as industry conferences and their CFP timelines. If you need write access to this calendar, please contact a member of the Developer Relations team via Slack.
Overview
The Developer Advocacy team uses tools to grow and analyse their thought leadership, improve written language and speaking experience and automate as much as possible. We use GitLab and build our own tools when there is no viable alternative, see projects.
Buffer
Developer Advocates use Buffer in the Pro tier to manage scheduled campaigns. Buffer acts as a queue with async publishing functionality. This allows to collect interesting URLs from your browser and mobile, add them to the queue and publish in different time slots throughout the day/week.
Introduction
This handbook page documents best practices how Developer Advocates can help wider community members with mentoring and coaching.
Mentoring
Finding a mentor
GitLab Developer Advocates actively engage with mentoring wider community members. The team’s time is limited with our many activities, please understand when we decline a request. Polywork and other platforms can help finding mentors.
Resources
Topics
If the career path is to becoming a Developer Advocate, the Developer Advocacy handbook provides many resources.
Team Workflow
Welcome to the Developer Advocate team workflow page. Learn how the team works and how to work with the team. We primarily use the Developer Advocate Meta issue tracker. We own the team label developer-advocacy and all of our other labels which are located at the gitlab-com group level. You can add the labels as necessary to any issue under this group for our team to track.
Overview Video
The Workflow overview video showcases the different components of the workflow in detail. The video is internal only due to confidential issues shown in workflows. If you would like to jump to the specific chapters of the video, see the links below.
Overview
Hacker News is an important social channel. Threads that mention GitLab’s structure, values, product vision, or other sensitive blog posts, articles, etc. should be treated as important, while posts about GitLab that land on the front page of Hacker News should be treated as both important and urgent.
Hacker News posts are important because they can generate traffic for our website, backlinks to our content, and, most importantly, value feedback on our product and processes. As an example, a Hacker News post about this page from January 2022 generated valuable feedback for our team.
The Speakers Bureau is a group of GitLab team members and members of the wider GitLab community who are available to participate in events and deliver talks.
What is advocacy?
Advocacy creates a human connection with buyers and consumers to technology way beyond typical content marketing, with a face and a name relaying the story, expressing an opinion, and ultimately influencing a decision.
Many people believe Guy Kawasaki, the former chief evangelist of Apple Computer, to be the father of advocacy.
Sources:
Who can be an advocate?
Everybody in the wider GitLab Community can be an advocate. Whether you work in marketing ops or infrastructure engineering, you have a point of view on the work you do and the ecosystem of open source enterprise technology.
Contributions to OSS
The Developer Advocacy team believes in Open Source and wants to lead by example, contributing to GitLab and the OSS ecosystem. Our workshops, community activities and projects are documented in the projects overview.
Projects maintained by Developer Advocates
We organize our projects in the Developer Advocacy group. A few examples are:
Contribution Examples
GitLab
Prometheus
HashiCorp Waypoint
- Documentation
- Blog posts
- GitLab Integration
- Demo
- Community
Definition of Contributions
Contributions are “more than just code” and are often times hard to measure. Our team tries to start with a small subset and update this section over time.
Introduction
We maintain our projects in the public gitlab-da group. This group has access to an Ultimate subscription.
The group organizes use cases, workshops, tutorials, maintained open source projects, demo playgrounds, thought leadership research, and more learning resources.
Organisation Structure
All projects are organized in sub-groups on the top level. No projects are allowed on the top-level namespace gitlab.com/gitlab-da.
| Group |
DRI |
Description |
| conferences |
@fjdiaz |
Group for public demos for team members at conferences, events, meetups, etc. |
| playground |
all |
Test projects, simple demo cases, code snippets, etc. without support. Please move them into the corresponding use-cases groups when linking from a blog post. |
| use-cases |
all |
Use cases for specific topics for product demos, talks, thought leadership, research |
| projects |
@abuango |
Production projects maintained by the team. For blog projects and demos, use the specific use-cases groups. |
| projects/devrel-bot |
@abuango |
Issue triage and automation workflows for Developer Advocacy and Developer Relations workflows. |
| projects/hide-duo-beta-trial |
@abuango |
Chrome extension to hide Beta/Trial widgets in the GitLab UI. |
| projects/discourse-assets |
@sugaroverflow @dnsmichi |
GitLab Discourse forum assets and customizations. |
| tutorials |
all |
|
| tutorials/security-and-governance |
@fjdiaz |
This group contains different projects as well as documentation around GitLab’s security and governance tools. |
| unmaintained |
- |
Projects, tutorials, use cases that are not maintained anymore but kept public for transparency |
| workshops |
all |
Workshop groups and projects provided by the team |
Use cases overview:
Speaker Resources
The Developer Advocate team is always happy to help at any stage of talk preparation, there is also a speakers resources page where you can find helpful guides and tips.
CFPs
You can learn more about the team’s CFP process here.
Developer Advocates use Google docs templates for abstracts and biographies, which you can reuse for your own talks.
Writing good conference proposals is both an art and a science. The science is the details of the technical content. The art is presenting it in a way that appeals to the audience - the conference committee.
If you are planning to speak at a conference of 500 people or more, feel free to create an issue and request help from the Developer Advocate team.
Here are some steps to go through when writing a CFP:
