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

Create:Source Code BE Team

The Create:Source Code BE team is responsible for all backend aspects of the product categories that fall under the Source Code group of the Create stage of the DevOps lifecycle.

Team Members

The following people are permanent members of the Create:Source Code BE Team:

Person Role
Michelle Gill Engineering Manager, Create:Source Code
Nick Thomas Staff Backend Engineer, Create:Source Code
Patrick Bajao Backend Engineer, Create:Source Code
Igor Drozdov Backend Engineer, Create:Source Code
Kerri Miller Backend Engineer, Create:Source Code
Robert May Senior Backend Engineer, Create:Source Code
David Sincheol Kim Senior Backend Engineer, Create:Source Code
Gary Holtz Backend Engineer, Create:Source Code
Marc S. Senior Backend Engineer, Create:Source Code

Stable Counterparts

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

Person Role
Achilleas Pipinellis Senior Technical Writer, Create, Package, Monitor, Secure, Defend
Marcia Ramos Senior Technical Writer, Create, Release
André Luís Frontend Engineering Manager, Create:Source Code, Delivery & Scalability
Phil Hughes Senior Frontend Engineer, Create:Source Code
Pedro Moreira da Silva Senior Product Designer, Create:Source Code
Katherine Okpara UX Researcher, Create
James Ramsay Group Manager, Product, Create
Daniel Gruesso Product Manager, Create:Source Code
Mark Lapierre Senior Software Engineer in Test, Create:Source Code (primary) & Create:Gitaly (secondary)
Samantha Ming Frontend Engineer, Create:Source Code
Justin Boyson Senior Frontend Engineer, Create:Source Code
Thomas Randolph Senior Frontend Engineer, Create:Source Code

Sisense & KPIs

We have a metrics dashboard to help us stay on track with Development KPIs (Make sure you filter by our team at the top!) This dashboard does not include security MRs from, but does include security MRs from production.


This chart shows the progress we're making on hiring. Check out our jobs page for current openings.

Future Start Dates in the Create:Source Code BE Team

The following people in the Create:Source Code BE Team have not started yet. They are counted towards today on the chart above.

Name Role Start Date
Marc S. Senior Backend Engineer, Create:Source Code 2020-05-04


In general, we use the standard GitLab engineering workflow. To get in touch with the Create:Source Code BE team, it's best to create an issue in the relevant project (typically GitLab) and add the ~"group::source code" and ~backend labels, along with any other appropriate labels. Then, feel free to ping the relevant Product Manager and/or Engineering Manager as listed above.

For more urgent items, feel free to use #g_create_source_code on Slack.

Working with product

Weekly calls between the product manager and engineering managers (frontend and backend) are listed in the "Source Code Group" calendar. Everyone is welcome to join and these calls are used to discuss any roadblocks, concerns, status updates, deliverables, or other thoughts that impact the group. Every 2 weeks (in the middle of a release), a mid-milestone check-in occurs, to report on the current status of ~"Deliverable"s. Monthly calls occurs under the same calendar where the entire group is encouraged to join, in order to highlight accomplishments/improvements, discuss future iterations, review retrospective concerns and action items, and any other general items that impact the group.

Collaborating with other counter parts

You are encouraged to work as closely as needed with stable counterparts outside of the PM. We specifically include quality engineering and application security counterparts prior to a release kickoff and as-needed during code reviews or issue concerns.

Quality engineering is included in our workflow via the Quad Planning Process.

Application Security will be involved in our workflow at the same time that kickoff emails are sent to the team, so that they are able to review the upcoming milestone work, and notate any concerns or potential risks that we should be aware of.

Capacity planning

We use a lightweight system of issue weighting to help with capacity planning. These weights help us ensure that the amount of scheduled work in a cycle is reasonable, both for the team as a whole and for each individual. The "weight budget" for a given cycle is determined based on the team's recent output, as well as the upcoming availability of each engineer.

