Engineering Management

Maintained by:

How Engineering Management Works at GitLab

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:

Technical leadership, as represented by Staff and higher-level engineers.
Professional leadership, as represented by Engineering management.

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.

General leadership principles

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:

Engineering Manager Onboarding

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.

Engineering Manager Backup

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 Expensify 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.

Technical Credibility

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:

Avoid critical path work. If work has been scheduled for a release or is otherwise blocking other members of the team, it's best left to a developer who can focus on it more holistically. As a manager you should expect regular interruptions to your day that will make you less effective on this kind of task.
Focus on where you can add the most value. As mentioned above, you won't add value on critical path work, but that doesn't mean you can't add value in other ways. For a great discussion on this, see this article on How (and why) Should Managers Code.
Plan to review more than you write. Following from all of this, most of your "coding-related work" should be in code review - you add more value reviewing code to stay up to date with your team and provide them feedback and guidance. If you find yourself spending more time writing code than you do reviewing it, this may be an indicator that you need to revisit your priorities as a leader.

Management Responsibilities

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.

Management Roles

The convention at GitLab is to display Manager roles as:

Manager, Brand Growth Manager in the Marketing Division
Manager, IT in the Finance Division

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 Backend or Support), and the potential for one or more specialties yields:

Where:

Acting or Interim roles are temporary management positions.
Senior manager roles are introduced when needed, usually related to management span of control in the relevant department.
Some departments have domain specific role names as well as or instead of Engineering Manager including:
- Product Design Manager for UX.
- Support Operations Manager for Support.
Specialty can be one or many, and should generally be listed as:
- One specialty: ", Specialty I".
- Two specialties: ", Specialty I & Specialty II".
- Three plus specialties: ", Specialty I, Specialty II & Specialty III".