IC Gearing Working Group

Attributes

Charter

The charter of this working group is to consider whether to implement a Individual Contributor Gearing Ratio policy within Engineering, implement the decision if it’s decided to proceed. Ideally any policy could be adaptable to other divisions in the same company (Sales, Marketing, Finance, etc) since there is interest in doing so.

Since this is a potentially controversial decision for ~1300 team members, the working group should also document a generic version of the process we follow (if successful) to allow future controversial, but important decisions to be made by any leader in the company while preserving transparency, handbook-first, and everybody-can-contribute in a scaled way.

Scope and Definitions

The primary scope that the group will address through the charter is the current proposal and suggestion around “Staff+” Engineering roles and the implementation of gearing ratios for those roles.

The proposal and conversation leading to the formation of this working group can be found in this MR.

The working group has a primary goal to complete the initial implementation of this policy addition within Engineering. As a secondary concern, the working group will seek to structure this policy in a way that will allow for adoption elsewhere in the company, or as an example for other organizations outside of GitLab.

The working group will also seek to iterate on how GitLab can further scale everyone can contribute. The original MR for this change resulting in tremendous collaboration and very useful feedback. While incredibly valuable, it also resulted in a heavy work burden for the DRI. Some ideas on improving similar changes which expect to receive tremendous engagement have already been identified an this working group will take action on these where appropriate.

Deliverables & Expected Outcomes

Complete the initial iteration of Engineering Gearing Ratios for ICs above the Staff-level MR

1. Consolidate feedback from the MR process and document key themes, axioms, or other structures helpful in implementing further changes
2. Identify and communicate next phase(s) for iteration and further feedback
3. Publish and provide for additional feedback
4. Implement initial policy

Iterate on how to scale the processes supporting everyone can contribute

1. Identify areas where iteration can allow for better scaling for high engagement MRs
2. Implement iteration through handbook first suggestions

• TBD
• TBD

Roles and Responsibilities

The functional leads (1 per department, 4 for the development department) will be repsonsible for:

• Representing the needs of potentially affected people in their department/sub-dept
• Gathering and consildating feedback on specific proposals from their department/sub-dept
• Communicating the output from the working group (if any) and answering questions from their dept/sub-dept

Ideally the functional lead is someone who is an IC that might be affected by the policy put in place. but anyone capable of representing a department or sub-department in the fashion mentioned above is welcome.

View page source - Edit this page - please contribute.