Govern Sub-department
The Govern sub-department teams are the engineering teams in the Govern Stage of the product.
Vision
To support GitLab’s product vision through alignment with the Govern stage product direction.
Groups
Priorities
Group priorities are reviewed collaboratively with product counterparts and published on the Govern direction pages
Product Documentation Links
- Security Dashboard
- Vulnerability Pages
- Security scanner integration
- Secure and Govern terminology
- Govern testing priorities
Sub-department development people leaders
| Name | Role |
|---|---|
 Phil Calder
|
Director of Engineering, Govern |
 Adil Farrukh
|
Engineering Manager, Govern:Authentication |
 Jay Swain
|
Engineering Manager, Govern:Authorization and Anti-abuse |
 Alan (Maciej) Paruszewski
|
Engineering Manager, Govern:Security Policies |
 Neil McCorrison
|
Engineering Manager, Govern:Threat Insights |
 Nathan Rosandich
|
Engineering Manager, Govern:Compliance |
To contact Govern sub-department development people leaders leaders use the following aliases:
- GitLab:
@gitlab-org/govern/managers - Slack:
@s_govern_managers - Slack channel:
#govern-development-people-leaders
All Team Members
Authentication
| Name | Role |
|---|---|
|
Adil Farrukh
|
Engineering Manager, Govern:Authentication |
 Andrew Evans
|
Senior Backend Engineer, Govern:Authentication |
 Bogdan Denkovych
|
Backend Engineer, Govern:Authentication |
 Drew Blessing
|
Senior Backend Engineer, Govern:Authentication |
 Eduardo Sanz-Garcia
|
Senior Frontend Engineer, Govern:Authentication |
 Imre Farkas
|
Staff Backend Engineer, Govern:Authentication |
 Smriti Garg
|
Senior Backend Engineer, Govern:Authentication |
 Aboobacker MK
|
Senior Backend Engineer, Govern:Authentication |
Authorization and Anti-abuse
| Name | Role |
|---|---|
|
Jay Swain
|
Engineering Manager, Govern:Authorization and Anti-abuse |
 Alex Buijs
|
Senior Fullstack Engineer, Govern:Authorization |
 Daniel Tian
|
Senior Frontend Engineer, Govern:Authorization |
 Eugie Limpin
|
Senior Fullstack Engineer, Govern:Anti-Abuse |
 Hinam Mehra
|
Fullstack Engineer, Govern:Authorization |
 Ian Anderson
|
Staff Backend Engineer, Govern:Anti-Abuse |
 Jarka Košanová
|
Staff Backend Engineer, Govern:Authorization |
 Mo Khan
|
Senior Backend Engineer, Govern:Authorization |
Compliance
| Name | Role |
|---|---|
|
Nathan Rosandich
|
Engineering Manager, Govern:Compliance |
 Aaron Huntsman
|
Senior Backend Engineer, Govern:Compliance |
 Harsimar Sandhu
|
Backend Engineer, Govern:Compliance |
 Hitesh Raghuvanshi
|
Senior Backend Engineer, Govern:Compliance |
 Huzaifa Iftikhar
|
Senior Backend Engineer, Govern:Compliance |
 Illya Klymov
|
Senior Frontend Engineer, Govern:Compliance |
 Sam Figueroa
|
Fullstack Engineer, Govern:Compliance |
Security Policies
Alexander Turinske
Andy Schoenen
Artur Fedorov
Dominic Bauer
Marcos Rocha
Martin Cavoj
Sashi Kumar KumaresanThreat Insights
Bala Kumar Subramani
Gregory Havenga
Lorenz van Herwaarden
Malcolm Locke
Mehmet Emin Inac
Samantha Ming
Savas Vedova
Subashis Chakraborty
Brian Williams
Dave Pisek
Michał ZającStable Counterparts
The following members of other functional teams are our stable counterparts:
| Name | Role |
|---|---|
 Alana Bellucci
|
Senior Product Manager, Govern:Threat Insights |
 Camellia X. Yang
|
Senior Product Designer Govern:Compliance and Govern:Security Policies |
 Evan Read
|
Senior Technical Writer, Govern:Compliance, Manage:Import and Integrate, Systems:Distribution, Systems:Gitaly |
 Grant Hickman
|
Senior Product Manager, Govern:Security Policies |
 Harsha Muralidhar
|
Senior Software Engineer in Test, Govern |
 Hannah Sutor
|
Principal Product Manager, Govern:Authentication and Authorization |
 Joseph Longo
|
Senior Manager, Governance and Field Security |
 Joe Randazzo
|
Product Manager, Govern:Authorization |
 Lucas Charles
|
Principal Engineer, Secure & Govern |
|
Ottilia Westerlund
|
Security Engineer, Fulfillment (Fulfillment Platform, Subscription Management), Govern (Security Policies, Threat Insights), Monitor (Observability), Plan (Product Planning), AI-powered (Duo Chat, AI Framework, AI model validation, Custom models) |
|
Phil Calder
|
Director of Engineering, Govern |
 Sam White
