Welcome to GitLab and congratulations on landing a job with the best open source tech company, GitLab. We are excited to have you join the team! We look forward to working closely with you and seeing you grow and develop into a top performing salesperson.
Our team consists of two functions, Business Development Representative (BDR) and Sales Development Representative (SDR). BDR focuses on qualifying inbound leads and SDR focuses on generating demand via outbound efforts.
On this team we work hard, but have fun too. We will work hard to guarantee your success if you do the same. We value results, transparency, sharing, freedom, efficiency, frugality, collaboration, directness, kindness, diversity, solutions, and quirkiness.
Being a BDR/SDR can come with what seems as long days, hard work, frustration, and even at times, failure. If you have the right mindset and come to work with a tenacious, hungry attitude you will see growth personally and in your career. security. GitLab is a place with endless opportunity. Let’s make it happen!
As a BDR and SDR, you will be dealing with the front end of the sales process. You play a crucial role that helps bridge the gap between sales and marketing. You will be tasked with generating qualified opportunities for GitLab as you look for leads, research companies, industries, and different roles.
As you gain knowledge, you will be able to aid these key players in solving problems within the developer lifecycle. There are numerous resources at your fingertips that we have created to help you in this process. You have:
BDR Handbook - This will help you with your day to day workflow. You can find information on how to prospect, best practices, customer FAQs, buyer types, cadence samples and more. Use the BDR handbook in conjunction with the marketing and sales handbooks. This will help you bridge the gap between the two and learn the product and process faster.
GLU GitLab University - These trainings will teach the fundamentals of Version Control with Git and GitLab through courses that cover topics which can be mastered in about 2 hours. These trainings include an intro to Git, GitLab basics, a demo of Gitlab.com, terminology, and more. You can also find information about GitLab compared to other tools in the market.
The GitLab Genral Onboarding Issue will typically fill up the majority of your first week. This is a step by step guide and checklist to getting everything in your arsenal set up like equipment, gmail, calendly, slack, security, and your Gitlab.com account. These todo’s provide you with the fundamentals.
The BDR Onboarding Issue will more specifically bring you up to speed with your role as a BDR. Do not take this to be concrete. We hire very talented individuals who take initiative and advantage of the opportunities and situations presented to them. Be creative, learn and try different ways of doing things. We are excited to have you and cannot wait to see what you bring to the team!
Each Business Development Rep (BDR) will be placed into the Marketo Queue and will receive a high volume of leads to work on a monthly and quarterly basis. Criteria for those leads are set by Marketo and the Director of Demand Generation
Manage and help inbound requests to email@example.com and firstname.lastname@example.org
Strategize to develop the proper qualifying questions for all types of customers.
Be able to identify where a customer is in the sale and marketing funnel and take the appropriate action
Generate Sales Qualified Leads (SQLs)
Rules of engagement
Inbound to work off of leads within SFDC
Inbound does not touch any lead that has activity on it within the last 45 days by a different BDR.
Inbound lead from Large/Strategic account list should be converted as a contact, with no opportunity, and the contact owner will be the SDR on the account.
If no SDR is assigned, assign to Account Executive (AE) on the account
If no AE, BDR should ask Regional Director for guidance, using the chatter function in salesforce.com
As a Sales Development Rep (SDR) you will be aligned with Account Executives and be assigned a list of 50-100 targeted accounts to work on a quarterly basis. The accounts assigned to you will be determined by the Regional Director that you will be supporting their team on pipeline growth.
Who in the org have we called before that we can follow up with or reference
Cross reference with version.gitlab.com to see their version and available other usage info
Summary/Bio - Anything mentioned about job responsibilities or skills
Previous work - Any Gitlab Customers that we can reference
Connections - Are they connected to anyone at GitLab for a possible introduction
(ctrl F) search for keywords
Collaborate, features, data
Making team projects more collaborative
Hit Team Targets and ROI
Your messaging for each one will be different. An end user or lower level developer will not care much about the ROI on our product.
Studies show that Executives read emails in the morning
Expect to be forwarded to the right person (Always ask)
Keep emails 90 words or less
Break into readable stanzas
Always be specific and tailored
Make your emails viewable from a mobile device
Opening Stanza (Best Practice is something about them)
Benefit & Value Proposition
Definite Ask with available days and times
Basics of Call Prospecting
Call about them, not you
Be confident and passionate
Aim for every role but focus on decision makers
Prospect into multiple departments
Ask for time
Focus on the your end game
Make it easy to say yes
Obtain a commitment
Structure of a Prospecting Call
Initial Benefit Statement
Qualification… See the criteria above in the handbook
Reason for taking the call (add value)
Inform them about GitLab
Cold Call Framework
Hi. This is (Name) from GitLab
Ask for Time
“Do you have just a moment?”
“Have you heard of GitLab before?”
Initial Message with IBS
“GitLab helps (Title) in the (Industry) industry solve issues around (pain & need) or
“(Industry specific client) used GitLab to (Case study value proposition)
Confirm that they are the right person
“I understand you are in charge of application/program development, is that correct?
Initial Benefit Statement example
"GitLab is an end-to-end developer lifecycle solution that allows developers to collaborate on code, project management, and to create a seamless workflow between teams across the entire org"
"Do you have 15 minutes on (specific day and time) to discuss your (example - developer life cycle)?"
Note: If there is a tutorial missing or something you'd like to learn how to do, please comment on this issue, or ping your Team Lead
Email Filters & Labels
#BDRing - Doing your job…Kris Touzel
#SQLing - Winning at your job…Ryan Caplin
#BDR - Boss Destroying Revenue
Frequently Asked Questions
How do I get help/assistance?
Don't hesitate to ping one of your colleagues with a question, or someone on the team who specializes in what you you're searching for. Everyone is happy to help, and it's better to get your work done faster with your team, than being held up at a road block.
Questions specific to:
Salesforce (I’m having issues with Salesforce, can’t login, my leads are not syncing, salesforce isn't working, I want to request more contacts from discoverorg, not sure what the protocol is, etc.)
GitLab account (it isn’t working, I can’t seem to login or access anything)
The handbook says “You should have clear objectives and the freedom to work on them as you see fit. Any instructions are open to discussion. You don’t have to defend how you spend your day. We trust team members to do the right thing instead of having rigid rules”
Who should I connect with for my 10 1:1 onboarding calls?
You can connect with whomever you please. However, you will interact the most with the Sales Team and the Demand Generation Team. * See the GitLab Team Page for suggestions.
Full-time BDRs have a significant portion of their pay based on performance and objective attainment. Performance based "bonuses" are based on results. Actions for obtaining results will be prescribed and measured, but are intentionally left out of bonus attainment calculations to encourage experimentation. BDRs will naturally be drawn to activities that have the highest yield, but freedom to choose their own daily activities will allow new, higher yield activities to be discovered.
Guidelines for bonuses:
Team and individual objectives are based on GitLab's revenue targets and adjusted monthly.
Bonuses are paid quarterly.
Bonuses may be based on various objectives
E.g. a new BDR's first month's bonus is typically based on completing onboarding
Bonuses may be tied to sales target attainment, OKRs, or other objectives.
If you get an answer to a question someone else may benefit from, incorporate it into this handbook or add it to the FAQ document
After meetings or process changes, feel free to update this handbook, and submit a merge request
Create issues for any idea (small or large that), that you want feedback on