This page will serve as a training resource and operational guide for current and future managers. All Sales Development Managers should follow the general leadership principles set out in the handbook.
Onboarding is essential for all Sales Development Managers at GitLab. As part of onboarding, a Becoming a GitLab Manager issue will be created for each manager when they join, or are promoted. This issue is intended to connect new managers with the crucial information they need, and ensure they have access to all the resources and training available.
The BDR process that we have defined here in GitLab is meant to provide a repeatable set of steps that an outbound BDR can follow to achieve results. It is very important for an onboarding manager to align themselves as quickly as possible to this process as it is a proven method that will help them manage their team in a efficient and data-driven way.
The BDR Process is explained step-by-step in the main SDR handbook page here
For a newcoming manager, we provide the Watch and Help Dashboards that will be your main tool in understanding where your team is aligned to our BDR process, and where they need assistance.
To help structure your usage of the above, you can follow the steps below during your first month at GitLab while the document here will be your main go-to resource
|Clone the W&H Dashboard and edit each report to be exclusive to your team's names||Gives you a SSoT that you and your team can easily reference|
|Review the dashboard with your team, and discuss how the data on it connect to the BDR KPIs||Allows you to understand your team's level of maturity and each team member's current level of alignment to existing processes|
|Take note of any discrepancies or points of feedback from the team, either transcribe them to 1:1s for individual conversations or to the SDR Issue board for org-wide improvements||Enables you to filter between discrepancies that are caused because of a team member's lack of diligence that should be improved upon by the individual OR for discrepancies that were caused by an org-wide operational shortcoming that should be improved upon on a global scale.|
|Set realistic expectations with the team about adherance to org KPIs and set a review mechanism to go over them on a reccuring basis||Helps maintain a repeatable structure of accountability for your entire team|
|Leadership Handbook||Tools and resources to assist people managers in effectively leading and developing team members at GitLab|
|Compensation Review Cycle (Compa Review)||How to review our Compensation Calculator and carry out the Compensation Review Cycle|
|Sales Dev Manager Onboarding Checklist||Make a copy and complete this checklist to ensure you know your team's tools and processes|
|360 Feedback||Opporunity for managers, direct reports, and cross functional team members to give feedback to each other. Schedule and all information on this page.|
|Workday||All team member HR information|
|Transitioning to a Manager Role at GitLab||New manager resources and what to expect|
|SSoT Sales > Sales Development Territory Alignment Sheet||Can be found in Manager Home Base sheet. Single source of truth document for Sales Development to AE/SAE/Territory Alignment|
|LeanData Change Request Issue Template||Use this template to request any update in lead routing/SDR alignment. Use a new issue for each SDR. Once this request is received, Marketing Operations will update LeanData, the SSoT alignment spreadsheet, Drift routing/team, and the
|SDR Internal Transition issue template||Use this issue template when you have an SDR moving from one team within our SDR org team to another. More information can be found in the internal trasition section below.|
|How to update the org chart and team page||Update the org chart to ensure the correct memebers of your team roll up to you. Ensure each member of your team has your
|Adding yourself or someone else to the team page||Video to assist new hires with updating their blank team page placeholder|
|Update manager or SDR role in Salesforce||To update a manager or Sales Development role in Salesforce, submit a single person access request or bulk access request depending on the number of roles that need to be updated. Keep in mind if this is needed due to someone transferring teams within the Sales Development org, this is already part of the Internal transfer issue template.|
|Create or update members of a Slack user group||A user group is a group of members in a workspace who often need to be notified at once — for example, @managers. To update who is in one of the Sales Development groups, submit a single person access request or bulk access request depending on the number of people that need to be added. Fill out the requested info and delete any remaining info that isn't needed. Under 'Account Creation' put Slack User Group: @ Name (i.e. @Managers). You can also use the bulk AR to request the creation of a user group and list the users who should be in it.|
|Add someone to the Sales Development Gmail alias||Submit a single person access request or bulk access request depending on the number of people that need to be added. Fill out the appropriate info and delete any remaining info that isn't needed. Under 'Account Creation' put the Sales Development email alias|
|Make an edit to the handbook||Guide for how to edit the handbook. *Note: all new hires must do this as part of their onboarding|
|Add a new page to the handbook||This GitLab Unfiltered video will walk you through how to create a new handbook page|
|Create a new job family||For each job at GitLab, the job family is the single source of truth for the expectations of that role. If you need information about when to create a new job family vs when to use an existing one watch this video|
|Rename a handbook page||Update the name of the URL to a handbook page|
|Resolve failed pipeline when creating an MR||Quick overview of how to go about identifying why a pipeline might be failing for a merge request to the handbook page|
|Sales Development Onboarding Job Specific Task Section||This task section will automatically be added to the general onboarding issue for new SDRs based on their role when hired.|
|SDR Issue Board||Used to track GitLab issues involving the SDR team. This is a global issue board. Please use the purple
|SDR Event Tracker Issue Board||Used to follow upcoming events globally|
|SDR Sisense Dashboard||Dashboard to monitor SDR leads and meetings|
|MQL & SAO Performance vs. Target Sisense Dashboard||Monitoring MQL and SAO performance in comparison to our goals|
|Large Land Watch and Help Board - Expand Watch and Help Board - SDR Inbound Watch and Help Board - MM Watch and Help Board - PubSec Watch and Help Board||Monitoring Contact Requests, Qualifying Leads, IQMs, and Paused/Failed Sequences|
|Lead View Descriptions||There are Manager Lead views in SFDC mirroring the SDR and BDR views which are described on the linked Handbook page on the left. These views need to be checked regularly by managers to ensure all necessary leads are being worked.|
Format: Audience | Type | Urgency Example:
[All of Sales Development] | [Enablement - Mandatory] | [🚨 Action Required]
[All BDRs] | [Operations - Outreach Process Cleanup] | [🧠 Need to Know ]
[EMEA Enterprise Land] | [Operations - New Outreach Event Sequence] | [🚨 Action Required ]
[All of Sales Development] | [Survey - People Group Survey Reminder] | [📊 Feedback Requested ]
BDR Assigned Actively Working -
BDR Assigned Not in Actively Working -
BDR Actively Working Accounts w/No Active Sequence or Qualifying Status -
Sales Dev by Salesforce Profile and Role -
Sales Dev Territories by Team role/member associated with each territory -
GitLab People Connect Team members will create the onboarding issue and start completing the onboarding tasks, no later than one week before the new team member joins. People Connect Team members require a minimum of 4 business days (with the new hire timezone as the basis) before the new hire's start date to complete all onboarding tasks. This issue will be automatically assigned to you. As a manager, you will also have tasks that need to be completed prior to the new team member's start date.
The general onboarding issue will also automatically add a 'Sales Development' section under 'Job Specific Tasks' based on the role of the new SDR. Both you and your new hire will have tasks to complete in this section.
With the creation of this issue, an access request (AR) will also be automatically created for a new team member on their second day at GitLab. This AR lists the role based entitlements (pre-defined groups and system-level access that are granted automatically to team members depending on their role) your new hire will need. *See what is being auto provisioned on this AR here.
On your new hire's first day, the assigned People Connect Team member will schedule a welcome email to arrive at 7:30am (local time of the new team member) on their start date detailing how your new hire can access GitLab and begin their onboarding process.
If an SDR or a group of SDRs will be moving from one SDR team to another, please open this SDR internal transition template as the automatic people ops issue does NOT get created for this type of transition. Please complete the steps in this issue to ensure the SDR changing teams has everything they need.
A career mobility issue should be opened 2 weeks before the transition date by the people connect team. If the aligned manager does not see that issue created 2 days before the scheduled transition date, the manager should reach out to the People Connect Team via the #people-connect Slack Channel.
People connect opens mobility issue if any of the following are true:
If an SDR will be out for a prolonged period of time, please follow the proper processes and complete the SDR leave checklist.
Similar to onboarding, there is a role-specific tasks section that will automatically be populated for the Sales Development team. This section includes tasks for the new manager and sales operations that must be filled out to ensure proper alignment, routing and reporting.
The full process for offboarding at GitLab differs based on whether it is voluntary or involuntary. These processes can be found on the offboarding handbook page.