Since things take longer than you think, it's OK if an issue takes longer than the weight indicates. The weights are intended to be used in aggregate, and what takes one person a day might take another person a week, depending on their level of background knowledge about the issue. That's explicitly OK and expected. We should strive to be accurate, but understand that they are estimates! Change the weight if it is not accurate or if the issue becomes harder than originally expected. Leave a comment indicating why the weight was changed and tag your EM so that we can better understand weighting and continue to improve.


The weights we use are:

Weight Description
1: Trivial The problem is very well understood, no extra investigation is required, the exact solution is already known and just needs to be implemented, no surprises are expected, and no coordination with other teams or people is required.

Examples are documentation updates, simple regressions, and other bugs that have already been investigated and discussed and can be fixed with a few lines of code, or technical debt that we know exactly how to address, but just haven't found time for yet.
2: Small The problem is well understood and a solution is outlined, but a little bit of extra investigation will probably still be required to realize the solution. Few surprises are expected, if any, and no coordination with other teams or people is required.

Examples are simple features, like a new API endpoint to expose existing data or functionality, or regular bugs or performance issues where some investigation has already taken place.
3: Medium Features that are well understood and relatively straightforward. A solution will be outlined, and most edge cases will be considered, but some extra investigation will be required to realize the solution. Some surprises are expected, and coordination with other teams or people may be required.

Bugs that are relatively poorly understood and may not yet have a suggested solution. Significant investigation will definitely be required, but the expectation is that once the problem is found, a solution should be relatively straightforward.

Examples are regular features, potentially with a backend and frontend component, or most bugs or performance issues.
5: Large Features that are well understood, but known to be hard. A solution will be outlined, and major edge cases will be considered, but extra investigation will definitely be required to realize the solution. Many surprises are expected, and coordination with other teams or people is likely required.

Bugs that are very poorly understood, and will not have a suggested solution. Significant investigation will be required, and once the problem is found, a solution may not be straightforward.

Examples are large features with a backend and frontend component, or bugs or performance issues that have seen some initial investigation but have not yet been reproduced or otherwise "figured out".

Anything larger than 5 should be broken down if possible.

Security issues are typically weighted one level higher than they would normally appear from the table above. This is to account for the extra rigor of the security release process. In particular, the fix usually needs more-careful consideration, and must also be backported across several releases.


Approximately 5-10 business days before the start of a new release, the EM will begin determining how "available" the team will be. Some of the things that will be taken into account when determining availability are:

Availability is a percentage calculated by (work days available / work days in release) * 100.

All individual contributors start with a "weight budget" of 10, meaning they are capable (based on historical data) of completing a maximum number of issues worth 10 weight points total (IE: 2 issues which are weighted at 5 and 5, or 10 issues weighted at 1 each, etc.) Then, based on their availability percentage, weight budgets are reduced individually. For example, if you are 80% available, your weight budget becomes 8.

Product will prioritize issues based on the teams total weight budget. Our planning rotation will help assign weights to issues that product intends on prioritizing, to help gauge the amount of work prioritized versus the amount we can handle prior to a kickoff.

Kickoff emails

Once availability has been determined, weights have been assigned, and the PM/EM finalize a list of prioritized issues for the upcoming release, kickoff emails will be sent. The intent of this email is to notify you of the work we intend to assign for the upcoming release. This email will be sent before the release begins. The kickoff email will include:

Emails get sent to each individual contributor on the team, as well as the Application Security counterpart, in order to give a heads-up about the upcoming issues in the milestone and what the assignments will be.

Planning rotation

For context, this process was taken and modified from the Plan team.

To assign weights to issues in a future milestone, we ask one team member to take the lead each month. They can still ask questions - of the rest of the team, of the stable counterparts, or anyone else - but they are primarily responsible. Issue weights will be confirmed once they've been assiged for the upcoming milestone. To weight issues, they should:

  1. Look through the issues on the milestone with a ~"Deliverable" label that have Weight:None.
  2. For each issue, they add a weight. If possible, they also add a short comment explaining why they added that weight, what parts of the code they think this would involve, and any risks or edge cases we'll need to consider.
  3. The process is intended to be lightweight. If something isn't clear what weight it is, they should ask for clarification on the scope of the issue.
  4. Start adding weights around a week before the weights for a milestone are due. Finishing earlier is better than finishing later.
  5. Check issues that have existing weights. Change the weight if you do not feel like the initial weight given is accurate and leave a comment explaining your reasoning.
  6. When the issues for the next release get formally assigned, the assignee should investigate the issue and confirm the weight.

