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

Growth Sub-department

FY2021 Direction

Develop a respectful and privacy focussed data collection framework that allows us to make informed product decisions which improve the way our customers sign up to GitLab, manage and renew their licenses, and upgrade their accounts to higher tiers.


The Growth sub-department consists of groups that eliminate barriers between our users and our product value.

Managing customer licensing and transactions

The Fulfillment Group is responsible for:



Deliver telemetry data that improves our product

The Telemetry Group is responsible for:



Drive value for the business and our users by improving activation, retention, upsell, and per-stage adoption

We focus on validating ideas with data across the following four Groups:

Acquisition Group

Conversion Group

Expansion Group

Retention Group

We work closely with the Data Team along with our Product Team counterparts to design and implement experiments that measure the impact of changes to our messaging, UX, and overall experience of using GitLab.


The Growth sub-department uses the ~"devops::growth" label and the following groups for tracking throughput and ownership of issues and merge requests.

Group name Group label
Fulfillment ~"group::fulfillment"
Telemetry ~"group::telemetry"
Acquisition ~"group::acquisition"
Conversion ~"group::conversion"
Expansion ~"group::expansion"
Retention ~"group::retention"


The following people are permanent members of the Growth sub-department:

Person Role
Bartek Marnane Director of Engineering, Growth
James Lopez Engineering Manager, Fulfillment
Chris Baus Frontend Engineering Manager, Fulfillment and Telemetry
Jerome Ng Engineering Manager, Growth:Acquisition and Conversion and Telemetry
Phil Calder Engineering Manager, Growth:Expansion and Retention

All Team Members

The following people are permanent members of groups that belong to the Growth sub-department:


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


Person Role
Jerome Ng Engineering Manager, Growth:Acquisition and Conversion and Telemetry
Alper Akgun Senior Fullstack Engineer, Growth:Conversion
D.R Fullstack Engineer, Growth:Conversion


Person Role
Phil Calder Engineering Manager, Growth:Expansion and Retention
Jackie Fraser Fullstack Engineer, Growth:Expansion
Doug Stull Senior Fullstack Engineer, Growth:Expansion


Person Role
Phil Calder Engineering Manager, Growth:Expansion and Retention
Jeremy Jackson Senior Fullstack Engineer, Growth:Retention
Jay Swain Senior Fullstack Engineer, Growth:Retention

Fulfillment Backend

Person Role
Rubén Dávila Backend Engineer, Fulfillment
James Lopez Engineering Manager, Fulfillment
Corinna Wiesner Backend Engineer, Fulfillment
Tyler Amos Senior Backend Engineer, Fulfillment
Shreyas Agarwal Senior Backend Engineer, Fulfillment
Vladlena Shumilo Backend Engineer, Fulfillment

Fulfillment Frontend

Person Role
Vitaly Slobodin Senior Frontend Engineer, Fulfillment
Chris Baus Frontend Engineering Manager, Fulfillment and Telemetry
Ragnar Hardarson Senior Frontend Engineer, Fulfillment
Ammar Alakkad Frontend Engineer, Fulfillment

Telemetry Backend

Person Role
Jerome Ng Engineering Manager, Growth:Acquisition and Conversion and Telemetry
Alina Mihaila Backend Engineer, Telemetry

Telemetry Frontend

Person Role
Chris Baus Frontend Engineering Manager, Fulfillment and Telemetry

Business Continuity - Coverage and Escalation

The following table shows who will provide cover if one or more of the Growth Engineering management team are unable to work for any reason.

Team Member Coverered by Escalation
Bartek Marnane Christopher Lefelhocz Eric Johnson
Chris Baus James Lopez Bartek Marnane
James Lopez Chris Baus Bartek Marnane
Jerome Ng Phil Calder Bartek Marnane
Phil Calder Jerome Ng Bartek Marnane

If an Engineer is unavailable the Engineering Manager will reassign open issues and merge requests to another engineer, preferably in the same group.

Some people management functions may require escalation or delegation, such as BambooHR and Expensify.

This can be used as the basis for a BCP Communication Plan and Role Assignments, as well as a general guide to Growth Engineering continuity in the event of one or team team members being unavailable for any reason.

Stable Counterparts

The following members of other functional teams are our stable counterparts:

Person Role
Hila Qu Director of Product, Growth
Matej Latin Senior Product Designer, Growth:Expansion
Timothy Noah Senior Product Designer, Growth:Retention
Jacki Bauer UX Manager, Growth
Michael Karampalas Principal Product Manager, Growth:Retention
Shane Rice Manager, Growth Marketing
Amanda Rueda Product Manager, Growth:Fulfillment
Tim Hey Principal Product Manager, Growth:Expansion
Sid Reddy Senior Product Manager, Growth:Telemetry
Kevin Comoli Product Designer, Growth:Conversion
Emily Sybrant Product Designer, Growth:Acquisition
Jeff Crow Senior UX Researcher, Growth
Jensen Stava Senior Product Manager, Growth:Acquisition
Sam Awezec Senior Product Manager, Growth:Conversion
Russell Dickenson Senior Technical Writer, Enablement, Growth
Vincy Wilson Quality Engineering Manager, Growth

