Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Acquisition Process

  1. You are here:
  2. Handbook
  3. Acquisitions Handbook
  4. Acquisition Process

This is a detailed view of our acquisition process. For more information about our acquisitions approach visit our acquisitions handbook.

Acquisitions deal flow

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 five key stages:

  1. Exploratory
  2. Early diligence
  3. Business case
  4. Due Diligence
  5. Integration

Exploratory stage

  1. Intro call: The purpose of this 30-min call is to:
    1. Learn about your company including team, products, financials, and funding
    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.
  2. Create a new, private Slack channel. Format: #acq-company_name. Add VP Product Strategy and the relevant product category director(s).
  3. Add template WIP Business Case to the top of the acquisition gdoc and start filling out the details
  4. Set up initial product call: start product diligence and discussion of which features could be built into GitLab and into which GitLab product stage. Discuss strategy fit to GitLab's product roadmap.
  5. Internal review: preliminary assessment of product and technology fit of the potential opportunity as well as integration options into GitLab. If the product lead is supportive of moving forward towards developing a more in depth business case, determine if the proposed acquisition is aligned with current product priorities and planned headcount allocations. Otherwise, set up a discussion with VP of Product before proceeding with further diligence.

Early Diligence

  1. Mutual NDA: Sign a mutual NDA as linked on our legal handbook page
  2. Form the acquisition team.
  3. Internal acquisition champion - every acquisition needs a champion; someone who is advocating for the acquisition, helping drive the acquisition rationale, and seeing its successful integration. For most acquisitions that fit our approach, the champion will come from GitLab's Product team, at the Director level. For other acquisitions, champions may come from engineering or possibly other functions.
  4. 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
  5. 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.
    3. Founder technical interviews - founders will go through two rounds of interviews to assess technical and cultural alignment.
  6. Resume review - Review of all employee resumes
  7. Compensation review to identify any gaps and possible flags led by the HR Business Partner
  8. Optional interviews for the key technical employees - to increase the success rate of the deal post-LOI we recommend conducting interviews for the key technical employees identified before signing the LOI. This will greatly reduce the likelihood of personnel gaps becoming a blocker during the Due Diligence stage. The interviews will include a technical interview and a manager interview as detailed in the Due Diligence stage below.
    1. The key technical employees are those identified as critical to the success of the acquisition, the proposed integration plan and the future of the team at GitLab post integration.

Business Case stage

  1. Product integration strategy: the internal acquisition champion 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
    7. Deal milestones:
      1. Typically we aim to set 3-4 milestones, to provide a concise set of goals which should cover the bulk of our product interest in the target company
      2. Integrated within 6 months:
        1. 6 months is an optimal timeframe which isn't too far sighted where possible changes in priorities could consequently lead to us negating our interest in said milestones. This could further lead to complexed legal scenarios where payments are subject to milestone completion but if those were changed then circumstances are different.
        2. Will help establish focus on both acquired target and our product team
        3. Be able to complete payouts to the target's entity and shut it down sooner
      3. First milestone shipped within 30 days of joining GitLab:
        1. Critical to adopting our culture and successful future integration of the target's engineering team in GitLab.
        2. Allows us to show early fruits of the acquisitions soon, aligned with our value of iteration.
    1. To determine the deal ROI, the acquisition team will perform the analysis using the cost-revenue acquisition calculator (internal GitLab document). Make a copy of the master cost-revenue acquisition calculator file and save it in the relevant project folder in Google Drive before making changes to the file.
  3. Present business case for internal review of the acquisition proposal.
  4. LOI and Exclusivity Agreement: Using the LOI template(internal GitLab document) and the Exclusivity Agreement, assuming all terms have been reviewed, the acquisition lead will both agreements for digital signing.

Due Diligence stage

  1. To kick-off the Due Diligence stage, email the target company with the following clarifications and information:
    1. All employees and their profiles will be reviewed by the GitLab team
    2. The employees who will be invited for an interview process will go through GitLab's standard interview process
    3. Key employees identified who were interviewed during the Early Diligence stage may go through further interview rounds as determined by the GitLab team to qualify for a role at GitLab
    4. All employees must identify an open vacancy at GitLab which they think best matches their professional profile. This will be shared in a spreadsheet gathered by the target's CEO.
  2. Technical diligence
  3. Financial & legal diligence
  4. The progress of the diligence will be synced on a daily stand-up call for the acquisition team
  5. Final internal review call with the acquisition team to recap the acquisition as a whole and present a final recommendation

Integration

The Corporate Development team will be responsible to oversee and facilitate the integration of the acquisition post-closing, working closely together with the respective organizations in GitLab, namely: Legal, Product, Engineering, and Finance. The DRI for the integration stage is the Sr. Director, Corporate Development. This will consist of several aspects and best practices:

  1. Operational shutdown (if appropriate):
    1. Execution of customer sunset plans
    2. Shutdown of target company and its entities
  2. Alignment on objectives and goals:
    1. Incorporate the integration plan into GitLab's roadmap
    2. Introduce deal milestones into respective departmental OKRs
    3. Create and update product vision in case a new product area is added to GitLab
  3. People & Culture:
    1. Cultural integration plan, analyzing similarities and differences in the two companies' cultures
    2. Onboarding of acquired team members
  4. Performance tracking:
    1. Identify and continuously revisit business performance metrics to track the deal's added value and ROI over time
    2. Delivery against product plans and OKRs

Forming an acquisition team

An acquisition team will consist of the following GitLab functions:

  1. Corporate Development acquisition lead
  2. Sr. Dir. Corporate Development
  3. VP Product Strategy
  4. Dir. Product Management
  5. Product Manager
  6. Dir. Engineering
  7. Finance/accounting team member
  8. Legal team member
  9. HR Business Partner

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
HR Business Partner 1. Lead the compensation review 1. Lead the interview process during the early and due diligence stages to completion  

Acquisitions are confidential

At GitLab, we treat all acquisition discussions as confidential and share any information internally 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.

Edit this page — open Web IDE — please contribute. Creative Commons License