Growth Stage

Vision

Grow an agile fullstack development capability to support our product goals through feature development and experiments enabling GitLab to make informed product decisions and achieve results in line with our product direction.

Mission

Working inline with our values, we focus on iteration and collaboration, working with and across areas of the product our development department counterparts maintain, as well our own areas of responsibility.

Direction

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.

Growth stage teams have Fullstack Engineers. The reason for this is that the Growth stage 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:

• Growth direction
• Growth Kanban board for development
• Experimentation
• GLEX
• Experiment rollout
• acquisition group
• activation group

Growth teams contribute to a GitLab experimentation gem to make it easier to run experiments and make data driven product decisions on GitLab.com.

Roadmap

Our current roadmap can be accessed through our quarterly OKR planning issues:

• FY24 Q3
• FY24 Q4

Who Are We?

People Leaders in Development

All Team Members

The following people are permanent members of groups that belong to the Growth stage:

Acquisition

Name	Role
Buck O'Leary	Senior Fullstack Engineer, Growth::Acquisition
David Hamp-Gonsalves	Senior Fullstack Engineer
Doug Stull	Staff Fullstack Engineer, Growth:Acquisition
Jay Montal	Senior Fullstack Engineer, Growth::Acquisition
Roy Liu	Associate Fullstack Engineer, Growth:Acquisition
Serhii Yarynovskyi	Fullstack Engineer, Growth:Acquisition

Activation

Counterparts

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

Stable Counterparts

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

Name	Role
Buck O'Leary	Senior Fullstack Engineer, Growth::Acquisition
Costel Maxim	Senior Security Engineer, Application Security, Plan (Project Management, Product Planning, Certify), Create:Source Code, Growth, Fulfillment:Purchase, Fulfillment:Provision, Fulfillment:Utilization, Systems:Gitaly
Doug Stull	Staff Fullstack Engineer, Growth:Acquisition
Gayle Doud	Principal Product Manager, Growth:Acquisition
Jay Montal	Senior Fullstack Engineer, Growth::Acquisition
Kamil Niechajewicz	Engineering Manager, Growth
Nikhil George	Senior Security Engineer, Application Security, Secure (Static Analysis, Dynamic Analysis, Composition Analysis, Vulnerability Research), Growth (Acquisition, Activation).
Paige Cordero	Senior Product Manager, Growth:Activation
Philipp Zapf	Customer Success Manager, Growth (Enterprise EMEA)
Roy Liu	Associate Fullstack Engineer, Growth:Acquisition
Serhii Yarynovskyi	Fullstack Engineer, Growth:Acquisition

How We Work

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

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.

Labels and 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.

The Growth stage uses the ~"devops::growth" label and the following groups for tracking merge request rate and ownership of issues and merge requests.

Growth teams work across the GitLab codebase on multiple groups and projects including:

• The gitlab.com/gitlab-org group
• gitlab
• GLEX
• customers-gitlab-com
• The gitlab.com/gitlab-com group
• www-gitlab-com

Issue sequencing

In order to convey Issue implementation order and blocking concepts, we leverage the blocking issue linking feature.

More on the discussion can be seen in https://gitlab.com/gitlab-org/growth/team-tasks/-/issues/752.

Issue Refinement And Estimation

Before the work can begin on an issue, we should refine and estimate it. We have a continuous process for this, leveraging additional workflow status, ~"workflow::refinement", which indicates that the issue is being refined by the team. Once the issue refinement is completed, it can be moved to ~"workflow::scheduling" stage.

The refinement process is driven by triage bot automations and policies to ensure that it’s smooth and consistent.

Refinement Steps

1. Issues are moved from ~"workflow::planning breakdown" to ~"workflow::refinement" automatically by the triage bot in order of priority (from top to bottom). The bot will only move issues to refinement if there is room in refinement column, meaning there is less issues than maximum limit for this column. This is first chance for PMs to prioritize issues by moving them higher in the planning breakdown column. After the issue is moved to refinement, a dedicated refinement thread is created, which acts as a place for discussion and weight estimation.
   • 💡 Hint: In rare case when an issue has to be expedited, it’s possible to move it to refinement manually. This will invoke a reaction from triage bot, which will add refinement thread for such issue instantly so the refinement can proceed the same way as with automated path.
2. During refinement the team ensures that the issue is well described and requirements are clear. They can use the refinement thread to discuss but they should make sure that any changes and decisions made there are also reflected in issue’s description. Once each engineer is comfortable with the way the issue is described, they can vote their estimation of weight based on our guidelines. The voting happens by reacting to the thread with one of few possible weight estimates: 1️⃣ 2️⃣ 3️⃣ 5️⃣ or 🚀.
3. Each day the triage bot checks all issues in ~"workflow::refinement" column and if an issue has required minimum number of estimation votes (see MIN_REACTIONS constant here for the current setting) it will be moved to ~"workflow::scheduling".
   • 💡 Hint: If there is some problem with the issue and it shouldn’t be moved forward even if enough engineers estimate it, ❌ reaction can be added to the thread which will stop the bot from transitioning the issue to ~"workflow::scheduling" as long as this reaction sticks to the thread. This means that whoever put it is also responsible for removing it once the problem is gone.
