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.
Share call summary (Initial Acquisition Review Template, a GitLab internal document) 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 to the top. Add EVP Product and the relevant product and engineering leaders to help with the initial assessment of the opportunity.
If product management lead sees a potential strategic fit and wants to proceed, set up initial product and tech call to learn about the product (demo, roadmap), technology and team. Discuss which features could be built into GitLab and into which GitLab product stage.
Initial internal review: preliminary assessment of product and technology fit of the potential opportunity to GitLab's product roadmap as well as integration options into GitLab. If the product lead is supportive of moving forward towards developing a more in depth business case, confirm whether the proposed acquisition can be funded with planned headcount allocations. Otherwise, set up a discussion with EVP Product before proceeding with further diligence.
Select code name to use instead of target company name. Update Slack channel: #acq-code_name.
Confirm internal acquisition champion - every acquisition needs a lead 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, 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.
Preliminary financial & legal diligence - list of preliminary documents to share with GitLab:
Employee roster with: employee name, title, role, tenure, years of experience, location, salary, LinkedIn profile, programming languages proficiency
Employee agreements and PIAA
Customer list with name, monthly revenue, contract termination date and any other fields if relevant.
Vendor list with monthly spend
Any assets that are needed for the business and will be part of the acquisition
Assets excluded from the acquisition
Early technical diligence:
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.
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.
Resume review - Review of all employee resumes
Compensation review to identify any gaps and possible flags led by the HR Business Partner
Optional interviews for the key technical employees - to increase the success rate of the deal post-Term Sheet, we recommend conducting interviews for the key technical employees identified before signing the Term Sheet. This will greatly reduce the likelihood of personnel gaps becoming a blocker during the Confirmatory Due Diligence stage. The interviews will include a technical interview and a manager interview as detailed in the Confirmatory Due Diligence stage below.
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.
Product integration strategy: the GitLab product and engineering acquisition champions will formalize the integration strategy with a focus on feature sets/functionalities:
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
Integrated within 6 months:
6 months is an optimal timeframe which allows for incremental integration of the target's functionality, covering its entirety at best or its fudemantals 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.
Will help establish focus on both acquired target and our product team
Be able to complete payouts to the target's entity and shut it down sooner
First milestone shipped within 30 days of joining GitLab:
Critical to adopting our culture and successful future integration of the target's engineering team in GitLab
Allows us to show early fruits of the acquisitions soon, aligned with our value of iteration
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.
Presenting the business case for approvals (by order of occurence):
Champions' approval: The acquisition team will review the business case together and approve the suggested deal. This includes approval of all the following:
Complete executive summary (with link to term sheet draft) including budget and headcount allocation for the acquisition
Complete businees case (templates for both) including Deal Milestones
Complete term sheet (template) draft with proposed details (asset payment, retention bonuses, Deal Milestones, closing schedule, customer termination and closing conditions) filled in.
Functional approvals: The corporate development acquisition lead, Dir. Product and Dir. Engineering will present the business case for acquisition to the EVP Product and EVP Engineering. They will review to approve the items listed in the Champions' approval (complete: executive summary, business case, term sheet)
CEO, CFO and CLO approvals: The corporate development acquisition lead, Dir. Product and Dir. Engineering (deal 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 negotations.
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.
Once the terms to start negotations have been approved, the corporate development acquisition lead will reach out to the target company to share the offer and term sheet.
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.
Once all approvals have been obtained, the corporate development acquisition lead will stage the term sheet for signing on HelloSign for target CEO and GitLab CEO (in that order). Add CLO, CFO, and EVP Product on Cc on the agreement.
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: Dir. Product, Dir. Engineering, EVP Product, EVP Engineering, CLO, CFO, CEO. The changes should be referenced on the term sheet approval tracking issue before seeking approvals.
Confirmatory Due Diligence
To kick-off the Due Diligence stage, the corporate development acquistion lead emails the target company CEO with the following clarifications and information requests:
All employees and their profiles will be reviewed by the GitLab team
The employees who will be invited for interviews will go through GitLab's standard interview process
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
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.
The progress of the diligence will be synced on a regular stand-up call with the acquisition team
The corporate development acquisition lead and the legal lead negotiate the definitive deal documentation with the target company CEO and legal team
Final review and approval:
Recap call - Final internal review call with the acquisition team to recap the acquisition as a whole and present a final recommendation
CEO approval - Log the approval from CEO over email, with cc to our CLO (Chief Legal Officer)
BoD approval - Legal to seek final deal approval from GitLab's Board of Directors
The corporate development acquisition lead will coordinate the signing and closing of the deal
The Corporate Development team is responsible for overseeing and facilitating the integration of the acquisition post-closing, working closely with Legal, Product, Engineering, and Finance. The DRI for the integration stage is the Dir. Corporate Development. This will consist of several aspects and best practices:
Operational shutdown (if appropriate):
Execution of customer sunset plans
Shutdown of target company and its entities
Alignment on objectives and goals:
Incorporate the integration plan into GitLab's roadmap
Introduce Deal Milestones into respective departmental OKRs
Create or update product vision in case a new product area is added to GitLab
People & Culture:
Cultural integration plan, analyzing similarities and differences in the two companies' cultures
Onboarding of acquired team members
Identify and continuously revisit business performance metrics to track the deal's added value and ROI over time
Delivery against product plans and OKRs
An acquisition team will consist of the following GitLab functional team members:
Dir. Corporate Development - acquisition lead
Dir. Product Management
Engineering team member
Finance / accounting team member
Legal team member
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 engineering team member, contact the engineering manager of the relevant category for assignment.
Acquisition Team Responsibilities
1. Main POC for acquired team 1. Identify potential areas for integration 1. Create case for acquisition and customer transition story 1. Integration
1. Business case with deal structure
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. Lead financial diligence 1. Validate business case and deal structure
1. Review entity, assets and existing agreements 1. Evaluate sunset and customer transition path
1. Term Sheet 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, Google Doc, 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.
To ensure confidentiality during the acquisition process, we assign code names to each potential transaction once we enter the Early Diligence stage. 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.