Performance Management for Support Managers
What is this page?
This page is intended as a supporting structure for Support Managers in handling the particularities of performance in Support. It is not intended to replace the more comprehensive Underperformance Page in the Leadership section of the Handbook.
Managers should work with their reports to understand their current ability and their desire for growth. Using this understanding managers should set performance goals and track progress towards them on a regular cadence. (See Tracking your Career Development for some ways of doing this.) Performance goals should contribute towards achieving our global KPIs.
PTO, training and other context are important in goal setting and should be taken into account. In some cases, it might be prudent to set goals of minimal to zero contributions towards team goals to help encourage engineers to focus on these individual activities. Below are some common areas for goal setting:
FRT and Ticket Assignment
Public and internal comments
To maintain good progress through to resolution on all assigned tickets and help others maintain progress on their tickets engineers must communicate with our customers and collaborate with their peers. Public and internal comments can be an indication of performance, but be careful not to confuse it with the desired result of solved tickets.
See: Ticket Baselines
Docs and Product MRs help prevent future tickets. All Engineers should be submitting Docs MRs regularly.
- Performance Indicators - Support MR Rate
- Improve documentation and publicly share knowledge
- Fix GitLab bugs and create features
Pairing sessions are good to be aware of, especially if skills-based performance is being coached.
Support Engineers should regularly be working to expand their skills base through whatever resources are appropriate, be it Support Training Modules, LinkedIn Learning courses, pairing sessions, or other activities organized by GitLab Learning and Development.
Individual performance can be challenging to measure: week over week performance may be clouded by PTO, or time spent focusing on areas that have a high number of hours invested for a low overall output. For example, a Support Engineer working with a customer in an escalated state may spend many hours working on a challenging problem, take no new tickets during that time, and produce a small number of comments that solve the case. But when considered over time, such indicators can be helpful at evaluating results.
For a more complete look, see warning signs / patterns of underperformance.
Underperformance in Support
Underperformance for Support Engineers is defined as an Engineer not meeting their agreed upon goals for 4 consecutive weeks.
Working through Underperformance
Managers should act early by having a conversation with their direct report when a team member is underperforming. A good guideline to what is “early” is when a support engineer hasn’t been meeting their goals for four consecutive weeks. At this point you should discuss the situation and plan for moving forward with your manager.
Once you and your manager agree, the next steps are to:
- loop in the Team Member Relations Partner
- Have a conversation with your direct report:
- review GitLab’s guidelines on providing feedback, and any additional training you have received
- communicate that you have identified specific behaviors that indicate the team member is not currently performing to standards (include specific examples)
- be clear that this discussion is not a formal verbal warning or written warning
- ensure psychological safety and provide space for the team member to respond and raise concerns
- identify and form an action plan