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

Manage Team


The responsibilities of this team are described by the Manage product category. Manage is made up of multiple groups, each with their own categories and areas of responsibility.

In GitLab issues, questions should start by @ mentioning the relevant Product Manager for the category. GitLab employees can also use #s_manage.

How we work


Before work can begin on an issue, we should estimate it first after a preliminary investigation.

Separate issues should be created for each discipline that's involved (see an example), and scheduled issues without a weight should be assigned the "estimation:needed" label.

When estimating development work, please assign an issue an appropriate weight:

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.

For UX issues, please use a similar methodology:

Weight Description (UX)
1 Mostly small to medium UI changes, smaller UX improvements, without unanswered questions
2 Simple UI or UX change where we understand all of the requirements, but may need to find solutions to known questions/problems.
3 A simple change but the scope of work is bigger (lots of UI or UX changes/improvements required). Multiple pages are involved, we're starting to design/redesign small flows. Some unknown questions may arise during the work.
5 A complex change where other team members will need to be involved. Spans across multiple pages, we're working on medium-sized flows. There are significant open questions that need to be answered.
8 A complex change that spans across large flows and may require input from other designers. This is the largest flow design/redesign that we would take on in a single milestone.
13 A significant change that spans across multiple flows and that would require significant input from others (teams, team members, user feedback) and there are many unknown unknowns. 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.

As part of estimation, if you feel the issue is in an appropriate state for an engineer to start working on it, please add the ~"workflow::ready for development" label. Alternatively, if there are still requirements to be defined or questions to be answered that you feel an engineer won't be able to easily resolve, please add the ~"workflow::blocked" label. Issues with the workflow::blocked label will appear in their own column on our planning board, making it clear that they need further attention.

Once an issue has been estimated, the estimation:needed label can be replaced with estimation:completed.


We plan in monthly cycles in accordance with our Product Development Timeline. In order to plan for these milestones, groups should consider the following milestones:

During a release


Our priorities should follow overall guidance for Product. This should be reflected in the priority label for scheduled issues:

Priority Description Probability of shipping in milestone
P1 Urgent: top priority for achieving in the given milestone. These issues are the most important goals for a release and should be worked on first; some may be time-critical or unblock dependencies. ~100%
P2 High: important issues that have significant positive impact to the business or technical debt. Important, but not time-critical or blocking others. ~75%
P3 Normal: incremental improvements to existing features. These are important iterations, but deemed non-critical. ~50%
P4 Low: stretch issues that are acceptable to postpone into a future release. ~25%

Organizing the work

Planned or in-progress work should follow our Product Development Flow. This breaks down tasks into two categories:

Category Question Uncertainty Directly Responsible Consulted
Validation How should we solve a problem? Relatively high Product/Design Engineering
Build How should we build a solution? Relatively low Engineering Product/Design

Basecamp thinks about these stages in relation to the climb and descent of a hill. Validation represents the climb (we're figuring things out), and Build represents the descent (issues that we understand and are executing on). We represent the Validation and Build tracks in the following boards:

Group Validation Track Build Track
Access Board Board
Import Board Board
Compliance Board Board

Boards can be filtered for a particular milestone and department (example).


After the Kickoff, the Manage team conducts an asynchronous retrospective on the prior release. You can find current and past retrospectives for Manage in


Although we have a bias for asynchronous communication, synchronous meetings are necessary and should adhere to our communication guidelines. These meetings generally fall into several categories:

The following people are permanent members of the Manage team:

Person Role
Dennis Tang Frontend Engineering Manager, Manage
Martin Wortschack Senior Frontend Engineer, Manage:Analytics
Brandon Labuschagne Frontend Engineer, Manage:Analytics
Ezekiel Kigbo Frontend Engineer, Manage:Analytics
Illya Klymov Senior Frontend Engineer, Manage:Access
Jiaan Louw Frontend Engineer, Manage:Compliance
Robert Hunt Frontend Engineer, Manage:Compliance
Peter H. Frontend Engineer, Manage:Spaces
Liam McAndrew Engineering Manager, Manage:Access
James Edwards-Jones Backend Engineer, Manage:Access
Luca Williams Product Manager, Manage
Jeremy Watson Group Manager, Product, Manage
Matt Gonzales Senior Product Manager, Manage:Compliance
Haris Delalić Senior Product Manager, Manage:Import
New Vacancy - Jeremy Watson (Interim) Senior Product Manager, Manage:Access
Imre Farkas Senior Backend Engineer, Manage:Access
Evan Read Senior Technical Writer, Manage, Verify, Configure, Growth
Manoj M J Backend Engineer, Manage:Access
Adam Hegyi Senior Backend Engineer, Manage:Analytics
Aakriti Gupta Backend Engineer, Manage:Analytics
Sebastián Arcila-Valenzuela Senior Backend Engineer, Manage:Access
George Koltsov Backend Engineer, Manage:Import
Josianne Hyson Backend Engineer, Manage:Import
Sanad Liaquat Senior Software Engineer in Test, Manage
New Vacancy - Jeremy Watson (Interim) Senior Product Manager, Manage:Analytics
Małgorzata Ksionek Senior Backend Engineer, Manage:Access
Pavel Shutsin Senior Backend Engineer, Manage:Analytics
Désirée Chevalier Software Engineer in Test, Manage
Nick Post Senior Product Designer, Manage
Daniel Mora Senior Product Designer, Manage
A.H. Senior Product Designer, Manage
Aishwarya Subramanian Backend Engineer, Manage:Import
Dan Jensen Engineering Manager, Manage, Manage:Analytics