Acquisition Process

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

Acquisition process

The process is comprised of five key stages:

1. Pipeline Building
2. Exploratory
3. Early Diligence
4. Confirmatory Due Diligence
5. Integration

Pipeline Building

1. Sourcing: The corporate development team closely collaborates with GitLab’s product leadership to identify key areas for potential M&A. We source acquisition opportunities (“Sourced Pipeline”) from:
   1. Ecosystem screen with the help of third party databases such as Crunchbase
   2. Inbound introductions from GitLab team members and industry contacts
   3. Proactive outreach to companies aligned with our vision and strategic priorities

Exploratory

1. We prioritize companies that fit with our product and acquisition priorities (“Prioritized Pipeline”) and reach out to their leadership to set up intro calls.

2. Intro calls: The purpose of this 30-min call is to learn more about the potential target company and assess if further acquisition discussions make sense. The agenda for the call is:

   1. Company overview including team, products, financials, and funding
   2. Discuss which features could accelerate GitLab’s roadmap
   3. Review the GitLab acquisition process including deal terms, as appropriate (acquisitions handbook)
   • TARGET TEAM: Ahead of this 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.

3. Share call summary Initial Acquisition Review Template (located in the Corp Dev shared drive under Acquisition Templates - GitLab internal-only) of companies that are aligned with GitLab’s acquisition strategy (“Qualified Pipeline”) with relevant product lead.

   • Create a new, private Slack channel (format: #acq-company_name) and add the internal GitLab document (“Main Acquisition Document”) to the topic. Add Chief Product Officer (CPO) and the relevant product and engineering leaders to help with the initial assessment of the opportunity.

4. Product call: If the Product Champion sees a potential fit and wants to proceed, set up an initial 90-minute product call to dive into the product and tech. The call must include the Product champion and may also include Stage Leaders and specific Product Managers relevant to the call. Stage Leaders and Product Managers should keep in mind the early stage of this evaluation and attempt to think expansively about how the potential acquisition could be additive to GitLab. The agenda for the call is:

   1. Product demo with highlights on key functionality and technologies
   2. Concise roadmap overview with a focus on near-term plans
   3. GitLab roadmap fit - discuss which features could be built into GitLab and into which product stage
   4. Start the discussion about what an integration into GitLab’s code base will look like

   A mutual NDA will be shared by GitLab and will be required to be signed prior to the Product Call. For more details about our MNDA and process for signing see GitLab Legal Handbook.

   The Corporate Development Deal Process Manager will schedule and send calendar invites for a GitLab internal only synchronous Product Call debrief for immediately after the Product Call, or first available time slot.

5. Initial internal review:

   1. Preliminary assessment of product and technology fit of the potential opportunity to GitLab’s product roadmap as well as integration options into GitLab.
   2. In certain instances, a hands-on product validation following the Product Call may be necessary to help inform the acquistion process and next steps. The Product Champion will select a DRI to perform a hands-on product validation. If a hands-on product validation does not occur following the Product Call, it will then occur later in the acquistion process during Early Diligence.
      1. Following the hands-on product validation, the Product Champion, DRI selected for hands-on validation and Corporate Development Champion & Deal Process Manager will meet sync to debrief on findings from the hands-on product validation and align on next steps.
         1. The Corporate Development Deal Process Manager will offer time to debrief on findings with the company being evaluated if the decision is to end the engagement following the hands-on product validation.
   3. Before moving to early technical diligence, the Product Champion will need to confirm annual fiscal budget with the Chief Product Officer and finance team.
      1. It is necessary to understand whether onboarding the target’s employees can be funded through existing or planned requisitions either within the Product Champion’s section, across the R&D budget or other operating expense reallocations. If not, budget must be secured by Product, with the help of Finance, before proceeding.
      2. This step is intended to optimize cross-functional collaboration and prevent a case where during final approval it is determined that budget does not exist for us to onboard the target’s employees, threatening the deal outcome.

Early Diligence

1. Select code name to use instead of target company name. Update Slack channel: #project-code_name.
   1. Corporate Development Deal Process Manager to create a dedicated Project for cross-functional collaboration and issue tracking. Make a copy and rename the New Project Diligence Template to get started.
2. Form the acquisition team and add the entire team to the channel and documents. +1. Confirm internal acquisition champion - every acquisition needs a lead champion; someone who is advocating for the acquisition, helping drive the acquisition rationale and a successful integration process. For most acquisitions that fit our approach, the champion will be a Product Section lead, at the Director+ level, accompanied by an engineering champion from the GitLab’s Engineering team, at the Director+ level, respectively. For other acquisitions, champions may come from other internal functions.
3. Create a dedicated technical diligence Slack channel #p-code_name-technical-diligence. This channel will be the main channel for communication on technical topics with GitLab’s development team.
4. Preliminary diligence - below is a list of documents to share with GitLab:
   1. Financials:
      1. Cap table
      2. Balance sheet
      3. Profit and Loss sheet
      4. Cashflow statement
      5. Tax returns
   2. Employees:
      1. Roster with: employee name, title, role, tenure, years of experience, location, salary, LinkedIn profile, programming language proficiencies, contributions to respective components and services in the codebase
      2. Employee resumes
      3. Employee agreements and PIAA
   3. Customer list with name, monthly revenue, contract termination date and any other fields if relevant.
   4. Vendor list with monthly spend
   5. Asset list:
      • Any assets that are needed for the business and will be part of the acquisition
      • Assets excluded from the acquisition
   6. Technical Bill of Materials (BOM) - a complete document which lists:
      1. Repositories
      2. Issue trackers / bug management systems
      3. Additional (non-code) assets
      4. Domain names
      5. Servers
      6. Dependencies
      7. Database schemas
      8. Data
      9. Trademarks
      10. Social media accounts
   7. Security Reports/Documentation
      1. External Security Reports
         • SOC 2
         • ISO 27001 Certification
         • CAIQ
         • External Penetration Testing Report
      2. Internal Security Documentation
         • Risk Management Program Documentation
         • Risk Register and status of risks
         • Results of security reviews the entity has performed over it’s current vendors
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, license compliance and more. That should be turned around within 2-3 business days.
      1. The Corporate Development Deal Process Manager will create a new document (Project [code-name] - Technical Diligence) for the Technical Call meeting notes, separate from the main acquisition document. Future diligence findings, and all other technical diligence related note-taking of meetings (external and internal), which are engineering-centric should be recorded in this Technical Diligence document, a separate and internal Google Doc from the main acquisition document. The Technical Diligence document will be bookmarked to the Slack channel topic of #p-code_name-technical-diligence
   2. Technical call: a hands-on product and code screen-share session (2 hours) in which the technical lead, as assigned by the respective Engineering champion, together with the respective Product champion will lead a screen-share session aimed at a hands-on validation of the product functionalities and an overview of the applications. The objectives and agenda for the call are:
      1. Objectives:
         1. Technically validate the functionalities and competencies of the product which have been presented throughout our process thus far
         2. Determine the value the acquisition can potentially add to GitLab
         3. Conclude a high level evaluation of the complexity and quality of the solution
         4. Identify blockers, challenges for the integration
      2. Agenda:
         1. Cover a more technical demo of the product; cover further questions/areas which surfaced following the Product Call
         2. Walkthrough of the architecture and the mechanisms of the product
         3. Review the core components/services/applications as well as development practices
         4. Start discussing the technical aspects of a potential path for the integration
      3. Internal notes of the call should be recorded in the Technical Evaluation Google Doc
      4. Access to proprietary code will not be asked at this stage. Code review will take part in the confirmatory due diligence phase.
6. Integration - a key component of post-transaction integration is the product integration strategy: prior to closing of the transaction, the GitLab product and engineering acquisition champions will formalize the integration strategy with a focus on feature sets/functionalities:
   1. What we keep as-is, rewrite, discard/EOL
   2. What is critical for user migration
   3. Target product tiers in GitLab
   4. Barriers for implementation
   5. Deal Milestones:
      1. We aim to set 3 milestones at 2, 4 and 6 months from joining GitLab, to provide a concise set of goals which should cover the bulk of our product interest in the target company
      2. Milestones should be articulated as objectives as opposed to tasks. The structure of defining milestones should resemble that of OKRs, with each milestone having an objective and then a few key results which will be required to achieve the objective. This will help target companies focus on driving the objectives and not be tied to, and concerned with, a specific task as changes are likely to occur once integration work starts. The milestones outline the objectives to facilitate the work required in achieving the roadmap advancement the deal was identified with delivering. Each milestone should be broken down to the keys required to complete in order to achieve success for the milestone’s objective.
         1. Include GitLab Legal on Milestone formation discussion threads and synchronous calls to help ensure that Milestone language is meets GitLab Legal’s level of specificity and clarity.
      3. First milestone shipped within 60 days of joining GitLab:
         1. Accounting for 3 weeks of onboarding, targets will ship the first milestone 5 weeks following the end of the onboarding period
         2. Critical to adopting our culture and successful future integration of the target’s engineering team in GitLab
         3. Allows us to show early fruits of the acquisitions soon, aligned with our value of iteration
      4. Product is integrated within 6-9 months:
         1. 6-9 months is an optimal timeframe which allows for incremental integration of the target’s functionality, covering its entirety at best or its fundamentals at the very least, while not being overly extended. We would want to refrain from using a longer time frame as our roadmap priorities may change such that we could potentially find ourselves abandoning certain milestones, negating some or all of the rationale behind the deal.
         2. Will help establish focus on both acquired target and our product team
         3. Be able to complete post-closing payouts (if any earned and due) to the target’s entity and shut it down as soon as practicable and in accordance with the terms of the deal documents
      5. At least one milestone will focus on developing new functionality which will be based on the integration delivered in earlier milestones
7. To determine the deal ROI, the acquisition team will perform the analysis using the applicable model as well as the acquisition NPV calculator (internal GitLab document).
8. Early People-Ops review
   1. The Corporate Development Deal Process Manager will create a new Slack channel topic of #p-code_name-people and include the People-ops Champion (VP of People-Ops) and a Talent Acquisition Lead. The People-ops Champion may request that the Corporate Development Champion and Process Manager bring in designated People-ops team-members as needed.
      1. Employee roster review
         1. Set your own LinkedIn profile to private mode viewing when reviewing target employee profiles. Private mode viewing will prevent target employees from being alerted to GitLab’s examination of their LinkedIn profiles.
      2. Compensation review - to identify any gaps and possible flags led by the HR Business Partner
      3. Founder technical interviews - founder(s) will go through two rounds of interviews to assess technical and cultural alignment.
         1. The founder interview differs in style and objective of a traditional new hire interview. Interviewers will be asked to review the Interview Preparation Direction in advance of meeting with the founder(s).
9. An Application Security Review performed by GitLab’s Application Security Team
   1. Identifies application vulnerabilities that need to be considered by GitLab by applying a threat modeling approach to conduct the review
10. Presenting the business case for approvals (by order of occurrence):
    1. Champions’ approval: The acquisition team will review the business case together and approve the suggested deal. This includes approval of all the following:
       1. Complete executive summary (with link to term sheet draft) including budget and headcount allocation for the acquisition
       2. Complete business case templates (see Corp Dev shared drive for both - GitLab internal-only) including Deal Milestones
       3. Complete term sheet (template) draft with proposed details (asset payment, retention bonuses, Deal Milestones, closing schedule, customer termination and closing conditions) filled in.
    2. Functional approvals: The Corporate Development, Product and Engineering Champions will present the business case for acquisition to the CPO, CTO and CRO. They will review to approve the items listed in the Champions’ approval (complete: executive summary, business case, term sheet)
    3. CEO, CFO and CLO approvals: The Corporate Development, Product and Engineering Champions will present the business case for acquisition to the CEO, CFO and CLO. This meeting will also capture the explicit approval of the term sheet to start negotiations.
       1. Approval of term sheet to start negotiations will be tracked in a term sheet approval issue. We don’t include any financial and milestone information in the approval tracking issue for confidentiality reasons.
11. Term Sheet:
    1. Once the terms to start negotiations have been approved, the Corporate Development Deal Champion will reach out to the target company to share the offer and term sheet.
    2. Once an agreement on terms with the target has been reached, the term sheet (with any changes) will be brought forward for approval from: CLO, CFO, CEO (in that order). These approvals will be captured in the term sheet approval issue.
    3. Once all approvals have been obtained, the Corporate Development Champion will stage the term sheet for signing on DocuSign for target CEO and GitLab CEO (in that order). Add CLO, CFO, and CPO on Cc on the agreement.
       1. Approval tracking will be tracked on the term sheet approval issue mentioned earlier. Any changes to previously-approved terms need to be reviewed and approved once more by the following: Product champion, Engineering champion, CPO, CTO, CLO, CFO, CEO. The changes should be referenced on the term sheet approval tracking issue before seeking approvals.

Confirmatory Due Diligence

1. To kick-off the Due Diligence stage, the Corporate Development Deal Process Manager emails the target company CEO with the following clarifications and information requests:
   1. All employees and their profiles will be reviewed by the GitLab team
   2. The employees who will be invited for interviews will go through GitLab’s standard interview process
   3. Key employees 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. The Corporate Development Deal Process Manager will create an engagement debrief and lessons learned document and share it with the team for on-demand capturing of insights.
3. Document who is read-in on the project and work with GitLab Legal to circulate a Read-in Acknowledgement form to sign and return.
4. Complete Technical diligence
5. Complete financial diligence
6. Legal diligence - Once both the technical and the financial diligence have been completed and signed off by the Engineering champion and Finance acquisition team member, respectively, the Corporate Development Deal Process Manager will contact legal to start the legal diligence. Legal will tag the relevant owners for each of the diligence tasks in the (template diligence table (see Corp Dev shared drive - GitLab internal-only) in the main acquisition doc.
7. The progress of the diligence will be synced on a regular stand-up call with the acquisition team
8. The Corporate Development Champion and the legal lead negotiate the definitive deal documentation with the target company CEO and legal team
9. Key employee retention conversations - to increase the success rate of the deal and integration plan, we may request to conduct retention conversations for the key technical employees identified. 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.
10. Final review and approval:
    1. Conclusive call - Final internal review call with the acquisition team to recap the acquisition as a whole, review the acquisition agreement and present a final recommendation. This meeting will also capture the explicit approval of the acquisition agreement from the CLO, CFO and CEO. Approvals from the call as well as additional required approvals will be tracked using the definitive agreement approval issue template.
    2. BoD approval:
       1. Legal will facilitate the final deal approval from GitLab’s Board of Directors
       2. A board package will be shared with the BoD members before requesting their approval. It should include:
          1. Executive summary email:
             1. Will be sent to the BoD members by the CEO
             2. The Corporate Development Champion and Deal Process Manager will create a 1-2 page executive summary email message. It should include a high level coverage of the following topics:
                1. Deal details and rationale (including roadmap acceleration, projected revenue gain)
                2. Expertise of team joining
                3. Key terms for the APA and any additional costs
                4. Diligence conducted: legal, tax, financial, technical, people
                5. Known risks, indemnification conditions as well as representations and warranties
          2. Link to final version of APA
11. The Corporate Development Champion will coordinate the signing and closing of the deal

Integration

The Corporate Development team is responsible for overseeing and facilitating the post-closing integration, working closely with Legal, Product, Engineering, People, Finance, and other GitLab divisions as appropriate. The DRI is the Senior Director Corporate Development.

The integration process is outlined in our acquisition integration page.

Terminated Acquisition Engagements

1. If the acquisition has advanced past the Technical Call, conduct a retrospective:
   1. Create a retrospective issue (GitLab internal-only example)
   2. Set time for an optional live sync
   3. Solicit feedback on all related acquisition channels
   4. Once sync has completed, continue with the steps below.
2. The Corporate Development Deal Process Manager will archive all slack channels associated with the acquisition.
3. In accordance with the signed NDA, the GitLab Corporate Development Champion and Deal Process Manager, and all other deal participants in possession of preliminary and confirmatory deal diligence materials, will make best effort to remove the materials from GitLab’s internal drives and repositories.

Acquisition Team

The primary acquisition team is designed as a compact unit, and will consist of the following GitLab functional team members:

1. Corporate Development Champion - VP of Corporate Development
   1. Corporate Development Deal Process Manager - Corporate Development Manager
2. Product Champion - Product Section Leader (reporting to the Chief Product Officer)
   1. Product Manager
3. Engineering Champion - Dir. Engineering
   1. Engineering team member
4. VP, People Operations
5. Legal, Corporate lead

The primary acquisition team will engage with other functions and roles as needed:

1. VP Finance and Business Technology
2. VP Tax
3. Principal Accounting Officer
4. People Business Partner
5. VP Talent Acquisition
6. VP of Security

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 engineering team member, contact the engineering manager of the relevant category for assignment.

Acquisition Team Responsibilities

Acquisitions Are Confidential

At GitLab, we treat all acquisition discussions as confidential and share any information internally on a need-to-know basis. We apply compartmentalization for the various topics coming up during the acquisition process in order to maintain confidentiality and reduce unnecessary exposure.

To ensure confidentiality during the acquisition process, we assign code names to each potential transaction once we enter the Early Diligence stage. Project name themes are defined by GitLab Legal, Corporate Development’s theme is Movie / TV Show characters.

To maintain confidentiality, we follow the following guidelines:

1. When creating a new acquisition slack channel:
   1. Set the channel topic to: “This channel is confidential. Please confirm with Corporate Development Champion or Deal Process Manager name here before inviting people to the channel or related docs.”
   2. Set the channel description to: “Please review our acquisition handbook and process to familiarize yourself with our approach to acquisitions. Please review the confidentiality section of the process and our guidelines”.
2. We strive to keep the number of people involved in an acquisition as small as possible to reduce legal exposure and maintain a low potential risk of deal and information disclosure. If more members are required to be brought into the acquisition for a discussion limited to a specific topic, and do not need to be involved with the wider engagement, we create dedicated, single-topic channel, and add the relevant parties to it.
3. If you’re part of an acquisition Slack channel, Google Doc, or other internal GitLab discussion and would like to invite another GitLab team member to one of those, please confirm with the Corporate Development Champion or Deal Process Manager before doing so.
4. We collect all notes on an acquisition in the main acquisition doc shared on the topic of the acquisition’s slack channel. If you must create a new document, make sure it is set to invite-only and add the relevant people manually. That document needs to be kept inside the acquisition G-Drive folder on the Corporate Development Shared Drive.
5. Everyone involved in the project should use the code name in place of the actual company name in all communication about the deal until it is publicly announced.

Shared Slack Channels with Targets

If and when our team and the target’s would like to open a shared Slack channel for streamlined communication, please engage Corporate Development for that purpose so that we can ensure we have persistent process visibility.

Social Media

As an operating principal, all team members are advised not to accept social media invites or follow requests (LinkedIn, Facebook) from individuals at companies with which we are actively engaged in acquisition discussions. Third-parties can view these connections and deduce that GitLab is having, or has had, discussions relating to M&A or investments.

If you have an existing connection, or a regular cadence of interaction, with a company that then becomes engaged in M&A discussion with GitLab you do not need to disassociate. The spirit of this guidance is intended to keep the status-quo and not create the perception of change in relationship between GitLab and the company being evaluated.

Prioritizing Acquisition Opportunities

Each quarter the Corporate Development team defines a set of three categories which are prioritized for that quarter for outbound activity. We commonly refer to them as Quarterly Focus Areas. While this is true especially for our outbound efforts, these categories will be at the center of our overall efforts and focus for that quarter, taking into account inbound prospects as well.

Although we have our quarterly focus areas, we are open to discussing and potentially pursuing an opportunity outside of those focus areas. For us to look into an opportunity outside of our quarterly focus areas, it needs to satisfy one, or more, of the following criteria:

1. Present an outsized revenue potential
2. Serve as a strategic move (market dynamics etc.)

Every opportunity we explore is constantly evaluated against our prioritization as well as our bandwidth (including active engagements).

If you wish to propose an opportunity you believe we should pursue and is outside of our quarterly focus areas, please contact the Corp Dev team with the rationale behind that specific opportunity.

View page source - Edit this page - please contribute.