Engineering Management

1. You are here:
2. Engineering
3. Engineering Management

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.

On this page

• How Engineering Management Works at GitLab
• General leadership principles
• Engineering Manager Onboarding
• Engineering Manager Backup
• Technical Credibility
• Management Responsibilities
• Management Roles

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:

• 1-1s
• Providing regular feedback
• Dealing with underperformance
• Engineering manager role explained

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

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.

• Hiring
• Career Development
• Project Management
• Team Retrospectives
• Development department metrics

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
• Manager, Software Engineering in the Development Sub-department
• Manager, Support Engineering in the Support Sub-department

Senior Manager roles follow the same convention. For instance

• Senior Manager, Software Engineering in the Development Sub-department
• Senior Manager, Support Engineering in the Support Sub-department

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] [Site Reliability|Support|Quality] Engineering Manager [, Specialty]

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. 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 Manager for Support.
• Specialty - which is maintained in Workday and sync'ed to the handbook - should generally follow these guidelines:
  • Should include a Stage. Choose the primary stage if the manager covers multiple stages.
  • For managers who manage individual contributors, include the group (Stage: Group). Choose the primary group if the manager covers multiple groups.