The Utilization Team often works at the interface between GitLab Core and Fulfillment applications. This includes components in the Utilization category like consumables management (storage, CI minutes, seats, etc.), usage reporting, and usage notifications. Our customers use GitLab SaaS, GitLab self-managed, and internal tooling.
For more details about the product vision for Fulfillment, see our Fulfillment page.
The Utilization group manages the Utilization category.
We try to work async as much as possible. However, there are occasions where synchronous communication might be better suited for the task. Our Weekly Team Sync meeting is one of those occasions where we can celebrate wins, collaborate quickly over a number of issues, and generally have some face-time in an all-remote environment.
The Utilization group is spread across at least 4 different timezones.
The Utilization Team meets weekly on Tuesdays alternating each week between at 9:30 AM (6:30 AM PT // 2:30 PM UTC) and 4:00 PM US Eastern Time (1:00 PM PT // 9:00 PM UTC // Wednesday 10 AM NZT) to accommodate teammates in their timezones via Zoom.
Using the [REC] meeting prefix, the meeting is automatically uploaded into the GitLab Videos Recorded folder in Google Drive on an hourly basis via a scheduled pipeline. All teammates are set as alternate hosts and should be able to record the meeting is the Engineering Manager is not present. The recording link will be placed into the agenda after the recording is available.
All team members are encouraged to add topics to the weekly agenda async. In the unlikely event that the agenda is empty, we'll cancel the meeting.
Engineers are responsible for providing async issue updates on active, assigned issues when progress is made. Following the template and guidance for async updates for the entire Fulfillment Sub-department, updates should be made at least weekly. These updates help keep collaborators, stakeholders, and community contributors informed on the progress of an issue.
The Engineering Manager will report before the end of each week on milestone progress in the current milestone planning issue on the following topics:
**Total Weight Closed** XX
**Total Weight Open** XX (XX in dev)
**Deliverable Weight Closed** XX
**Deliverable Weight Open** X (XX in dev; X blocked)
**Blocked Issues** X issue(s) (X weight) link, description
The Engineering Manager will report on the progress of OKRs every two weeks as a comment in relevant issues and in the Ally reporting tool.
Current OKRs: FY22-Q3
Past OKRs:
It is important to take time off so that you can rest, reset, avoid burnout, take care of loved ones, etc. You are encouraged to take time for yourself or your family following our operating principle of Friends and Family First, work second.
When going out of office, please be sure to clearly communicate your availability with other people. The following steps are required when submitting a PTO notification.
In PTO by Roots, select a role as your backup during your PTO. Please assign the team slack channel #g_utilization as your backup to help distribute the workload. Consider if your current work in progress requires a substitute DRI and assign a single person for those specific issues.
Add the Fulfillment Shared Calendar to your PTO by Roots settings so your PTO events are visible to everyone in the team. The calendar ID is: gitlab.com_7199q584haas4tgeuk9qnd48nc@group.calendar.google.com Read more about PTO in the handbook.
Update your GitLab.com status with your out of office dates by clicking on your profile picture and selecting "Edit Status." For Example: OOO Back on yyyy-mm-dd Adding OOO to your status message will keep you from appearing in the reviewer roulette.
| Date | Event |
|---|---|
| 10th | PM creates a Planning Issue and pings the EM(s) in the Planning Issue for review & preliminary weighting. EM and PM calculate capacity, add to Planning Issue. |
| 10th-14th | EM & ICs add weights to issues in the backend and frontend build boards. |
| 15th | PM adds ~Deliverable labels to issues. |
| 17th | Last day of milestone PM adjusts current and upcoming issues to reflect slippage from the current milestone. ~Deliverable labels are adjusted as necessary. |
| Team Sync Closest to the Next Milestone | PM reviews the upcoming milestone plan with the team. |
| 18th | Milestone begins |
| 22nd | Release |
For feature work, we follow the estimation rubric provided on the Fulfillment handbook page that matches a description to a weight mostly along complexity and breadth of change required.
We use spikes to produce a design document or similar artifact that is useful for planning out feature work. This can simply be, but not limited to, an issue containing a summary of the discussions on the topic, answers to questions from the spike description, links to any PoC MRs produced, a roadmap or other detailed outline.
Estimating the effort required for a Spike is not as clearly set or easily defined as feature work because the complexity can't be accurately estimated. Take into consideration the following criteria when adding a weight to spike issue.
Follow the same Fibbonacci scale used for feature work from 1 (low, quick, easy) to 5 (large, lengthy, difficult). Historically, we have not estimated spikes higher than 5.
The following lists are links to Sentry and other tools where we proactively identify and triage Utilization problems. Proactive triage will not only provide for a more secure and robust application, but also provide for a better user experience especially as we iterate on features, reveal features from behind a feature flag, or introduce a refactoring. It leans into our Bias for Action operating principle and raises our awareness of application performance.
| Subject | Link | Notes |
|---|---|---|
| CustomersDot syncing | Sentry | UpdateGitlabPlanInfoWorker class is used to sync data between CustomersDot and GitLab |
| GitLab Subscriptions | Sentry | Results could be refined by controller, e.g. SubscriptionsController |
| Billing errors | Sentry | Results could be further refined by controller, e.g. Groups::BillingsController, Projects::BillingsController |
| Rails logs | Kibana | Utilization feature category Rails logs for the last 7 days |
| Sidekiq logs | Kibana | Utilization feature category Sidekiq logs for the last 7 days |
| Billable Member API | Grafana dashboard | - |
| CustomersDot Bug Issues | Issues | - |
| GitLab Bug Issues | Issues | - |
There's a way in sentry to create an issue for any error you find.
e.g. https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/2505559/?query=is%3Aunresolved%20UpdateGitlabPlanInfoWorker
See links in the right sidebar:
Although both links look the same, the first link is for creating an issue in the security repo, the second should be for the project (CustomersDot/GitLab) accordingly.
Iteration powers Efficiency and is the key that unlocks Results, but it's also really difficult to internalize and practice. Following the development department's key metrics we strive to deliver small and focused MRs.
Following a similar process to Milestone Retrospectives, we employ Iteration Retrospectives on a quarterly basis.
Key Takeaways
(Sisense↗) We also track our backlog of issues, including past due security and infradev issues, and total open SUS-impacting issues and bugs.
(Sisense↗) MR Type labels help us report what we're working on to industry analysts in a way that's consistent across the engineering department. The dashboard below shows the trend of MR Types over time and a list of merged MRs.
(Sisense↗)
(Sisense↗)