CSM Issue Tracking and OKRs
For more information visit GitLabs Objective and Key Results (OKRs) page.
Purpose
This page provides an overview of CSM team issue tracking, OKRs, and the OKR process.
OKRs should provide continuous strategic alignment with the business. Our Big Rocks are our annual OKRs and our quarterly OKRs contribute to them.
GitLab.com (Epics/Issues) is THE best place to track the work we are doing! The goal is a streamlined way to submit ideas, have those prioritized and agreed and then coordinate the team to work on key focus areas to get the job done. We can’t work on everything at once, so we aim to empower everyone to submit ideas and collaborate while keeping actual work focused on core priorities.
Additionally, this process should lead the way in leveraging GitLab features to demonstrate we can eat our own dog food and live a customer’s life in our day-to-day duties. The team should have a single process to provide updates on progress and communicate the likelihood of achieving the outcomes below:
-
Leadership able to easily track work across teams
-
Team-level organization to see progress and where help is needed
-
Managers support in 1:1s with an improved view of individual team member’s internal work
As is the case with all our work, the development of the process to track our work within the CS team is iterative and so it is recommended that you bookmark this page and check back frequently as this process is fine tuned.
Terminology
-
Objective: The Mission
-
Key Results: Measures of movement and behavior
-
Initiatives: Activities that we theorise will move the key results in a direction that brings us closer to achieving the Objective.
Why is it Important We Do This Now?
-
Improved visibility of team workload and priorities
-
Streamlined idea submission and review process
-
Enhanced ability to track progress and identify bottlenecks
-
Better alignment of work with strategic priorities
-
Increased transparency and collaboration within the team
-
Data-driven decision-making through GitLab’s reporting features
Principles
OKRs Should be Inclusive (Segments, regions etc) and lean in to heavily into our bias towards asynchronous contributions.
Objectives
-
Outcome over output
-
Inspirational and aspirational
-
Avoid overlapping objectives
-
Business aligned
Key Results
-
Measurable
-
Standard format:
<Verb> <measure> from <x> to <y>
-
Leading and lagging measures
-
No more than 3 to 5 Key Results per OKR
What Impact will this have to GitLab and its Customers?
This will have significant impacts on both GitLab and its customers:
For GitLab
-
Demonstrates the effectiveness of GitLab’s own tools for project management
-
Improves internal efficiency and productivity of the CS AMER team
-
Enhances cross-functional collaboration and transparency
-
Provides real-world use cases and feedback for product improvements
-
Strengthens the company’s “eat our own dog food” philosophy
For Customers
-
Leads to more responsive and efficient customer support
-
Provides a relatable example of GitLab usage for project management
-
Potentially results in improved features based on internal feedback
-
Demonstrates GitLab’s commitment to using and improving its own products
Data Model
-
Issues: Represents an Idea or Project to be undertaken. An Issue should represent no more than a quarter of duration of an activity. If it is more than a quarter, we should break it down into multiple issues.
-
Labels: Will be used to track additional reporting attributes and manage workflow state
-
Epic: Should indicate/tie an Issue back to a Strategic Objective / Pillar for CS
-
Milestone: Should be the fiscal quarter we are planning to deliver & close the work
Process
GLQL Tracking Table
Whereas previous iterations used issue boards for tracking work, the team is currently using a GLQL tracker within the CSMERM wiki.
Proposing OKRs
Idea Submission
-
Team members choose the appropriate subgroup and project for their issue. These are organized by region and role, with one subgroup for cross collaboration between these. If you are unsure which project to open your issue in, default to your team’s region and role (e.g. a CSM located in AMER would choose subgroup
AMER CS
and projectCSM
), or ask your manager for guidance. -
Team members create new issues with the
CS-Status::Proposed
scoped label. -
Use the issue template below for consistent information capture. The template should capture:
-
30-sec elevator pitch
-
Why is it important we do this now? Is this due to an OKR?
-
What impact will this have to GitLab and its customers?
-
Team member and resource support to get it done?
-
Estimated Effort and ETA
-
Ownership and Resourcing
-
Once prioritized, projects will be assigned a CS Manager as DRI
-
Using a CS Manager as DRI ensures we have visibility across the CS leadership team and can fairly represent the workload in any further resourcing/prioritization discussions
-
In addition to the CS Manager, at least one Senior/Staff CSx team member should be assigned to lead the discussion and at least one additional CSx team member to assist with the effort. If at least 2x team members can’t be identified to drive the issue to closure, then please realign with the CS Manager to discuss whether this is a current priority or should wait for additional team member availability.
Review and Prioritization
-
Regular management team meetings to review
CS-Status::Proposed
issues -
Categorize and prioritize issues using the labeling system (this should link to the labeling system section below)
-
Include Mgr CS as DRI
-
Identify 2x CSx, at least one Staff/Senior to manage the issue
-
Remove the
CS-Status::Proposed
label after review
Workload Management
-
Use
CS-Priority::Top-5
label for immediate action items determined by Mgr CS (This would include when tied back to a Big Rock or OKR) -
Assign
CS-Priority::High
issues to the current sprint/work cycle determined Mgr CS -
Utilize GitLab boards for workflow visualization
-
Reference the GLQL tracker referenced above as a dashboard
Backlog Management
-
Non-priority issues remain in the backlog
-
Regular backlog review and reprioritization
-
Use milestones for future sprint planning
Progress Tracking
-
Implement time tracking on issues
-
Use the
CS-Status::Concern
scoped label for issues facing obstacles and require leadership assistance -
Use the
CS-Status::On Track
scoped label for issues progressing as expected -
Use the
CS-Status::On Hold
scoped label for issues that are temporaryily paused
Triage Bot Policies
Triage bot utilizes policies to determine what actions to perform on what items.
Each policy contains rules for the resource set. These rules are contained within an array that detail what to run on and what to actually do. Triage bot fields are:
Missing Field | Example |
---|---|
Issue Assignee | @csmname |
CS-Priority Label | ~“CS-Priority::Top-5” |
CS-Team Label | ~“CS-Team::CSM” |
CS-Status Label | ~“CS-Status::On Track” |
CS-Region Label | ~“CS-Region::AMER” |
OKR label | ~“OKR” |
LT Sponsorship label | ~“CSLT::CS DIR NAME” |
Milestone | ~FYXX-QX |
XLT DRI label | ~“CSXLT::MGR CS NAME” |
Completion and Review
When the work is complete, label the issue with CS-Status::Ready for Review
to indicate that it is done and needs final review by CS Managers and potentially external stakeholders.
-
Prior to tagging
CS-Status::Ready for Review
, conduct retrospectives and provide summary lessons learned on the issue. Ensuring we have Lessons Learnt or Objectives Achieved allows us to share & celebrate the work done and completed. -
Post Review, if no other action is required, move completed issues to “Done” on the board.
Labeling System
Each issue should have labels and field values to satisfy the triage bot policies listed above. Below is a table of definitions for each label used in our tracking schema.
Category | Label | Definition |
---|---|---|
GitLab Department | Customer Success | Defines the relevant GitLab department as Customer Success for global OKR tracking |
OKR | OKR | Required label for tracking OKRs across GitLab |
Initiative | Initiative | Non-OKR initiative being tracked by CS org |
CS-Status | CS-Status::On Track | Issue is progressing as expected |
CS-Status | CS-Status::Watchpoint | Issue is running behind and needs re-alignment on objective timeline between DRI team |
CS-Status | CS-Status::Concern | Issue has signficant obstacles that jeopardize completion by due date and require leadership assistance |
CS-Status | CS-Status::Proposed | Objective or initiatves has been proposed to CS leadership but not yet approved |
CS-Status | CS-Status::Not Started | Issue has been identified but work has not yet begun |
CS-Status | CS-Status::On Hold | Issue is temporarily paused |
CS-Status | CS-Status::Closed Success | Issue has been successfully completed |
CS-Status | CS-Status::Closed Not A Priority | Issue was determined to be not be a priority and closed |
CS-Status | CS-Status::Ready for Review | Work on the issue is completed and is ready for signoff from leadership |
CS-Priority | CS-Priority::Top-5 | Top-5 OKR being tracked by CS leadership |
CS-Priority | CS-Priority::High | OKR or initiative that significantly impact CS team objectives and metrics |
CS-Priority | CS-Priority::Medium | OKR or intiative that moderately impact CS team objectives and metrics |
CS-Priority | CS-Priority::Low | “Nice-to-have” OKR or intiative that would be beneficial but aren’t critical |
CS-Region | CS-Region::Global | Organization-wide objective |
CS-Region | CS-Region::AMER | AMER specific objective |
CS-Region | CS-Region::EMEA | EMEA specific objective |
CS-Region | CS-Region::APAC | APAC specific objective |
CS-Team | CS-Team::CSM | Customer Success Manager team |
CS-Team | CS-Team::CSA | Customer Success Architect team |
CS-Team | CS-Team::On Demand (CSE) | Customer Success Engineer team |
CS-Team | CS-Team::RM | Renewal Manager team |
CS-Team | CS-Team::Tech-Touch | Tech-Touch (Digital Experience) team |
CS-Team | CS-Team:: Onboarding | Onboarding team |
LT Sponsorship | CSLT::[Name] | CS leadership team member sponsoring objective or initiative |
XLT DRI | CSXLT::[Name] | CS manager responible for objective or initiative |
OKR Schedule
The CSM OKR timeline is as follows:
Quarter Start | Task |
---|---|
4 weeks out | VP shares top goals with leadership team for feedback |
4 weeks out | Leadership team collaboratively draft goals for next quarter and agree DRIs |
4 weeks out | Leadership team review current OKR status |
2 weeks out | Leadership team 50 minute draft review meeting. After, OKRs are put into GitLab and links are shared in #csm-updates Slack channel |
2 weeks out | Leadership team discusses with their respective teams and polishes OKRs |
1 week out | Closing ceremony and playback of previous OKRs |
0 | Update OKRs to be active |
Additional Resources
02e9696a
)