Create:Code Review BE Engineering Manager Responsibilities
The Backend Engineering Manager role at GitLab is an exciting and dynamic position that encompasses a wide range of responsibilities. In addition to leading and managing a team of talented engineers, the role involves overseeing projects from start to finish, making sure everything runs smoothly and meets high standards. As an engineering manager, you’ll also have the opportunity to shape the team by actively participating in recruiting and hiring. One of the key aspects of the role is setting ambitious goals and measuring progress through OKRs (Objectives and Key Results), providing a clear roadmap for success. Moreover, fostering collaboration between different departments and teams is vital to ensure a seamless and efficient workflow. It’s a multifaceted role that combines the best of leadership, project management, and team building, making each day full of diverse and engaging challenges.
This page will capture some of the responsibilities and resources for the Create:Code Review Backend Engineering Manager.
People Management
Talent Assessments
Talent assessments happen on a regular basis.
Milestone Planning
Milestone Schedule
Here are the activities done by the engineering manager throughout the course of a milestone.
The release is on the 3rd Thursday of every month. We use a cutoff date of the Friday before that to get any work completed. You can see more about the release process here.
On the first of the month a new planning issue is automatically created for the next milestone. Create threads for the various projects / topics (e.g. Rapid Diffs, CLI, Bugs) and tag the backend team to get ideas for issues to include in the upcoming milestone planning.
Planning week activities
The last week of the milestone is planning week for the next milestone. Here are the tasks to do during this week and the following one:
| Day | Action |
|---|---|
| Mon | Make sure we have a capacity estimate for the next milestone. Check with team members to make sure all PTO has been entered. Use the capacity planning spreadsheet and add the capacity estimate to the planning issue. |
| Mon | Estimate slippage by asking team members which issues are likely/sure to slip, and the total weight expected to complete the work in the next milestone. |
| Mon | Have an initial planning meeting with the PM and frontend EM for Code Review to align on priorities for the milestone and set initial expectations on slippage. |
| Thu | Have a final planning meeting with the PM and frontend EM for Code Review to pick issues for the milestone that fit within the available capacity. |
| Fri | Assign issues to team members based on capacity. |
| Fri | Label all issues with the Deliverable and workflow::ready for development labels. |
| Fri | Post a comment with an overview of all assigned issues in the planning issue. |
| - | Milestone ends |
| Mon | Calculate the percentage breakdown of features, bugs, and maintenance and add it to the current planning issue. |
| Tue | Review all open issues from the previous milestone, move them to the appropriate milestone. |
| Thu | Find issues to investigate as part of the planning / backlog refinement process (*). Create a new issue using the backlog refinement template. |
(*) This process is not actively in use and needs to be revived or revisited.
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.
Weights
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. |
| 4: 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”. |
| 5: Unknown | A feature that is weight 5 will not be scheduled and instead should be broken down or a spike scheduled |
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 patch release process. In particular, the fix usually needs more-careful consideration, and must also be backported across several releases.
Availability
Approximately 5-10 business days before the start of a new release, the EM will begin determining how “available” the team will be. This is recorded in the capacity planning spreadsheet for transparency. Some of the things that will be taken into account when determining availability are:
- Upcoming training
- Upcoming time off / holidays
- Upcoming on-call slots
- Potential time spent on another teams deliverables
Availability is a percentage calculated by (work days available / work days in release) * 100.
All individual contributors start with a “weight budget” of 7, meaning they are capable (based on historical data) of completing a maximum number of issues worth 7 weight points total. Then, based on their availability percentage, weight budgets are reduced individually. For example, if you are 70% available, your weight budget becomes 5.
Product will prioritize issues based on the teams total weight budget.
Project Management
Service Level Objectives Monitoring
The Engineering Manager will take proactive steps to avoid having reported bugs to go past the target duration defined in Severity SLOs.
The Bug Triage Board and Triage Reports can be used to review all open bugs.
Priority Issues
There are some classifications of issues that need immediate attention. These could be reliability, security, or high-priority issues. The Engineering Manager needs to watch for these issues on a regular basis, typically multiple times per week.
The Code Review Priority Issue Board is a way to see all these issues in one place.
a18cc20e)
