Foundations Stage
About
The responsibilities of this stage are described by the Foundations product category. Foundations is made up of multiple groups, each with their own features and areas of responsibility, noted last on this page.
- I have a question. Who do I ask?
In GitLab issues, questions should start by @ mentioning the relevant Product Manager for the product category.
GitLab team members can also use #s_foundations.
How we work
- In accordance with our GitLab values.
- Transparently: nearly everything is public, we record/livestream meetings whenever possible.
- We get a chance to work on the things we want to work on.
- Everyone can contribute; no silos.
- The goal is to have product give engineering and design the opportunity to be involved with direction and issue definition from the very beginning.
OKRs
For a list of active OKRs, check the OKR project.
Direction
The direction and strategy for Foundations is documented on https://about.gitlab.com/direction/foundations/. This page (and the category direction pages under the “Categories” header) is the single source of truth on where we’re going and why.
- Direction pages should be reviewed regularly by Product. When updating these pages, please CC the relevant group to keep your teammates informed.
- Product should make sure that their groups understand the direction and have an opportunity to contribute to it. Consider a monthly direction AMA for your group to field questions.
Career Development
Giving / receiving feedback
It can be hard to understand how you’re doing in your role, because feedback can come off as formal (annual reviews, 360 surveys, career development conversations, goal check-ins) or casual (in Slack channels, 1-1’s, MR reviews, team meetings.) We receive various kinds of feedback regularly and through different formats, so the type of feedback you’re receiving is not always clear. In order to be more intentional about the types of feedback given, here is a classification chart based on three types of feedback:
Label | Meaning | Example |
---|---|---|
(appreciation) | I want to thank you for doing this, and please do more of it in the future | “I did not expect that you would have created a working group, because you’ve done so, our whole team will benefit from the results.” |
(coaching) | I’m trying to help you improve a behavior you are already exhibiting or change a behavior that you currently have | “The reports that you give me are very helpful, and in the future we can schedule them for the first of the month to be more consistent.” |
(evaluation) | Tells you where you stand according to existing standards or expectations | “My expectation was that our decision would be transparent. Since it was not, our team has forgotten the decision, so we must be sure and meet that expectation next time.” |
Engineering Managers
This section lists relevant experience areas for individual contributors interested in the management track, new engineering managers, or existing engineering managers who may be lacking opportunities. This list can be used to identify opportunities in these areas.
Expert hiring manager
Expert hiring manager
- Experience with behavioral interviews
- Screening candidates for your team
- Identifying cultural answers or clarifying vague answers
- Identifying a headcount need in advance
Performance management
Performance management
- Crucial conversations
- Performance improvement plans
- Coaching on improvement areas
- Giving feedback
- Identifying underperformance
Communicating company decisions
Communicating company decisions
- Annual review, calibration sessions, compensation discussions
- Motivating team members on opportunities that come with negatives (borrow requests, engineering allocations, feature change locks)
Product area
Product area
- Triage reports
- Define and monitor productivity metrics, take action if necessary
- Collaborative planning
- Proactively identifying issues or recommending engineering allocations
- Leading an incident in your area
- Proposing and driving a borrow request (reactive)
- Shared OKRs and delivery
Team success
Team success
- Career growth development leading to promotions, mentors, technical interviews, maintainers
- Setting goals based on 360 feedback and career aspirations
- Smooth onboarding process
- Frequent and transparent handbook updates
- Identifying performance indicators for the team
- Becoming a mentor
Achieving consensus
Achieving consensus
- Facilitating a working group
- Participating in stage, sub-department, skip level, and/or engineering manager discussions
- Coordinating the dev on-call
- Experience with being Incident Manager On-Call (IMOC)
- Collaboration with the full product group quad planning
Personal growth
Personal growth
- Receiving feedback
- Continued learning, identifying new growth opportunities, and building a personal growth plan
- Seeking a mentor
Trainings offered by GitLab for EMs
Other resources
- Slack #aspiring-managers channel
- Handbook page dedicated to growing leadership skills for ICs
Staff Engineers
For an explanation on what to expect as a Staff engineer and a list of ideas for tactical initaitives, visit this page.
Team Days
Engineering management schedules Team Days every 2 quarters as a way to celebrate our wins as a team, with our counterparts, and look forward to the future. These are optional social events led primarily by the attendees in terms of activities and discussions, but scheduled and organized by engineering managers.
Sync meetings will occur in all time zones, and activities may happen throughout the day in a dedicated team day Slack channel. While optional, all team members should have an opportunity to participate for as long as they want, so capacity for all engineers should be accounted for during milestone planning.
Meetings
Although we have a bias for asynchronous communication, synchronous meetings are necessary and should adhere to our communication guidelines. Some regular meetings that take place are:
Meeting (Internal Only, limited access) | Frequency | DRI | Topics |
---|---|---|---|
SaaS Availability | Weekly | Infrastructure | Incident corrective actions, Feature Change Lock status, Past Due Infradev, Error Budget, or Security updates |
Engineering Stage Review Handbook | Monthly | Michelle Gill | Productivity metrics, Technical Roadmap updates |
Foundations and Data Science EM Meeting | Biweekly | Michelle Gill | Standards discussions, questions, help needed, FYIs, process improvements, collaborating on engineering stage direction, team event planning, leadership communication dissemination, wider initiative brainstorming, OKRs |
Core Development Staff Meeting | Biweekly | Tim Zallmann | Recurring staff meeting for updates across engineering management within Tim’s organization |
For one-off, topic specific meetings, please always consider recording these calls and sharing them (or taking notes in an internally available document.
Agenda documents and recordings can be placed in the shared Google drive (internal only) as a single source of truth.
All meetings should have an agenda prepared at least 12 hours in advance. If this is not the case, you are not obligated to attend the meeting. Consider meetings canceled if they do not have an agenda by the start time of the meeting.
Stage Reviews
The Engineering Stage Review is a monthly Engineering Manager meeting designed to evaluate team productivity, technical progress, and key metrics across the stage groups. In this meeting, we assess team productivity metrics and trends at a stage-wide level, review technical roadmap progress and align initiatives across teams, identify areas for improvement and discuss action plans, and connect related technical work across different teams.
Format:
- 50-minute monthly sessions, split into two parts:
- Data Science Session (covering AI Framework, Custom Models, MLOps, Duo Chat)
- AI Powered & Foundations Session (covering Duo Workflow, Global Search, Design System, Personal Productivity, Import & Integrate)
- Each team has approximately 10 minutes for review
- Metrics and updates are submitted 24 hours before the meeting for async review
Shared calendars
- Foundations: Important Dates - Use this calendar for stage-wide reminders (OKR due dates, promotion cycles, talent assessment timelines, regular holiday preparations)
- To add this calendar to your Google Calendar, use this calendar ID
c_kvfbp2t8edtgm4rjialus0834g@group.calendar.google.com
- To add this calendar to your Google Calendar, use this calendar ID
- Foundations Shared - Use this calendar for recurring group level reminders and meetings (Release kickoff, milestone planning, social calls)
- To add the shared calendar to your Google Calendar, please use this link (GitLab internal).
- To add a meeting to the shared calendar, please add the link in this document to the event.
- To add a new member to the shared calendar
- Click “Settings and Sharing” in the kebab menu when mousing over “Foundations Shared” in your Google Calendar sidebar under “My calendars”.
- Scroll to the “Share with specific people” section of the settings area. Click “Add people” and add the new member with “Make changes and manage sharing”.
- For a more detailed walkthrough, have a look at a quick video walkthrough
Skip Levels
Skip Levels with Michelle occur in 3 ways:
- Each month, skip level invites will be sent to approximately 10 team members depending on availability across teams. This equates to 1 skip level approximately every 6 months, therefore invites are sent based on the last meeting date.
- Monthly placeholder events are pre-scheduled in all regions also at that time and can be “claimed” on this calendar (internal only) by any engineer or engineering manager. If you don’t see any - they are taken, follow step 3.
- Michelle is never too busy for a skip level. Simply schedule one. 🙂
Metrics
Dashboards & Handbook | Async Updates | Sync Updates |
---|---|---|
Error Budget (Handbook) | Monthly reporting issue | Saas availability when red |
Past due Infradev (Handbook) | Monthly reporting issue (Foundations, Data Science) | Saas availability when SLA is past or backlog is unmanageable |
Bug/Vulnerabilities (SLAs) | Monthly reporting issue (Foundations, Data Science) | Saas availability when SLA is breached or backlog is unmanageable |
Recent Incidents | Reliability Reports | Saas availability when applicable |
MR Rate (Handbook) | - | Engineering stage review |
Mean Time to Merge | - | Engineering stage review |
Review Time to Merge (Handbook) | - | Engineering stage review |
Review Rate | - | Engineering stage review |
Technical Roadmap progress (Handbook) (Data Science, Foundations) | - | Engineering stage review |
Say/Do (Handbook) | Deliverables | Engineering stage review |
Development
Say/Do Ratio
When we commit to a new milestone, engineering managers apply the ~Deliverable label to all issues they are able to commit to based on capacity. This serves as a promise from engineering to product as well as a signal for the most important issues in the milestone for the team to pick up. At the end of the milestone, successfully completed issues with the ~Deliverable label are assessed against the total number of ~Deliverable issues in order to create the Say/Do Ratio (7 issues completed of 10 committed to is a 70% Say/Do result.)
The Say/Do Ratio is a metric used to:
- Provide predictability and stability when milestone planning
- Raise flags about the types of issues that are frequently disruptive
- Measure how well we are meeting our commitments to our customers
Links and resources
- Stage links
- Discussions and issues are located at
gitlab-org/manage
- General Slack #s_foundations
- Skip level calendar (Internal Only)
- Discussions and issues are located at
- Engineering links
- Manage and Data Science engineering discussion are located at
gitlab-org/manage/engineering-managers
- Social channel #pikachus-social
- Engineering Manager Slack #s_manage_data_science_ems
- Manage and Data Science engineering discussion are located at
Global Search Group
Import and Integrate Group
Personal Productivity Engineering Team
05ab939a
)