Acquisition Integration

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

Overview

Integration planning begins well before a transaction closes. At the appropriate time during the deal process, the Sr. Dir. Corporate Development, the DRI for the integration stage, will help facilitate the integration between the relevant divisions and functions involved. To accomplish that, an integration working group (IWG) will be established with representatives from divisions across GitLab (e.g., Finance, Legal, Product, Engineering, People, etc.).

Importantly, each integration will have an executive sponsor from the E-Group as well as two additional DRIs:

1. Roadmap DRI - the Product Champion for the acquisition, will be responsible the direction, impact, scope, and alignment of the integration
2. Engagement DRI - the Engineering Champion for the acquisition, will be responsible for the implementation of the technical integration milestones and retention of the acquired team members within GitLab.

We use the deal documents, findings from diligence and other data and information to establish a written Day 1 Plan and Long-Term Plan. The former documents what exactly needs to occur or needs to be in place on Day 1 following the closing of the transaction. The Long-Term Plan includes key milestones developed as part of the Acquisition Process. Each of the subject matter experts on the IWG identifies what needs to be done in advance of, and on, Day 1 and for the period during which the Long-Term Plan is effective until integration is complete.

The IWG will meet regularly (cadence will be determined on a deal by deal basis) and the IWG members will use that time to discuss issues or other items that could impact integration. Integration is iterative, as such the IWG revises the integration plan as necessary while making sure all stakeholders are aware of the revisions and updates, as appropriate.

Examples of areas and tasks, some of which are determined by deal structure and deal documents, that may be part of the post-closing integration process include:

Communications

1. It is important that the new team members know who to contact with questions and it is also important for there to be “one voice” communicating with the new team members. Pre-closing, that “one voice” is the deal lead, and post-closing it is a team comprised of the applicable team members who are the subject matter experts or leads. Using the “one voice” approach helps ensure all communications are coordinated, and the messages are consistent and timely. In the case of pre-closing and closing matters, the deal lead works, as appropriate and permissible, with the target company’s CEO and other senior management in communicating with the target company employees as part of the deal announcement.
2. The deal lead is responsible for working with the target company in connection with coordinating (as appropriate and permissible) communications and messages to the target company’s customers. The timing and nature of the communications depends on the structure of the transaction and the terms related to customer communications set forth in the deal documents.
3. See the Acquisition Process Communications Handbook Page for further direction.

Strategic Objectives and Performance Tracking

1. Alignment on objectives and goals:
   1. Incorporate the integration plan into GitLab’s roadmap
   2. Introduce Deal Milestones into respective departmental OKRs
   3. Create or update product vision in case a new product area is added to GitLab
2. 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

Finance, Accounting & Tax

1. Open, close or transfer bank accounts, as necessary, and update signing authority if appropriate.
2. Change/update remittance on invoices, if necessary.
3. Reconcile accounts payable and accounts receivable and transition the same to GitLab’s systems, if appropriate.
4. Notify target company vendors, as necessary, and by any required deadline.
5. Work with the People team to onboard new team members to the GitLab payroll system.
6. Log any deal-specific payroll and other considerations into our systems

Legal

1. Track and manage all post-closing deadlines, deliverables, escrow release, post-closing notices required by customers and/or vendors, etc.
2. Work with appropriate team members to address issues and items identified during diligence and the deal process.
3. Operational shutdown of target company if, as and when appropriate or as specified in the deal documentation.
4. Organize and obtain the closing binder related to the acquisition and upload to ContractWorks.
5. Work with target company’s counsel for a smooth transition, as appropriate and permissible, of legal matters from target company’s counsel to GitLab legal.

Technical integration

1. Each delivery milestone which is defined in the acquisition agreement or ancillary deal documents will be converted to a confidential issue by the PM leading the integration efforts, once the acquisition announcement has been made public. These issues will be the SSOT to track progress on a delivery milestone. Once an issue is completed, it will serve as a confirmation of a successful delivery of that milestone. Signoff for completion of a milestones is required by:
   1. Product champion
   2. Engineering champion
   3. Corp. Dev. champion
2. Once a milestone has been signed-off, the Corp. Dev. champion will notify the accounting team if there is a consideration payment which needs to be processed
3. Check-in calls (cadence (e.g., weekly, bi-weekly, monthly, etc.) will be determined on a deal by deal basis) will be scheduled by the PM leading the integration efforts with the following team members:
   1. Product and engineering champions
   2. Corp. Dev. champion
   3. Main engineer leading the integration efforts from the acquired company
   4. Legal
4. Changes to milestones - integration milestones are subject to changes as we work towards accomplishing them. As these milestones may have contractual obligations and impact wider product vision ambitions, any and all changes to milestone language have to be approved by the three deal champions: corp dev, product and engineering. Changes to milestones may require amending the acquisition agreement, in which case, the appropriate team members and contacts for the target company will be included in such discussions, as necessary. Changes that do not require approval and/or amending the acquisition agreement may be addressed async but in general it is preferred to discuss changes during the regular check-in call noted above.

Fastboot

To facilitate an effective, efficient and positive onboarding for the team, a fastboot should be planned within the first month of the team’s onboarding to GitLab:

• Purpose:
  • Build a social connection between both teams
  • Align both respective teams on the technologies in place, both from GitLab as well as the target
  • Fully develop the work plan for the integration
