At GitLab, we promote two paths for leadership in Engineering. While there is a healthy degree of overlap between these two ideas, it is helpful and efficient for us to specialize training and responsibility for each of:
While technical leadership tends to come naturally to software engineers, professional leadership can be more difficult to master.
This page will serve as a training resource and operational guide for current and future managers.
All Engineering Managers should follow the general leadership principles set out in the handbook. In particular, it is not uncommon for Engineering Managers to struggle with one or more of the following areas, so we recommend you review them carefully and discuss your confidence with your manager:
Onboarding is essential for all Engineering Managers at GitLab. As part of onboarding, a Becoming a GitLab Manager issue will be created for each manager when they join, or are promoted. This issue is intended to connect new managers with the crucial information they need, and ensure they have access to all the resources and training available.
Each Engineering Manager (EM) is responsible for developing a Backup Plan in the case that an EM has to take an unplanned extended OOO. In order to minimize the team disruptions, this plan should be executed once an EM decides it is the best course of action. An example is below:
|Peer EM Backup (preferably FE / BE pairs)||Senior Team Member||Manager of EM|
|Participate in the Team Retrospective, highlight items to company-wide retro, read items on call if necessary||Work with PM on Backlog Refinement and Milestone Planning||Complete Navan Expense Reports|
|Conduct Synchronous / Asynchronous 1-1’s (if more than 1 week)||New Hire Onboarding||Handle Expense Questions|
|Manager Approvals (Access to staging, etc)|
Please, consider including timing details. Example: If outage spans last/first week of the milestone, participate in planning the milestone with PM.
When you're done, consider also publishing it to your team page and informing your Peer EM Backup.
We expect all managers at GitLab to be technically credible with their teams. Fluency in our core technologies and architectures is essential because it enables managers to participate effectively on technical conversations. In order to maintain this fluency, we encourage managers to participate in coding-related work to an extent. However, please keep the following advice in mind:
The sections below aim to inform you of the responsibilities that an engineering manager has at GitLab. It will provide you with the necessary context, information, and process to follow.
The convention at GitLab is to display Manager roles as:
Manager, Brand Growth Managerin the Marketing Division
Manager, ITin the Finance Division
This convention is used in Workday, the system of record. For display in the handbook and to preserve de-facto industry standard role names such as
Engineering Manager and abbreviations such as
EM, manager roles in the Engineering Division
generally follow this naming pattern:
Engineering Manager, [Specialty]
Accounting for temporary management positions, the Senior manager track,
different types of manager roles (such as
Support), and the potential for one or more specialties yields:
[Acting|Interim] [Senior] [Backend|Frontend|Fullstack|Site Reliability|Support|Quality] Engineering Manager [, Specialty]
Seniormanager roles are introduced when needed, usually related to management span of control in the relevant department.
Engineering Manager. Be specific when identifying which manager under Engineering is responsible for certain tasks in order to avoid confusion over the term "EM". For example:
Support Operations Managerfor Support.
Stage. Choose the primary stage if the manager covers multiple stages.
Stage: Group). Choose the primary group if the manager covers multiple groups.