This is a detailed view of our acquisition process. For more information about our acquisitions approach visit our acquisitions handbook.
The process is comprised of five key stages:
#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.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.
#project-code_name.#code_name-technical-diligence. This channel will be the main channel for communication on technical topics with GitLab's development team.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 #code_name-technical-diligenceThe 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.
The primary acquisition team is designed as a compact unit, and will consist of the following GitLab functional team members:
The primary acquisition team will engage with other functions and roles as needed:
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.
| Function | Role | Deliverables | |
|---|---|---|---|
| Corporate Development | 1. Main POC for acquired team 1. Identify potential areas for integration 1. Create case for acquisition and customer transition story 3. Integration |
1. Business case with deal structure | |
| Product | 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. Product integration strategy | |
| Engineering | 1. Technical diligence | 1. Code quality review 1. Integration strategy validation - feasibility and timeline | |
| Finance | 1. Lead financial diligence 2. Validate business case and work with tax team to validate deal structure |
||
| Legal | 1. Review entity, assets and existing agreements 2. Evaluate sunset and customer transition path |
1. Term Sheet 1. Acquisition agreement and ancillary deal documents | |
| People Group | 1. Maintain SSOT for team member data 2. Lead the compensation review 3. Lead the interview process during the early and due diligence stages to completion 3. Lead and assess successful team member integration in partnership with business |
1. Team Member Offers of employment 2. Onboarding experience 3. Post acquisition survey and action planning |
|
| Security | 1. Identify and summarize Security Risk Posture as part of Early Diligence 2. Perform Application Security review |
1. Security Risk summary detailing the security risk impacts to GitLab |
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:
name here before inviting people to the channel or related docs."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.
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:
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.