• Budget: will need to be structured as part of the acquisition process prior to the Closing of the deal
• Format for the fastboot can be found here (GitLab internal-access only)

People Integration

1. Onboarding of target team members (as specified in the deal documents) using the GitLab onboarding issue.
2. Ensure all new team members are on the GitLab payroll system as of Day 1, which will require contacting the payroll provider well in advance of Day 1.
3. Confirm with target company that the target company’s employee benefits vendors are aware of the pending closing and ensure all target team members (as specified in the deal documents) timely receive information regarding benefits. All such benefits to be provided post-closing must comply with any relevant terms set forth in the acquisition agreement.
4. Identify any particular training courses (in addition to those in the GitLab onboarding issue) needed for the new team members.
5. Address any change of control issues present in any employment agreement and which have an impact post-closing; unless otherwise specified in the acquisition agreement, the target company is generally responsible for such issues, subject to the terms of the applicable employment agreement.
6. During the first 12 months after the team members join GitLab, the People Ops team will administer two pulse surveys to assess integration. The first Acquisition Integration Survey will be released on or about the three month anniversary of closing and the second pulse Acquisition Integration Survey will be released on or about the nine month anniversary of the closing.
7. Internal Transfers - For any internal team members that wish to transition to/apply for roles on acquired teams, hiring managers should be particularly diligent about reviewing context and information pertaining to the acquisition details, charter, milestones, goals, etc. Acquired teams, particularly in early stages, can operate differently than a typical team at GitLab in that the first 6-12 months (or more) of work given that the milestones and directions are pre-defined as part of the acquisition agreement. We want to ensure full transparency is maintained with team members who transition in an effort to set them up for success.

Field enablement

Sales and Marketing Messaging

Sales and marketing of the target company product(s) covers three different areas, which are:

1. Messaging

The GitLab Field and Marketing organizations have aligned on a go-to-market approach based on a standard and consistent customer value-based messaging framework. As such, the Acquisition Integration team should partner with Product Marketing and document the following:

1. What customer value driver(s) does this acquisition augment and how?
2. How does this acquisition augment GitLab’s differentiators and/or introduce new ones?
3. How does this acquisition augment our existing customer use cases?

2. Role-based learning objectives

After the value-based messaging has been completed, partner with the Field Enablement team to define role-based learning objectives. To get started, the team should answer the below questions for Sales Development Reps and each field role (e.g. Account Executive / Strategic Account Executive, Channel Sales Manager, Solution Architect, Customer Success Manager, Professional Services Engineer) as it relates to the acquisition:

1. Knowledge gaps: What does that role need to KNOW that they may not know today?
2. Behavior gaps: What does that role need to be able to DO, ARTICULATE, and/or SHOW that they may not be able to today?

3. Enablement Development

Once the above is completed, the team proceeds to enablement development and execution. Below is our standard enablement assets for acquisitions. The acquisition team should evaluate the list below and any changes or additions to it specific to the acquisition at hand.

1. Snapshot video - Ahead of the announcement, the Product champion will record a short video (up to 10 minutes) which will be included as part of the PR for the acquisition as well as a resource for enablement for the GitLab team. The video should cover the following points:
   1. An overview of the categories the acquisition is relevant for
   2. Why these categories are important to GitLab’s users and how they fit
   3. What value will the completed integration of the acquisition deliver to our users
   4. The impact the integration can have on our users
2. Prospect FAQ - A prospect FAQ document will be created answering questions which are likely to come up from our customers
3. Overview webcast - A webcast for our field teams will be scheduled 1-2 months from announcement providing a more in-depth overview of the acquisition and its impact for our product, customers and prospects.
4. Technical webcast - Scheduled around the delivery of the MVC of the integration efforts, a technical webcast for our field teams will be scheduled to provide a demo of the new functionality and new product workflows.
5. Field Communication Plan - Field Communications will work with the Product DRI to create a communications plan using the Field Communication Playbook that disseminates key resources and information to field team members.

4. Digital Experience (DEX) Ownership of Acquired Company Website

The Digital Experience Team is responsible for the updated website banner of the acquired company announcing the acquisition if the communication plan is to publicly announce the deal. See the Communications Acquisition Process for additinal detail. At deal close, DEX will also coordinate with GitLab Communications and Corporate Development to align on the acquired company’s website takeover and ownership. An issue will be opened and owned by the Corporate Development Deal Process Manager to address and coordinate the website takeover and ownership by DEX. In addition to ensuring DEX has secured the necessary website credentials from the acquired company, example matters to consider and track will include:

1. Do we wish to deprecate the acquired company’s website?
   1. If yes, on what date?
2. Do we want certain pages of the acquired company’s website to redirect?
   1. If yes, to where? And on what date?

Document Management Process

• Pre-closing documents will be stored on Google Drive and made accessible to those involved with the prospective acquisition process.
• Upon closing, a member of the Legal & Corporate Affairs team will be responsible for organizing and obtaining the closing binder related to the acquisition.
• Once received, the Legal Operations team will upload the binder as well as the rest of the documents in the original Google Drive folder into a new folder in ContractWorks.
• Each month a Reconciliation Issue will be created for the previous month, included in this Issue will be an obligation from Corporate Counsel to confirm either, (i) there are no Agreements for the previous month, or (ii) all executed Agreements have been provided to the Legal Operations Team Member(s) for upload.