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.
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.
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 teams contribute to a GitLab experimentation gem to make it easier to run experiments and make data driven product decisions on GitLab.com.
| Person | Role |
|---|---|
| Kamil Niechajewicz | Engineering Manager, Growth:Acquisition and Activation |
The following people are permanent members of groups that belong to the Growth stage:
| Person | Role |
|---|---|
| Doug Stull | Staff Fullstack Engineer, Growth:Acquisition |
| Roy Liu | Associate Fullstack Engineer, Growth:Acquisition |
| Ross Byrne | Fullstack Engineer, Growth:Acquisition |
| Serhii Yarynovskyi | Fullstack Engineer, Growth:Acquisition |
| Person | Role |
|---|
The following table shows who will provide cover if one or more of the Growth Stage management team are unable to work for any reason.
| Team Member | Covered by | Escalation |
|---|---|---|
| Wayne Haber | Phil Calder | Christopher Lefelhocz |
| Phil Calder | Kamil Niechajewicz | Wayne Haber |
| Kamil Niechajewicz | 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 Workday and Navan Expense.
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 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.
The following members of other functional teams are our stable counterparts:
| Person | Role |
|---|---|
| Gayle Doud | Senior Product Manager, Growth:Acquisition |
| Paige Cordero | Senior Product Manager, Growth:Activation |
| Sam Awezec | Principal Product Manager, Growth:Acquisition and Activation |
| 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 |
| Nikhil George | Senior Security Engineer, Application Security, Secure (Static Analysis, Dynamic Analysis, Composition Analysis, Vulnerability Research), Growth (Acquisition, Activation). |
| Vincy Wilson | Senior Manager, Quality Engineering, Enablement, Fulfillment, Growth, Sec and Data Science |
| Mariana da Costa Melo | Customer Success Manager, Growth (Commercial EMEA) |
| Philipp Zapf | Customer Success Manager, Growth (Enterprise EMEA) |
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.
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.
| Name | Label | gitlab-org | All Groups |
|---|---|---|---|
| Growth | ~"devops::growth" |
Growth Workflow | - |
| Acquisition | ~"group::acquisition" |
Acquisition Workflow | - |
| Activation | ~"group::activation" |
Activation Workflow | - |
| Experiments | ~"experiment-rollout" |
Experiment tracking | - |
| Feature Flags | ~"feature flag" |
Feature flags |
Growth teams work across the GitLab codebase on multiple groups and projects including:
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.
~"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.
refinement thread for such issue instantly so the refinement can proceed the same way as with automated path.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 🚀.~"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".
~"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.~"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.| 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.
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 ~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.
The Growth groups regularly run experiments to test product hypothesis.
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.
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).
Complete list of Growth Section engineering metrics.
(Sisense↗) We also track our backlog of issues, including past due security and infradev issues, and total open SUS-impacting issues and bugs.
(Sisense↗) MR Type labels help us report what we're working on to industry analysts in a way that's consistent across the engineering department. The dashboard below shows the trend of MR Types over time and a list of merged MRs.
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)