|Date Created||August 28, 2020|
|End Date||April 22, 2021|
|Slack||#wg_ic-gearing (only accessible from within the company)|
|Google Doc||Working Group Agenda (only accessible from within the company)|
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.
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.
The functional leads (1 per department, 4 for the development department) will be repsonsible for:
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.
|Working Group Role||Person||Title|
|Facilitator||Steve Loyd||Infrastructure VP|
|Development:Dev&Ops&CICD Functional Lead||Nick Thomas||Staff Backend Engineer|
|Development:Dev&Ops&CICD Functional Lead||Natalia Tepluhina||Staff Frontend Engineer|
|Development:Secure&Govern Functional Lead||James Johnson||Staff Security Engineer|
|Development:Enablement&Growth Functional Lead||DJ Mountney||Staff Engineer|
|Infrastructure Functional Lead||Alessio Caiazza||Staff Backend Engineer|
|Quality Functional Lead||Zeff Morgan||Senior Software Engineer in Test|
|Security Functional Lead||Paul Harrison||Staff Security Engineer|
|Support Functional Lead||Will Chandler||Staff Support Engineer|
|UX Functional Lead||Lorie Whitaker||Staff UX Researcher|
|Member||Christopher Lefelhocz||Development VP|
|Member||Roos Takken||People Business Partner, Engineering|
|Member||Darva Satcher||Senior Manager, Development|
|Member||Jean du Plessis||Engineering Manager, Development|
|Member||Craig Gomes||Engineering Manager, Memory & Database|
|Member||John Jarvis||Staff Site Reliability Engineer.|
|Member||Grzegorz Bizon||Staff Backend Engineer|
|Member||Pedro Moreira de Silva||Staff Product Designer|
|Member||Chad Woolley||Senior Backend Engineer|
|Member||Kerri Miller||Senior Backend Engineer|
|Member||Craig Barrett||Senior Site Reliability Engineer|
|Member||Giuliana Lucchesi||People Business Partner, Development|
|Member||Rachel Nienaber||Engineering Manager|
|Member||Joern Schneeweisz||Staff Security Engineer|
|Member||Vitaly Slobodin||Senior Frontend Engineer|
|Member||Thong Kuah||Staff Backend Engineer|
|Member||Rayana Verissimo||Staff Product Designer|
|Member||Sean Carroll||Engineering Manager, Source Code|
|Executive Sponsor, DRI||Eric Johnson||Chief Technology Officer|