How We Work

As part of the wider Growth stage we track and work on issues with the label ~"devops::growth".

Product Development Flow

Our team follows the Product Development Flow utilizing all labels from ~workflow::start to ~workflow::verification.

We adhere to the Completion Criteria and Who Transitions Out outlined in the Product Development Flow to progress issues from one stage to the next.

Workflow Boards

We use workflow boards to track issue progress throughout a milestone. Workflow boards should be viewed at the highest group level for visibility into all nested projects in a group.

There are three GitLab groups we use:

gitlab-org gitlab-com gitlab-services all groups
Growth Workflow - Growth Workflow -
Acquisition Workflow - Acquisition Workflow -
Conversion Workflow - Conversion Workflow -
Expansion Workflow - Expansion Workflow -
Retention Workflow - Retention Workflow -
Fulfillment Workflow - - -
Telemetry Workflow - Telemetry Workflow -

Product Development Timeline

Our work is planned and delivered on a monthly cycle using milestones. Our team follows the Product Development Timeline utilizing all dates including from M-1, 4th: Draft of the issues to M+1, 4th: Public Retrospective.

Milestone Boards

We use milestone boards for high level planning and roadmapping across several milestones.

gitlab-org gitlab-com gitlab-services
Growth Milestones - Growth Milestones
Acquisition Milestones - Acquisition Milestones
Conversion Milestones - Conversion Milestones
Expansion Milestones - Expansion Milestones
Retention Milestones - Retention Milestones
Fulfillment Milestones - -
Telemetry Milestones - Telemetry Milestones

UX Workflows

We follow the UX Team's Product Designer and Researcher workflows. We also have Growth specific workflows that you can read about here.

Sharing Designers Across Stage Groups

To start with, we follow GitLab internal communication guidelines. In addition the following tips will make it easier to collaborate with Product Designers who span multiple groups:

Visual Reviews of MRs

The engineering team applies the UX label to any MR that introduces a visual, interaction or flow change. These MRs can be related to new issues, bugs, followups, or any type of MR. If the engineer isn't sure whether the MR needs UX, they should consult the designer who worked on the related issue, and/or the designer assigned to that stage group, or the UX manager.

Visual reviews are required for any MR with the UX label. When the MR is in workflow::In review, the engineer assigns the MR to the designer for a visual review. This can happen in parallel with the maintainer review, but designers should prioritize these reviews to complete them as quickly as possible.

There are times when it isn't possible or practical for a designer to complete their visual review via Review Apps or GDK. At these times the designer and engineer should coordinate a demo.

How We Use Issues

To help our team be efficient, we explicitly define how our team uses issues.

Issue Creation

We aim to create issues in the same project as where the future merge request will live. For example, if an experiment is being run in the Customers application, both the issue and MR should be created in the Customers project.

We emphasize creating the issue in the right project to avoid having to close and move issues later in the development process. If the location of the future merge request cannot be determined, we will create the issue in our catch-all growth team-tasks project.

Running Experiments

We follow a four step process for running experiments as outlined by Andrew Chen's How to build a growth team.

  1. Form Hypotheses: Define ideas our team wants to test.
  2. Prioritize Ideas: Decide which ideas to test first.
  3. Implement Experiments: Do the Product, Design, Engineering, Data, and Marketing work to execute the experiment.
  4. Analyze Results: Dive into the results data and prove or disprove our hypotheses.

Each week, we provide progress updates and talk about our learnings in our Growth Weekly Meeting.

The duration of each experiment will vary depending on how long it takes for experiment results to reach statistical significance. Due to the varying duration, there will be some weeks where we have several experiments running concurrently in parallel.

Experiment Issue Boards

Experiments are tracked on Growth - Experiments boards by group:

gitlab-org gitlab-com gitlab-services all groups
Growth Experiments Growth Experiments Growth Experiments -

Experiment Issue Creation

All growth experiments consist of two issues:

Experiment Issue Labels

For tracking the status of experiments we also use the following scoped experiment:: labels:

Release Schedule

In order to deploy an experiment, experiments need to be tagged with a milestone and aligned to GitLab's release schedule.

Release schedules vary depending on where an experiment is being conducted.

Experiments are generally excluded from monthly release posts as they are behind feature flags and usually made available on An experiment feature can be added to the release post only after it has been implemented for the long run.

Growth Engineering Weekly

Every week, engineers in the Growth sub-department meet to discuss topics related to growth engineering. Discussion topics include how to track experiments, A/B testing, changes in customers application, changes in gitlab application, etc. Growth Engineers are encouraged to bring discussion topics to the meeting and to them to the agenda.

To get the most time zone coverage, these meetings alternate fortnightly between:

Team members are encouraged to attend the meeting that matches their time zone.

September 2019 Fast Boot

The Acquisition, Expansion, Conversion and Retention groups took part in a Fast Boot in September 2019. The planning issue contains the proposal for Fast Boot, and outcomes are available in the Growth Fast Boot Page.