Develop a respectful and privacy focused data collection framework, and an experimentation platform, that allow us to make informed product decisions and improve the customers experience, promote conversion, adoption of key stages, and increase our user base.
The Growth sub-department consists of groups that eliminate barriers between our users and our product value.
Deliver product intelligence data to improve the GitLab product
Product Intelligence Group: Product Intelligence focuses on providing GitLab's team with data-driven product insights to build a better GitLab. To do this, we build data collection and analytics tools within the GitLab product in a privacy-focused manner. Insights generated from Product Intelligence enables us to identify the best places to invest people and resources, what product categories mature faster, where our user experience can be improved, and how product changes impact the business. You can learn more about what we're building next on the Product Intelligence Direction page.
Build an experimentation platform for GitLab to make it easier to run experiments and make data driven product decisions
Experimentation: Experimentation focuses on providing GitLab's team with an experimentation platform to help build a better GitLab.
Drive value for the business and our users by improving trial to paid conversion, per-stage adoption, and wider usage of GitLab
We focus on validating ideas with data across the following four Groups:
The Growth groups also provide development input into two Growth product areas of focus:
We work on the issues prioritized by our product teams including running experiments on GitLab.com. More information on priorities can be found on the Growth direction page.
Unlike most other teams in the engineering division the Growth sub-department has Fullstack Engineers. The reason for this is that the Growth sub-department has a need for both Frontend and Backend skill-sets, but as a small team, has optimized for team member efficiency to adopt the Fullstack role.
Some useful links to see how and what we are working on include:
| Person | Role |
|---|---|
| Alina Mihaila | Acting Fullstack Engineering Manager, Product Intelligence |
| Jay Swain | Interim Fullstack Engineering Manager, Sec:Anti-Abuse and Growth:Adoption |
| Kamil Niechajewicz | Fullstack Engineering Manager, Growth:Conversion and Expansion |
| Phil Calder | Senior Engineering Manager, Growth |
| Wayne Haber | Director of Engineering for Growth, Sec, and ModelOps |
The following people are permanent members of groups that belong to the Growth sub-department:
| Person | Role |
|---|---|
| Jeremy Jackson | Senior Fullstack Engineer, Growth:Adoption |
| Minahil Nichols | Fullstack Engineer, Growth:Adoption |
| Person | Role |
|---|---|
| Alper Akgun | Staff Fullstack Engineer, Growth:Conversion |
| Dallas Reedy | Fullstack Engineer, Growth:Conversion |
| Sam Figueroa | Fullstack Engineer, Growth:Conversion |
| Serhii Yarynovskyi | Fullstack Engineer, Growth:Conversion |
| Person | Role |
|---|---|
| Doug Stull | Staff Fullstack Engineer, Growth:Expansion |
| Jackie Fraser | Fullstack Engineer, Growth:Expansion |
| Nicolas Dular | Senior Fullstack Engineer, Growth:Expansion |
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 | Covered by | Escalation |
|---|---|---|
| Wayne Haber | Christopher Lefelhocz | Eric Johnson |
| Phil Calder | Kamil Niechajewicz | Wayne Haber |
| Alina Mihaila | Kamil Niechajewicz | Phil Calder |
| Kamil Niechajewicz | Jay Swain | Phil Calder |
| Jay Swain | Phil Calder | Wayne Haber |
If an issue arises - such as a production incident or feature change lock - that a team member needs management support with when their direct manager is not online, the team member should reach out to any Growth Engineering Manager by mentioning in #sd_growth_engineering. The Growth manager can help the team member follow the process and co-ordinate to ensure the team member has the necessary support.
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 business continuity plan (BCP), as well as a general guide to Growth Engineering continuity in the event of one or more team members being unavailable for any reason.
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 following members of other functional teams are our stable counterparts:
| Person | Role |
|---|---|
| Amanda Rueda | Senior Product Manager, Product Intelligence |
| Gayle Doud | Senior Product Manager, Growth:Expansion |
| Sam Awezec | Principal Product Manager, Growth:Conversion |
| Emily Bauman | Product Designer, Growth |
| Kevin Comoli | Senior Product Designer, Growth |
| Matej Latin | Senior Product Designer, Growth |
| Fiona Neill | Senior Technical Writer, Manage (Optimize, Workspace), Growth (Product Intelligence) |
| Kati Paizee | Senior Technical Writer, Growth (Activation, Conversion, Expansion, Adoption), Ecosystem (Integrations) |
| Andrew Kelly | Senior Security Engineer, Application Security, Growth (Activation, Conversion, Expansion, Adoption), Fulfillment (Purchase, License, Utilization), Enablement (Distribution, Geo, Memory, Global Search, Database) |
| Carlo Catimbang | Senior Software Engineer in Test, Growth:Product Intelligence |
| Vincy Wilson | Quality Engineering Manager, Enablement, Fulfillment, Growth, ModelOps, and Sec |
| Jacki Bauer | Product Design Manager, Growth & Fulfillment |
The Growth sub-department uses the ~"devops::growth" label and the following groups for tracking merge request rate and ownership of issues and merge requests.
| Group name | Group label |
|---|---|
| Product Intelligence | ~"group::product intelligence" |
| Adoption | ~"group::adoption" |
| Conversion | ~"group::conversion" |
| Expansion | ~"group::expansion" |
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.
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 | - |
| Conversion Workflow | - | Conversion Workflow | - |
| Expansion Workflow | - | Expansion Workflow | - |
| Adoption Workflow | - | Adoption Workflow | - |
| Product Intelligence Workflow | - | Product Intelligence Workflow | - |
| Experiment tracking | - | - | - |
| Feature flags | - | - | - |
Before work can begin on an issue, we should estimate it first after a preliminary investigation. This is normally done in the monthly planning meeting.
| Weight | Description (Engineering) |
|---|---|
| 1 | The simplest possible change. We are confident there will be no side effects. |
| 2 | A simple change (minimal code changes), where we understand all of the requirements. |
| 3 | A simple change, but the code footprint is bigger (e.g. lots of different files, or tests effected). The requirements are clear. |
| 5 | 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. |
| 8 | A complex change, that will involve much of the codebase or will require lots of input from others to determine the requirements. |
| 13 | A significant change that may have dependencies (other teams or third-parties) and we likely still don't understand all of the requirements. It's unlikely we would commit to this in a milestone, and the preference would be to further clarify requirements and/or break in to smaller Issues. |
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 (merge request rate) enables our Growth teams to achieve a weekly experimentation cadence.
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.
We use milestone boards for high level planning and roadmapping across several milestones.
Info on the Growth UX team and how they work can be found on the Product/Growth page.
To help our team be efficient, we explicitly define how our team uses issues.
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 GitLab CustomersDot, both the issue and MR should be created in the CustomersDot 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.
We use issue templates for common tasks.
To support Iteration Growth engineering:
5 and higher should be reassigned to the Product Manager to make sure they can be split into smaller MVCs.
When this is not possible, the Product Manager will create a spike or research issue so that engineering can break it down and close the original.The DRI (assignee) of an issue is encouraged to add an async issue update, particularly for issues labelled ~Deliverable or ~Growth-Deliverable.
These updates can be added anytime and are useful to highlight when an issue is on track, blocked, or may need to be re-prioritized.
This helps us maintain transparency and our bias towards asynchronous communication.
Async issue update
**YYYY-MM-DD Update**
#### Please provide a quick summary of the current status (one sentence).
#### When do you predict this feature to be ready for maintainer review?
#### Are there any opportunities to further break the issue or merge request into smaller pieces (if applicable)?
#### Were expectations met from a previous update? If not, please explain why.
The Growth groups regularly run experiments to test product hypothesis.
GitLab team members are welcome to attend the Growth Sub-department Engineering Weekly meetings to connect with growth team members and find out more about running experiments at GitLab.
The Growth sub-department experiment teams track the number of closed "growth deliverable" issues prioritized by our product managers using the Growth-Deliverable definition. This metric acts as a target for deliverables based on number of engineers available to the four Growth experiment teams.
The following view shows the breakdown of closed Growth issues by type. This highlights the percentage of issues that relate to experiments or features.
The Growth sub-department tracks number of experiments per engineer as a development metric. This counts new experiments added to the codebase using experiment feature flags. Current experiments shows the total number of experiments in the codebase (pending, active, or concluded and ready to be removed).
Every week, engineers in the Growth sub-department meet to discuss topics related to growth engineering. Discussion topics include A/B testing, experimentation, instrumentation, product intelligence and data concerns, and changes at GitLab affecting engineering. Engineers in the Growth sub-department are encouraged to bring discussion topics to the meeting and add them to the agenda.
All GitLab team members are welcome to attend.
To get the most time zone coverage, these meetings alternate fortnightly between:
Team members - including those in different areas of APAC - should be able to attend at least one of the three meetings.
Team members are encouraged to contribute to the agenda async and attend the meeting that matches their time zone.
The Growth sub-department teams use data to help make product decisions. Central to that is the Product Intelligence group that provides the framework and tooling for data collection. As part of this, we look at how we can leverage different technologies to improve these services for GitLab use, and for our customers. We will be looking at how can we use Clickhouse in GitLab, including whether this is an option for:
On occasion we hold virtual team days or meetings to take a break and participate in fun, social activities with our Growth counterparts.
#s_growth in Slack (GitLab internal)#g_product_intelligence in Slack (GitLab internal)