Adding weights to the issues should take no longer than 8 hours. Please speak up if you find this taking longer than expected!

The rotation for upcoming releases is:

Release Weights due Engineer
12.7 2019-12-17 Patrick Bajao
12.8 2020-01-17
12.9 2020-02-17 Igor Drozdov
13.0 2020-03-17 Kerri Miller
13.1 2020-04-17 Nick Thomas
13.2 2020-05-17 Patrick Bajao
13.3 2020-06-17 David Kim
13.4 2020-07-17 Robert May
13.5 2020-08-17 Gary Holtz

Backend and Frontend issues

Many issues require work on both the backend and frontend, but the weight of that work may not be the same. Since an issue can only have a single weight set on it, we use scoped labels instead when this is the case: ~backend-weight::<number> and ~frontend-weight::<number>.

What to work on

The primary source for things to work on is the Source Code backend issue board for the current iteration cycle (don't forget to filter by milestone!), which lists all of the Deliverable and Stretch issues scheduled for this cycle in priority order.

The lists are compiled by the Product Manager following the product prioritization process, with input from the team, engineering managers, and other stakeholders. The iteration cycle lasts from the 18th of one month until the 17th of the next, and is identified by the GitLab version set to be released on the 22nd.

There is also the Source Code backend assignment issue board (again, don't forget to filter by milestone!), which shows the same Deliverable and Stretch issues, now grouped by assignee, with the left-most list listing issues not currently assigned to any backend engineer. On each list, the issues are again ordered by priority.

What to work on first

Deliverables are considered top priority and are expected to be done by the end of the iteration cycle on the 17th, in time for the release on the 22nd.

These top priority issues are assigned to engineers on or ahead of the 18th of the month, when the iteration cycle is kicked off, and it is their responsibility to make a best effort to get them done during that cycle, and to inform their engineering manager if anything is standing in the way of their success. You can find the issues assigned to you on the Source Code backend assignment issue board (again, don't forget to filter by milestone!).

Many things can happen during a month that can result in a deliverable not actually being completed by the end of a cycle, and while this usually indicates that the engineering manager was too optimistic in their estimation of the issue's weight, or that an engineer's other responsibilities ended up taking up more time than expected, this should never come as a surprise to the engineering manager.

The sooner this potential outcome is anticipated and communicated, the more time there is to see if anything can be done to prevent it, like reducing the scope of the deliverable, or finding a different engineer who may have more time to finish a deliverable that hasn't been started yet. If this outcome cannot be averted and the deliverable ends up missing the cycle, it will simply be moved to the next cycle to be finished up, and the engineer and engineering manager will have a chance to retrospect and learn from what happened.

Generally, your deliverables are expected to take up about 75% of the time you spend working in a month. The other 25% is set aside for other responsibilities (code review, community merge request coaching, helping people out in Slack, participating in discussions in issues, etc), as well as urgent issues that come up during the month and need someone working on them immediately (regressions, security issues, customer issues, etc).

What to work on next

If you have time to spare after finishing your deliverables and other activities, you can spend the remaining time working on Stretch issues, which can also be found on the Source Code backend issue board and Source Code backend assignment issue board (again, don't forget to filter by milestone!).

These lower priority issues are not expected to be done by the end of the iteration cycle, but are to be Deliverables in the next cycle, so any progress made on them ahead of time is a bonus.

Stretch issues are usually not directly assigned to people, except in cases where there is clearly a most appropriate person to work on them, like in the case of technical debt, bugs related to work someone did recently, or issues someone started on before but hasn't had a chance to finish yet.

If no Stretch issues are assigned to you yet, you can find new ones to pick up in the left-most list of the Source Code backend assignment issue board (again, don't forget to filter by milestone!), which lists all issues not currently assigned to any backend engineer. As the issues are ordered by priority, they should be picked up starting at the top. When you assign an issue to yourself to indicate you're working on it, it will move to your list and out of the left-most unassigned list, and the second issue will rise to the top for other engineers to pick up.

If anything is blocking you from getting started with the top issue immediately, like unanswered questions or unclear requirements, you can skip it and consider a lower priority issue, as long as you put your findings and questions in the issue, so that the next engineer who comes around may find it in a better state.

Instead of picking up Stretch issues, you may also choose to spend any spare time working on anything else that you believe will have a significant positive impact on the product or the company in general. As the general guidelines state, "we recognize that inspiration is perishable, so if you’re enthusiastic about something that generates great results in relatively little time feel free to work on that."

We expect people to be managers of one and prefer responsibility over rigidity, so there's no need to ask for permission if you decide to work on something that's not on the issue board, but please keep your other responsibilities in mind, and make sure that there is an issue, you are assigned to it, and consider sharing it in #g_create_source_code.

Workflow labels

The easiest way for engineering managers, product managers, and other stakeholders to get a high-level overview of the status of all issues in the current milestone, or all issues assigned to specific person, is through the Development issue board, which has columns for each of the workflow labels described on Engineering Workflow handbook page under Updating Issues Throughout Development.

As owners of the issues assigned to them, engineers are expected to keep the workflow labels on their issues up to date, either by manually assigning the new label, or by dragging the issue from one column on the board to the next.

Async standup

The groups in the Create stage conduct asynchronous standups in the #g_create_standup channel 3 times a week, on Monday, Wednesday, and Friday.

The goal is to support the members of these groups in connecting at a personal level, not to check in on people's progress or replace any existing processes to communicate status or ask for help, and the questions are written with that in mind:

  1. What did you do outside of work since we last spoke?
  2. What are you planning to do today?
  3. Is anything blocking your progress or productivity?

For more background, see the Async standup feedback issue on the Create stage issue tracker.


We have 1 regularly scheduled "Per Milestone" retrospective, and can have ad-hoc "Per Project" retrospectives.

Per Milestone

The Create:Source Code group conducts monthly retrospectives in GitLab issues. These include the backend team, plus any people from frontend, UX, and PM who have worked with that team during the release being retrospected.

These are confidential during the initial discussion, then made public in time for each month's GitLab retrospective. For more information, see team retrospectives.

Per Project

If a particular issue, feature, or other sort of project turns into a particularly useful learning experience, we may hold a synchronous or asynchronous retrospective to learn from it. If you feel like something you're working on deserves a retrospective:

  1. Create an issue explaining why you want to have a retrospective and indicate whether this should be synchronous or asynchronous
  2. Include your EM and anyone else who should be involved (PM, counterparts, etc)
  3. Coordinate a synchronous meeting if applicable

All feedback from the retrospective should ultimately end up in the issue for reference purposes.

Deep Dives

The groups in the Create stage organize regular Deep Dive sessions to share our domain specific knowledge with others in the stage, the organization, and the wider community. All existing Deep Dives can be found on GitLab Unfiltered with slides and recordings in the descriptions. For Create specific Deep Dives, there is a different playlist. To find more information on upcoming sessions, or to propose a new topic, please see the epic.

Career development

Career development conversations in the Create:Source Code BE team are centered around a Career Development Sheet that is based on the Engineering Career Matrix for Individual Contributors. The sheet lists the expected current level behaviors on the left, the next level behaviors on the right, and uses colored columns in between to visually represent the extent to which the individual has shown to have grown from the current level to the next. Columns to the right of a next level behavior are used to collect specific examples of that behavior, which serve as evidence of the individual's growth.

Both the matrix and the sheet are Works in Progress; the development of the career matrix is tracked in an epic, and as the matrix evolves, the sheet will be updated to match.