Acquisition Process

Below is the deal flow of the acquisitions process with estimated conversion rates and metrics for each stage we think there can be a drop point. At this point, the estimates are hypothetical and not based on actual deal flow data we've collected through our process. The flow aims to capture the success rate and volume of the acquisitions process for GitLab.

Step	Success rate/volume
Potential target companies	1000/year
Strategy fit	30%
Deal term fit	15%
NDA	100/year
Code screen share	50%
Founders technical interview	70%
Resume review of all people	70%
Optional step: sample interviews with non-founders (will increase LOI success rate)
Deal terms discussed and socialized
LOI	15/year
Review all code	90%
Interview all people	60-90%
Acquisition offer	12/year
Acquisition closed	10/year

Acquisition process

The process is comprised of three key stages:

Exploratory
Business case
Diligence

Exploratory stage

Intro call: we'll reach out to schedule a 50 minute introductory call. The purpose of the call is to:
1. Current state of your company including team, products, financials, and more
2. Review the expectations and process noted on this page
3. Start discussing which features could be built into gitlab
4. Discuss which GitLab product category the team could join as a whole
5. Discuss deal terms as noted on the acquisitions handbook
6. Answer questions your team may have Details from this call should be collected following the Initial Acquisition Review Template(a GitLab internal document). TARGET TEAM: Ahead of the product call please review our roadmap and outline which of your current and future product features can be implemented into GitLab's product categories. Outline a simple integration timeline for those features, considering an MVC release on the first month after joining GitLab and monthly releases following with quick iterations.
Mutual NDA: Sign a mutual NDA as linked on our legal handbook page
Create a new, private Slack channel for the acquisition team discussions. Format: #acq-company_name. Add VP Product Strategy and where relevant, the relevant product category director/s to newly created Slack channel.
Add template WIP Business Case to the top of the acquisition gdoc and start filling the details
Product call/s: start product diligence and deep dive into the discussion of which features could be built into GitLab and into which GitLab product stage. Discuss strategy fit to GitLab's product roadmap.
Internal review: validate potential fit for the team within GitLab and the integration options into GitLab
Form the acquisition team
Preliminary financial & legal diligence - list of preliminary documents to share with GitLab:
1. Financials
2. Tax returns
3. Employee roster with: employee name, title, role, tenure, years of experience, location, salary, LinkedIn profile, programming languages proficiency
4. Employee Résumés and/or LinkedIn profiles
5. Employee agreements and PIAA
6. Customer list with name, monthly revenue, contract termination date and any other fields if relevant.
7. Vendor list with monthly spend
8. Asset list
9. Any assets that are needed for the business and will be part of the acquisition
10. Assets excluded from the acquisition
Early technical diligence:
1. In case the target company has open source components, the respective Dir. Engineering (dependent on GitLab stage) will start an early code review to determine: code quality, development practices, contributions and more. That should be turned around within 2-3 business days.
2. Hands-on product and code screen-share session (2 hours): the technical lead, as assigned by the respective Dir. Engineering, together with the respective Dir. Product will lead a screen-share session aimed at a hands-on validation of the product functionalities and an overview of the code.
Founder technical interviews - founders will go through two rounds of interviews to assess technical and cultural alignment.
Résumé review - Review of all employee résumés
Optional interviews for a sample of the technical employees - to increase the success rate of the deal post-LOI we recommend conducting interviews for a sample of the technical employees before we sign the LOI. This will reduce the element of uncovering gaps during the diligence stage. The interviews will include a technical interview and a manager interview as detailed in the diligence stage below.

Business case stage

Product integration strategy: the lead PM will formalize the integration strategy with a focus on feature sets/functionalities:
1. What we keep as-is
2. What we reimplement in GitLab
3. What we discard/EOL
4. Critical for user migration
5. Target product tiers in GitLab
6. Barriers for implementation
Present business case for internal review of the acquisition proposal.
LOI: Using the LOI template(internal GitLab document) and assuming all terms have been reviewed, the acquisition lead will share a LOI within 7 days.

Diligence stage

Technical diligence:
1. Code diligence - your team will provide access for key engineering contacts at GitLab to: code repositories, products and development/test environments.
2. Employee evaluations - each engineer will undergo two rounds of interviews comprised of:
  1. Technical assessment - a live coding session, solving a technical exercise or review a merge request with live followup session.
  2. Manager interview In case of acquisitions with over 10 engineers the employee evaluation stage will happen in phased approach for 5 employees at a time.
Financial & legal diligence
CEO call: Once integration of the product and team have been scoped out the acquisition lead will reach out to the CEO PA to schedule a 50 minute call. The purpose of this call is to:
1. Discuss the wind down and onboarding process details including roles for the founders and the placement of the team within GitLab.
2. Review the employee onboarding goals

Forming an acquisition team

An acquisition team will consist of the following GitLab functions:

Acquisition lead, currently Eliran Mesika on all acquisitions
VP Product Strategy
Dir. Engineering
Finance/accounting team member, currently Paul Machle
Legal team member, currently Jamie Hurewitz

To assign the product manager, after the product call or as soon as it's clear which product category the features will be implemented into, contact the category product director for the assignment.

To assign the engineer team member, contact the engineering manager of the relevant category for assignment.

Acquisition team responsibilities

Member	Role	Deliverables
Acquisition lead	1. Main POC for acquired team 1. Identify potential areas for integration 1. Create case for acquisition and customer transition story	1. Business case with deal structure
VP Product Strategy	1. Outline current product features to be implemented into GitLab 1. Outline potential future functionalities to be built into GitLab after the integration period	1. Integration strategy
Dir. Engineering	1. Lead technical diligence	1. Code quality review 1. Integration strategy validation - feasibility and timeline
Finance	1. Lead financial diligence 1. Validate business case and deal structure
Legal	1. Review entity, assets and existing agreements 1. Evaluate sunset and customer transition path	1. LOI 1. Acquisition agreement

Acquisitions are confidential

At GitLab, we treat acquisitions as confidential and we share the work on them on a need-to-know basis. If you're part of an acquisition Slack channel, GDoc or other internal GitLab discussion and would like to invite another GitLab team-member to one of those, please confirm with the acquisition lead before doing so.