4. Once the issue is in ~"workflow::scheduling", it is awaiting final prioritization by PMs - it has to be manually moved to ~"workflow::ready for dev" depending on the current priorities. This part of the process is PMs responsibility. This allows for additional fine-tuning of priorities and acts as a buffer for our ready for development column.

Estimation guidelines

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.

• If an issue has many unknowns where it’s unclear if it’s a 1 or a 5, we will be cautious and estimate high (5).
• If an issue has many unknowns, we can break it into two issues. The first issue is for research, also referred to as a Spike, where we de-risk the unknowns and explore potential solutions. The second issue is for the implementation.
• If an initial estimate is incorrect and needs to be adjusted, we revise the estimate immediately and inform the Product Manager. The Product Manager and team will decide if a milestone commitment needs to be adjusted.

Technical exploration (“Spike”) guidelines

Occasionally, the team will be asked to dedicate time to exploring or “spiking” a technical solution to a problem or opporunity area deemed a priority by Growth PM. Technical spikes are fundamentally different than our typical work items as the result is more commonly a recommendation on a technical direction or solution (in the form of additional epics and/or issues) rather than code, yet they still require dedicated developer focus and should be accounted for in our development workflows. As such, we’ve determined the following guidelines and responsibilities for individual Growth Engineers to follow when addressing a techincal spike in our workflow:

Note: As of Q2 FY25, technical spikes will follow the same workflow process as code-based issues - they will enter ~workflow::refinement, then be scheduled and prioritized for pick up in ~workflow::ready for development. Active technical spike work will be represented in ~workflow::in dev. Once outputs are completed, the technical spike issue will be closed and moved to ~workflow::complete.

Inputs

As a technical spike is prioritized and available for pickup in ~workflow::ready for development, complete the following steps:

• Assign yourself to the technical spike along with the current milestone

• If not already added, add the ~spike label to the issue.

• Connect with the responsible PM to align on a reasonable due date for the technical spike. Duration will be dependent on the subject matter and Growth’s familiarity with the topic.

• Once determined, assign a due date.

• Review the contents of the technical spike issue body. Add a comment to clarify outstanding questions with the responsible PM. This is a great time to highlight potential needs for cross-collaboration with other teams or code or Product subject matter experts, or other inputs you feel will be important to the technical spike.

• If possible, add a comment with a proposed plan for how you intend to address the spike and whether any PM checkpoints, etc. would be desired. During the technical spike investigation period

• Communicate any relevant learnings or discoveries that could impact duration or scope needed for the spike with the responsible PM

• If you are nearing the assigned due date and will be in need of more time for the investigation, reach out to the responsible PM to align on next steps

Outputs

As the technical spike work comes to a completion, complete the following steps to close out the spike process:

• Provide a summary comment with detailed learnings of your investigation and recommended path(s) for the solution in the spike issue. Include an outline of the recommended next step issues and/or epics to be created for the next phase of work.
• Tag in the responsible PM, EM, and Growth Engineering team (@gitlab-org/growth/engineering team) for review.
• Confirm with the responsible PM that the spike requirements have been met within the alotted duration time.
• Move the technical spike issue to ~workflow::complete.
• Close the technical spike issue.

UX

Info on the Growth UX team and how they work can be found on the Product/Growth page.

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 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.

Iteration

To support Iteration Growth engineering:

1. Separates refactoring from feature MVCs. When refactoring is raised in review, the preference is to resolve in a follow up issue.
2. Addresses technical debt and follow up issues through prioritization and discussion by relevant stakeholders.
3. Issues with a weight of 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.
4. We make use of research issues and engineering spikes in the prior milestone, so estimations are more accurate.

Status Updates

The DRI (assignee) of an issue is encouraged to add an async issue update, particularly for issues labeled ~Deliverable or ~Stretch. 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

Experimentation

The Growth groups regularly run experiments to test product hypothesis.

• Read about the experimentation process.
• View the developer documentation
• View slides for the Experimentation Workshop

GitLab team members are welcome to attend the Growth Stage Engineering Weekly meetings to connect with growth team members and find out more about running experiments at GitLab.

Growth Metrics

The Growth stage tracks number of experiments deployed as a development metric. This is not an individual or team performance indicator. This allows teams to track their technical debt.

New experiments added to the codebase using experiment feature flags are tracked until removal. Current experiments shows the total number of experiments in the codebase (pending, active, or concluded and ready to be removed).

Growth Section Metrics

Complete list of Growth Section engineering metrics.

Team Days

On occasion we hold virtual team days or meetings to take a break and participate in fun, social activities with our Growth counterparts.

• FY23-Q2 2022
• December 2021
• April 2021
• September 2020
• May 2020

Common Links

• Growth stage
• Growth workflow board
• #s_growth in Slack (GitLab internal)
• Growth opportunities
• Growth meetings and agendas (GitLab internal)
• GitLab values

View page source - Edit this page - please contribute.