Excludes indirect engineering leadership from MR rate.

Why is this change being made?

A discussion on whether senior engineering managers should be included in MR Rate calculations of teams revealed that this is currently inconsistent within GitLab depending on how the Single Source of Truth for group membership (specialty) is recorded for the various senior engineering managers.

The problem as I would state it is that for groups that report into a senior engineering manager, each group in the stage(s) would have an additional team member added to the denominator of their MR Rate calculations (again, if that senior engineering manager has a specialty of the team rather than the section) causing, in some cases, significant drops in MR Rate and productivity metrics unrelated to the productivity or efficiency of the team members. The Engineering Manager of the group is included but is also accountable for group MR Rate [ Fullstack | Backend | Frontend ] so I'm not designing this MR to change that.

Keeping in mind that we do want to understand the impact of engineering leadership and avoid a "top heavy" organisation or at least understand that aspect of organisation structure, this proposal aligns leadership at the level of their scope.

As a first step, I'm proposing this change to the definition of MR Rate to explicitly state that indirect engineering leadership should not be included in MR Rate calculations. This would mean that direct leadership would still be included, this looks something like:

• Group includes engineering manager
• Stage includes senior engineering manager
• Section/sub-department includes (senior) director
• Department includes VP
• Division includes CTO

The general idea that indirect engineering leadership not be included should be a sufficient flexible concept to allow for different organisation structures like a Senior Engineering Manager managing a Section/Sub-department for example.

What else needs to change?

To enable this flexibility, we'll need to have each of the organisation units added to our single source of truth for specialty membership. This could include WorkDay, Sisense, and other systems at GitLab. At a minimum, this would mean having specialties for groups, stages, sub-departments, departments, and divisions added to this Single Source of Truth.

Folks in leadership will need to review their organisation unit membership in the Single Source of Truth (WorkDay/BambooHR) to make sure it accurately reflects their direct/indirect group membership.

We'll need to evaluate whether our dashboards/charts need to be adjusted should we require different types of organisation units.

Other suggestions?

An alternate approach could be to add the concept of indirect leadership to the Single Source of Truth which would also require changes to our other reporting. This would mean that all engineering leaders would be added to organisational units in the Single Source of Truth but that membership would be identified as indirect and wouldn't then be included in the MR Rate calculations.

This approach might enable us to have both types of reporting direct and indirect. This almost certainly would require changes to our data pipelines and dashboards and may be more flexible but would likely require a more involved effort.

We could also consider removing management entirely from MR Rate calculations as has been suggested [ example | example ]. We run the risk of not having clear data showing or at least including management which could lead to a lack of understanding of the impact of a "top heavy" organisation. This change could be made within dashboards themselves by removing any engineering leadership.

Another suggestion proposed that indirect engineering leadership be removed and we would also add engineering managers to the numerator but not denominator of the MR Rate calculation. This change would require some aspects of the proposed solution (removing indirect leadership) as well as adjustments to dashboards wherever MR Rate was being calculated.

Author Checklist

• Provided a concise title for this Merge Request (MR)
• Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
  • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added.
• Assign reviewers for this MR to the correct Directly Responsible Individual/s (DRI)
  • If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the Maintained by section on the page being edited
  • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies
• If the changes affect team members, or warrant an announcement in another way, please consider posting an update in #whats-happening-at-gitlab linking to this MR
  • If this is a change that directly impacts the majority of global team members, it should be a candidate for #company-fyi. Please work with internal communications and check the handbook for examples.

---