|
Group Manager, Product - Govern |
Govern staff meeting
The Govern stage engineering department leaders meet weekly to discuss stage and group topics in the Govern staff meeting. This meeting is open to all team members and is published on the Govern stage calendar.
Meetings have an agenda and are async-first, where the aim is to resolve discussions async and leave time in the meeting to deep dive into topics that require more discussion.
We use the Govern Sub-department Board to better organize our discussions.
Weekly updates
The Govern development teams provide weekly status updates using an issue template and CI scheduled job. As priorities change, engineering managers update the template to include areas of interest such as priorities, opportunities, risks, and security and availability concerns. The updates are GitLab internal.
Quarterly review updates
Every quarter, an engineering manager for each group in the Govern Sub-department prepares the quarterly review update using the issue template and records approximately 5 minutes to summarize the last quarter from the engineering perspective and present a high-level plan for the group for the next one to respond to quarterly Product strategy and explain our goals for next quarter.
We aim to foster collaboration and communication between engineering managers in the Govern Sub-department, align groups on product priorities for the next quarter, and celebrate our successes together.
Quarterly review update template can be found here).
OKR planning
Our OKRs are a mixture of top down, aligned with Company-wide, Product, or Engineering Division OKRs, and bottom up engineering-led initiatives driven by our team members in Govern. Any team member can propose an OKR for Govern by creating a proposal issue in our internal OKR project. The issue can be used to collaborate and discuss the proposal. When we are ready to commit, we can create or align to an existing Objective, and add specific key results to track through the quarter.
Labels:
Sub-Department::Govern- for top-level sub-department Objectives.devops::govern- for Objectives and key results for the stage, and stage groupsgroup::- for Objectives and key results for a specific group
Each Objective and Key Result should have an assignee who is DRI for providing status updates throughout the quarter. Regular updates are preferred. At a minimum these should be updated
- By end of day, the second Friday of every month
- Ay the end of the quarter
OKRs can be changed or closed during the quarter if they are completed, or as our goals change. This ensures we are focusing on areas that are revelant to our current and future priorities.
Skills
Because we have a wide range of domains to cover, it requires a lot of different expertise and skills:
| Technology skills | Areas of interest |
|---|---|
| Ruby on Rails | Backend development |
| Go | Backend development |
| Vue, Vuex | Frontend development |
| GraphQL | Various |
| SQL (PostgreSQL) | Various |
| Docker/Kubernetes | Threat Detection |
PTO
To support our teams, and commitments made to internal and external customers, team members in Govern are encouraged to create a PTO issue before going on leave lasting a week or longer.
The issue provides a place to discuss and document coverage for any work in progress, or projects where the team member is the directly responsible individual (DRI), and support the Paid Time Off at GitLab policy.
We use an internal issue tracker as team member PTO is not public information, and a PTO template
When a team-member takes some time off, it is important that their work is still being followed up on if needed. We want to make sure that any MR that lands in staging and production environments while we are out gets proper attention and is verified by a counterpart. Therefore, when getting close to our time-off period, we should do the following:
- Any MR that can be put on hold until we’re back from PTO should be put in the
Draftstatus. This ensures that the MR won’t be merged accidentally without a clear DRI to follow up on it. - Other non-draft MRs and freshly merged MRs, which need to be verified on staging, should be assigned to another engineer. The additional DRI will be responsible to verify the changes if they land in staging while we’re out. When doing this, we must ensure that enough context has been provided in the MR’s description and/or the related issue (setup, testing, potential impact, design decisions, etc.).
Keep in mind that, while we strongly recommend following this process when taking some time off, it might not be relevant all the time. For example, if our time-off period is going to be short and/or our active MRs are minor enough, it might make sense to ignore these recommendations and follow up when we’re back.
Engineering Leadership - PTO or unavailable
Team members should contact any Govern Engineering Manager by mentioning in #sd_govern_engineering or #govern-development-people-leaders if they need management support for a problem that arises, such as a production incident or feature change lock, when their direct manager is not available. The Govern manager can provide guidance and coordination to ensure that the team member receives the appropriate help.
Some people management tasks, including Workday and Navan Expense, may require for escalation or delegation.
Metrics
Links and resources
- Stage links
- Discussions and issues are located at
gitlab-org/govern - General Slack #s_govern
- Social channel #sec-section-social
- Engineering Slack #sd_govern_engineering
- Govern Shared Calendar ID
gitlab.com_ed6207uel78de0j1849vjjnb3k@group.calendar.google.com
- Discussions and issues are located at
- Group #g_govern_security_policies
- Group #g_govern_threat_insights
- Group #g_govern_compliance
- Software Supply Chain Security working group
Technical Documentation Links
cf67742c)
