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

Acquisition Group


The Acquisition Group is part of the Growth section and is responsible for promoting the value of GitLab and accelerating site visitors transition to happy valued users of our product.

Questions should start by @ mentioning the Product Manager for the Acquisition group or create an issue in the Growth issues board.

How we work


We use the Engineering workflow when working on issues and merge requests across multiple projects.


We plan in monthly cycles using milestones following the Product development timeline. To ensure we adhere to this monthly cycle, we pay special attention to these dates:

Planning and Prioritization

We plan and groom issues in advance of finalizing a milestone commitment on M-1, 13th and before beginning development on M-1, 18th.

We tag each issue with the correct milestone, viewable on the milestone board

At times a single deliverable will be broken in to mutliple issues. One of these issues should be labelled as the Deliverable while the other issues are dependencies and are linked to the Deliverable issue. Once all dependency issues have been delivered, the issue with the Deliverable label can be closed. Deliverables by milestone are viewable on the milestone deliverables board.

Prioritization is a collaboration between Product, UX, Data, and Engineering. We use the ICE framework for experiments. Each Deliverable issue will have an ICE score.


We use a light-weight estimation process using a fibonacci scale with a maximum weight of 5. Anything over a 5 (large) indicates the work should be broken down into smaller, clearly defined issues.

Weight Description (Engineering)
1 Trivial: The simplest possible change. We are confident there will be no side effects.
2 Small: A simple change (minimal code changes), where we understand all of the requirements.
3 Medium: A simple change, but the code footprint is bigger (e.g. lots of different files, or tests effected). The requirements are clear.
5 Large: A more complex change that will impact multiple areas of the codebase, there may also be some refactoring involved. Requirements are understood but you feel there are likely to be some gaps along the way.

In planning and estimation, we value velocity over predictability. The main goal of our planning and estimation is to focus on the MVC, uncover blind spots, and help us achieve a baseline level of predictability without over optimizing. We aim for 70% predictability instead of 90%. We believe that optimizing for velocity (MR throughput) enables our Growth teams to achieve a weekly experimentation cadence.

Milestone Commitment

A milestone commitment is a list of issues our team aims to complete in the milestone.

Our milestone commitments are based off of our team's estimated capacity, which is the sum of issue weights completed in the last milestone. If there's too much variance between the last milestone and the one before it, we will use an average of the last few milestones.

In the planning phase, once issues are groomed, estimated, and prioritized, we begin loading issues into the milestone commitment until the sum of the loaded issue weights equals our team's estimated capacity. The loaded issues are our milestone commitment. Each issue should be labelled with the correct milestone along with a Deliverable or Stretch label. The top 70% of a milestone's issues should be labelled as Deliverable while the remaining 30% of issues should be labelled as Stretch. Read more about how these labels are used

Tracking Milestone Progress

Our primary method of tracking milestone progress is through our workflow board. We keep all issues up to date with the correct workflow labels. Any time the status of an issue changes, we add a detailed comment in each issue providing additional context.

Measuring Engineering Throughput

One of our main engineering metrics is throughput which is the total number of MRs that are completed and in production in a given period of time. We use throughput to encourage small MRs and to practice our values of iteration. Read more about why we adoped this model.

We aim for 10 MRs per engineer per month which is tracked using our throughput metrics dashboard.

Daily Standups (Async)

We have daily asynchronous standups using status hero's Slack integration. The purpose of these standups are to allow team members to have visibility into what everyone else is doing, allow a platform for asking for and offering help, and provide a starting point for some social conversations.

Three questions are asked at each standup:

Meetings (Sync)

We hold synchronus meetings twice a week on Mondays 03:30pm UTC and Wednesdays 03:30pm UTC. These meetings are used to additional gain clarity and alignment on our async discussions.

Team Members

The following people are permanent members of the Acquisition Group:

Person Role
Jerome Ng Engineering Manager, Growth:Acquisition and Conversion
Alex Buijs Senior Fullstack Engineer, Growth:Acquisition
Nicolas Dular Senior Fullstack Engineer, Growth:Acquisition
Alper Akgun Senior Fullstack Engineer, Growth:Conversion