Move managment pages into place

---

title: "Engineering Management"

---

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

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.

The convention at GitLab is to display [Manager](/company/team/structure/#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

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

- `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:

---

title: "Group Retrospectives"

---

As a part of our [retrospective process](/handbook/engineering/workflow/#retrospective), at the end of each release, each [Product Group](/company/team/structure/#product-groups) should hold their own Group Retrospective. The goal of the retrospective is to talk through what went well, what went wrong, and what can be improved. Some Engineering sub-departments, such as UX and Quality, also conduct their own retrospectives to feed into the main R&D retrospective and should generally follow the same process outlined here.

## Requirements for an efficient retrospective

strong plan for the discussion. However, even iterations that seem fine on the

surface can harbor deep problems, so it is always best to be prepared.

## Establishing a safe environment

Retrospectives are inherently conversations about _what went well_ and _what

went wrong_ in a project or iteration. While it's easy to talk about _what went

well_, _what went wrong_ can be a touchy subject. Without a safe environment,

Retrospectives are inherently conversations about *what went well* and *what

went wrong* in a project or iteration. While it's easy to talk about *what went

well*, *what went wrong* can be a touchy subject. Without a safe environment,

issues may go unmentioned, and the group won't improve as rapidly as they

otherwise could. To collect as much feedback as possible, we recommend

that you observe the following:

   is as an individual participant, not as the moderator. If the moderator wants

   to take a very active role in the discussion, they should find a peer,

   Director, or other member of the group willing to moderate.

1. **Emotions are not only _allowed_ in retrospectives, but they should also be encouraged.** 

1. **Emotions are not only *allowed* in retrospectives, but they should also be encouraged.**

   Emotional language ("I was angry when...," "It made me sad

   that...") not only helps convey intensity, it also helps expose issues that

   may have been difficult to sort out otherwise. Make sure all participants

   any other number of fact collecting exercises.

1. **Generate insights** - now that you have all of the facts, try to work

   together to identify patterns or causal relationships (because we did

   _x_, _y_ happened).

   *x*, *y* happened).

1. **Decide what to do** - with the insights firmly in hand, it should be

   fairly easy to identify action items for the group. This could be things

   to change with our process, it could be things to experiment with in the

---

title: "Engineering Manager Hiring"

description: "Hiring information and process to follow for Engineering Managers at GitLab."

---

- **Hiring is a priority.** GitLab is a fast-growing company, and paying

  attention to hiring is one of the highest-leverage activities a manager can

  perform. As long as there are vacancies on your team, hiring should be your top

---

aliases: /handbook/engineering/management/career-development

title: "Engineering Management Career Development"

description: "Career development information and process to follow for Engineering Managers at GitLab."

---

Outside of [hiring](/handbook/engineering/management/hiring/), the best way to improve the strengths of your team

is to practice career development coaching with your developers. Not all team members will want to become Staff Developers or Managers. Instead, identifying their individual career goals and proactively working towards those goal is the most effective way to help team members improve and have ownership over their careers. In addition to the company-wide notes on [career

mapping and

---

title: "Engineering Management Project Management"

description: "Project Management information and process to follow for Engineering Managers at GitLab."

---

[Product](/handbook/product/) is responsible for guiding the direction of our

product, and [technical leaders](../#how-engineering-management-works-at-gitlab)

are responsible for guiding the technical architecture to meet those