Skip to content
Snippets Groups Projects
Unverified Commit a799a36f authored by Jamie Maynard's avatar Jamie Maynard
Browse files

Move managment pages into place

parent 47f02e65
No related branches found
No related tags found
1 merge request!1662Migrated management from www-gitlab-com to here
---
title: "Engineering Management"
---
......@@ -13,16 +12,10 @@ for us to specialize training and responsibility for each of:
- **Professional leadership**, as represented by [Engineering management](/handbook/engineering/career-development#roles).
While technical leadership tends to come naturally to software engineers,
professional leadership can be more difficult to master.
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
......@@ -46,13 +39,14 @@ Each Engineering Manager (EM) is responsible for developing a Backup Plan in the
| 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 |
| 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.
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.
......@@ -78,7 +72,7 @@ work to an extent. However, please keep the following advice in mind:
## Management Responsibilities
The sections below aim to inform you of the responsibilities that an
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.
......@@ -92,27 +86,27 @@ information, and process to follow.
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:
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:
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:
Where:
- Acting or Interim roles are [temporary management positions](/handbook/engineering/career-development/#temporary-management-positions).
- `Senior` manager roles are introduced when needed, usually related to management [span of control](/company/team/structure/#management-group) in the relevant department.
......
---
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
......@@ -26,12 +19,11 @@ benefit from a safe environment. Similarly, an iteration that has nothing but
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:
......@@ -48,7 +40,7 @@ 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
......@@ -60,7 +52,7 @@ that you observe the following:
group, where necessary - if someone's role or contributions are going to be
discussed, they should have the opportunity to contribute to the
retrospective as well.
1. **Use an issue to collect feedback asynchronously.** Consider using an issue to collect
1. **Use an issue to collect feedback asynchronously.** Consider using an issue to collect
feedback asynchronously. This allows everyone involved to think about and record their feedback on their
own time. It is recommended that the group uses the [retrospective issue template](https://gitlab.com/gitlab-org/async-retrospectives/-/blob/master/templates/default.erb) for the issue.
1. **When necessary, get people face to face.** After a particularly difficult
......@@ -93,7 +85,7 @@ group, we recommend something that follows this general pattern:
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
......@@ -26,4 +19,4 @@ description: "Hiring information and process to follow for Engineering Managers
to do it well can take years. In times of rapid growth, it may consume 50% or
more of your time. Please use every resource available to you, from
more experienced hiring managers in the company to the many resources
[available in our handbook](/handbook/hiring/interviewing/).
\ No newline at end of file
[available in our handbook](/handbook/hiring/interviewing/).
---
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
......@@ -48,4 +42,4 @@ here are some important considerations for the Engineering team:
and you should feel free to add to or remove from the plan as they grow and
you learn more about them. If and when you feel that they are ready for
promotion, please follow the [normal promotion
process](/handbook/people-group/promotions-transfers/).
\ No newline at end of file
process](/handbook/people-group/promotions-transfers/).
---
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
......
---
title: "Pulse Survey"
---
## Overview
Some engineering teams have been piloting a weekly pulse survey.
......@@ -47,9 +40,9 @@ Do not edit any column names or results.
The next step is to be sure [Sheetload](/handbook/business-technology/data-team/platform/#using-sheetload) can read and ingest the new tab.
The [Sheetload readme](https://gitlab.com/gitlab-data/analytics/tree/master/extract/sheetload) is the SSOT for the following steps, but an abbreviated version is included for ease of info.
1. Add the new tab to the [sheets.txt](https://gitlab.com/gitlab-data/analytics/blob/master/extract/sheetload/sheets.txt) file following the `pulse_survey.pulse_survey_group_team` convention (there are examples in the file.)
2. Add a new dbt model to `analytics/transform/snowflake-dbt/models/sheetload/base` ([location](https://gitlab.com/gitlab-data/analytics/tree/master/transform/snowflake-dbt/models/sheetload/base)) following the naming convention of `sheetload_pulse_survey_group_team.sql`; this is a pretty straightforward SQL file and should follow an [existing example](https://gitlab.com/gitlab-data/analytics/blob/master/transform/snowflake-dbt/models/sheetload/base/sheetload_pulse_survey_configure_be.sql).
3. Substitute the group and team values (lines 12 and 13 in the example file) to match the survey's group and team.
4. Update the `table_list` list set beginning on line 7 in `analytics/transform/snowflake-dbt/models/sheetload/xf/engineering_pulse_survey.sql` ([Location](https://gitlab.com/gitlab-data/analytics/blob/master/transform/snowflake-dbt/models/sheetload/xf/engineering_pulse_survey.sql)) to add the new dbt model; follow the existing syntax example of `ref('filenamewithoutthe .sql at the end')`.
1. Add a new dbt model to `analytics/transform/snowflake-dbt/models/sheetload/base` ([location](https://gitlab.com/gitlab-data/analytics/tree/master/transform/snowflake-dbt/models/sheetload/base)) following the naming convention of `sheetload_pulse_survey_group_team.sql`; this is a pretty straightforward SQL file and should follow an [existing example](https://gitlab.com/gitlab-data/analytics/blob/master/transform/snowflake-dbt/models/sheetload/base/sheetload_pulse_survey_configure_be.sql).
1. Substitute the group and team values (lines 12 and 13 in the example file) to match the survey's group and team.
1. Update the `table_list` list set beginning on line 7 in `analytics/transform/snowflake-dbt/models/sheetload/xf/engineering_pulse_survey.sql` ([Location](https://gitlab.com/gitlab-data/analytics/blob/master/transform/snowflake-dbt/models/sheetload/xf/engineering_pulse_survey.sql)) to add the new dbt model; follow the existing syntax example of `ref('filenamewithoutthe .sql at the end')`.
After following these steps and getting the MR merged, these will get picked up on the next Sheetload and dbt runs.
The Sisense dashboard can always be refreshed to reflect the latest information.
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment