Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Support Engineer Responsibilities

  1. You are here:
  2. Handbook
  3. Support Team Handbook
  4. Support Engineer Responsibilities

Introduction

  1. This page is an extension of the Support Engineer job family page.
  2. This page should reflect the Support Career Framework.
  3. The aim of this page is to help you to know what your responsibilities as a Support Engineer are.
  4. You're not expected to work on all areas every week. Some of the areas have a frequency suggestion in parentheses after the heading title. This is to give you an idea of how often you might work in that area. Your manager will help you to know where to focus your efforts on a regular basis.
  5. The 'What does success look like?' subsections help encourage consistent contributions across our global team. They're not hard targets that must be met. They're to help you know how and where to contribute to succeed in your role.
  6. Performance measurement for annual reviews and promotions are separate activities to the core responsibilities described here.
    1. The People Group is responsible for the GitLab annual review process.
    2. Read about Support Engineer Career Path for further resources on promotions, and understanding the role at different levels.
  7. Support Engineering has team level performance indicators. Successfully carrying out the responsibilities on this page will, directly or indirectly, help improve our KPIs. All team-level KPIs are, in turn, related to GitLab's company-level Objectives and Key Results.

Support Engineer Areas of Focus

We currently have two main areas of focus for Support Engineers:

  1. GitLab - helping customers who encounter product-related problems in SaaS (gitlab.com) or self-managed installations
  2. License and Renewals - helping customers with License and Renewals problems

To view the team's current distribution among Areas of Focus, see our internal Support Team info site.

During onboarding, your initial area of focus will be made clear.

When reading this page, keep in mind your current area of focus. This will help you locate the correct workflows and roles.

Core responsibility of a Support Engineer

The core responsibility of a GitLab Support Engineer is to deliver an excellent support experience to our customers on a daily basis by working with them to solve the problems and answer the questions that they present to us in support tickets.

This responsibility can be broken down into five key components:

  1. Be appropriately available
  2. Work with your group to meet our FRT SLA target
  3. Maintain good progress through to resolution on all of your assigned tickets
  4. Manage customer expectations and communicate thoroughly through tickets and calls
  5. Help others in your group to maintain progress on their tickets

As you read through the components, keep in mind that the focus of an Intermediate Support Engineer differs from that of a Senior Support Engineer:

1. Be appropriately available

As a customer support team, we are responsible for being available to support our customers according to the terms of their contract with us. Although asynchronous work and communication are preferred within GitLab overall, in Support Engineering there is always a business need to have enough people available at any given moment to deliver support.

Support Engineers are responsible for:

2. Work with your group to meet our FRT SLA target

Our goal, as stated on the Support Performance Indicators page, is to provide a substantive (meaningful, helpful) first response within the time period specified by the Service Level Agreement we have with our customers on at least 95% of Priority Support tickets.

During each working day, each Support Engineer should work to help their group, and so all of Support, to meet that goal. How?

  1. Your group may have defined its own processes related to FRT. If so, please follow those. If not, then expect that each person in the group, including you, will be monitoring the group's view throughout each day, taking tickets as they can, and calling out to the rest of the group when there are new tickets that others could take.
  2. See our Working on Tickets page for guidance on finding and selecting tickets on which to work, assigning tickets, and providing a first response.
  3. Watch your group's view for tickets showing up in the Needs org section and process them right away if you can. Until those get processed, we can't begin to help the customers who submitted them. If you are a Senior Support Engineer, put a higher priority on helping others in your group to make a first response, than on taking tickets of your own. Please note that this section is about helping your own group. As can be seen in Prioritizing work, all SEs are encourage to help people in any group.

Processing 'Needs org' tickets (triaging)

Everyone is responsible for Triaging tickets to make sure they have:

  1. An associated organization

  2. The correct ticket form (such as SaaS, if they're asking for GitLab.com support).

    NOTE: A form change results in an auto-reply for tickets that don't have an organization associated yet. Hence, it is recommended to associate the user with the correct organization first. Then change the form to the most relevant form type and fill in additional metadata where possible.

  3. The correct priority
  4. The correct 'Problem Type'

3. Maintain good progress through to resolution on all of your assigned tickets

This is really the heart of what Support Engineers do, and succeeding here requires a balanced application of technical and nontechnical skills. Support Engineers should always be working to enhance their skills in both areas, not only through formalized training (see the Support Training project), but also through pairing with others, taking challenging tickets, etc.

Here are a few tips for maintaining good progress:

  1. Start your work on each ticket with a clear restatement of the problem as you understand it
  2. If the customer brings up new problems and questions, let them know those will need to be addressed in additional tickets and that your focus will remain on the original problem or question
  3. As soon as you're unclear on what your next steps should be, seek help. See our How to get help page for details
  4. If you are unsure of what message to deliver to the customer, or how to word the message to achieve a positive impact, seek help in the #spt_how-do-i-say Slack channel
  5. Ensure that you update each ticket, and therefore each customer, no later than the due date you've set with them. To succeed in this:
    1. Keep your entire workload in mind as you set your action plan with the customer so that you can set a reasonable due date (and time) for your next update
    2. If you haven't completed the intended work by update time, let the customer know what progress you've made and then set a new update time

4. Manage customer expectations and communicate thoroughly through tickets and calls

The Customer Service Skills module, which is included in the onboarding for all Support Engineers, is our best source of training and information for this topic. If you onboarded before this module existed, please familiarize yourself with its contents, either by going through the entire module or by selecting and viewing videos that address topics of interest to you. You might also want to grab the Ticket Management Quick Reference Guide from that module. Here's a quick reference to the quick reference guide:

Although most of the time Support Engineers communicate with customers asynchronously (through support tickets), it's important to make use of synchronous communications, Zoom calls, whenever the situation calls for it, such as:

  1. You're having trouble getting a clear understanding of the problem or request from the communications in the ticket
  2. You believe the customer is not understanding your requests of them
  3. The customer seems very anxious, frustrated, upset, or confused
  4. The customer repeatedly asks for a call
  5. Live troubleshooting and discussion are the best way to make progress toward resolution

See the Customer Calls page for our recommended practices and workflows for arranging, conducting and managing calls.

5. Help others in your group to maintain progress on their tickets

Collaboration is one of GitLab's values, and helping others with their tickets offers you a daily opportunity to live that value. When all higher priority items are under control (see Prioritizing work), please find tickets in your group's view. See the Support Global Groups FAQ page for topics about how to help other SEs.

What does success look like?

Success will look like a healthy balance between solving your assigned support tickets and helping your group to be successful. For the group success, see the criteria on the main SGG page. For your individual ticket work, you and your manager should begin with the following two criteria, the first quantitative and the second qualitative:

  1. Review a sampling of your tickets with your manager in your regular 1:1 meetings. Look not only for evidence of your technical skills in solving the problem, but also at how you managed the ticket and worked with the customer. In addition to producing evidence of your level of success, these reviews should result in improvements to the quality of your ticket work, both technical and nontechnical.

  2. Compare your weekly results against the three parts of the ticket baseline:

    Ticket baseline

    The ticket baseline is useful in gauging a Support Engineer's volume of ticket work compared to that of the rest of the global Support Team. We use a dynamic baseline that is equal to 85% of the mean for each metric. This dashboard shows the current values.

    • Consider the baseline metrics as minima to be achieved each week
    • When you don't meet a baseline, you and your manager should discuss in your next 1:1 meeting to determine what changes you should make, if any
    • We believe in quality, not quantity. More is not necessarily better. GitLab gives you freedom to choose and trusts you to use good judgment in exercising that freedom as you make daily decisions about Prioritizing work.

Participate in on-call rotations to coordinate and resolve emergencies (Occasionally)

The following on-call rotations are staffed by Support Engineers:

  1. Self-managed customer emergency on-call
  2. GitLab.com Communications Manager on Call (CMOC)

All Support Engineers participate in one of these rotations - not both, unless you absolutely love being on-call!

New Team Members: your Support Engineer Onboarding Issue shows the readiness criteria for joining rotations.

What does success look like?

  1. Being available when you're scheduled to be on-call (learn how to swap shifts)
  2. Responding to alerts within the required time before the alert is escalated
  3. Successfully carrying out the on-call communication processes for .com incidents or self-managed emergencies

See the handbook for more details on Expectations for on-call.

Be sure to highlight notable incidents in your 1:1 notes doc.

Collaborate with team members and customers (Daily)

Collaboration is a core value at GitLab. You are encouraged to collaborate with Support team members, other GitLab team members, and customers to help directly and indirectly solve customer problems.

What does success look like?

  1. Pairing sessions. You can see how you're doing on this pairing summary page
  2. Ask and answer questions in Slack. (We don't have a way to easily make this visible, but feel free to share things you're proud of with your manager in your 1:1 notes doc.)
  3. If you have volunteered to be a Support Stable Counterpart, collaborate with the group(s) you are assigned to and share knowledge with the Support Team.
  4. There are many other ways you can collaborate. Make a note of your collaborations in your 1:1 notes doc.
Level How it might look
Intermediate Aim for two pairing sessions per week
Senior Aim for one pairing or help session per day

Create and update issues for bugs and feature requests (Weekly)

Reducing future customer problems is an important part of being a Support Engineer. Creating, updating and escalating issues for bugs and feature requests helps achieve this.

What does success look like?

  1. Create bug issues and feature requests whenever needed. You can see how you're doing using the 'GitLab issues' activity link in your 1:1 notes. Here's an example link. The format is https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&author_username=YOUR_USERNAME (replace YOUR_USERNAME)

  2. GitLab doesn't currently have a way to find all the comments you've made on Issues. Until this feature is available, it's hard to make your contributions to product Issues visible. Instead, be sure that your Zendesk tickets have links to the Issues that you create or update. You can also highlight contributions in your 1:1 notes doc.

Level How it might look
Intermediate Create issues with description completed and appropriate labels
Senior Additionally drive fix/enhancement when appropriate based on expertise and customer interactions

Improve documentation and publicly share knowledge (Weekly)

You are encouraged to update documentation regularly. This helps prevent ticket creation by improving the information available for customers to use in solving problems without contacting us.

Creating blog posts and other publicly available knowledge that is accessible by search engines is valuable to help prevent ticket creation.

We summarize Support team contributions every week using a bot.

What does success look like?

  1. Aim for at least two documentation updates every month. You can see how you're doing using the 'Docs updates' activity link in your 1:1 notes. Here's an example link. The format is https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&author_username=YOUR_USERNAME&label_name[]=documentation (replace YOUR_USERNAME)
  2. If you publish information in other public places (e.g. a blog post), make a note in your 1:1 notes doc.

Fix GitLab bugs and create features (Occasionally)

Experienced Support Engineers and those familiar with programming are encouraged to fix GitLab bugs and create features.

We summarize Support team bug fixes and feature requests every week using a bot.

What does success look like?

There's no goal for this area. You can see how you're doing using the 'Support Fix' activity link in your 1:1 notes. Here's an example link. The format is: https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&author_username=YOUR_USERNAME&label_name[]=Support%20Team%20Contributions&not[label_name][]=documentation (replace YOUR_USERNAME)

Improve GitLab and Support processes (Occasionally)

We continuously evolve and improve our processes. You are encouraged to update the handbook and improve Support processes by contributing to issues in the Support Meta project.

There's a lot going on. It can be overwhelming if you try to contribute to everything. To help focus and find an area you're interested in look at the Support Team Epics where issues are grouped into larger initiatives. Epics have a directly responsible individual's (DRI) name in parentheses after the title. Contact them and speak with your manager if you'd like to help out.

What does success look like?

There's no goal for this area. You can see how you're doing by using the 'Handbook updates' activity link in your 1:1 notes. Here's an example link. The format is https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&author_username=YOUR_USERNAME (replace YOUR_USERNAME)

Keep up-to-date on GitLab and Support

  1. Since we ship a new release each month on the 22nd, and as we manage to fit a lot of great new features and fixes into each release, it is sometimes difficult for the Support Team to keep up to date with key changes. In general, it is the responsibility of each Support Team member to read the release blog post, dig deeper where you need to or want to, and keep yourself up to date with new GitLab versions. To facilitate this further, there is a Retrospective every month (it is listed on the GitLab Team Meetings calendar) that you can join.
  2. We have several Support Weekly Meetings that you are encouraged to attend or watch the recording of.
  3. The Support Week in Review (SWIR) document is intended to contain all the recent announcements and updates each week with which everyone in Support should be familiar. You are expected to read or listen to the recording of the document every week. And you're encouraged to contribute to the document as well. You should consider putting a weekly reminder on your Monday mornings for reading (or listening to) the SWIR.

What does success look like?

There's no goal for this area. The aim is to make sure you are aware of and utilizing the information and resources that will help you stay on top of major recent changes in GitLab and the team.

Help prepare for product changes (optional)

As an extension of keeping up to date on GitLab, you're always invited to help prepare the team for changes. Occasionally, and always with every major release, there may be deprecations or breaking changes which the Support team needs to prepare for.

For major releases, typically a manager will organize the Support Stable Counterparts to review the planned changes.

Between major releases, product or development may request our assistance to contact specific users, which are handled by a group of volunteers within Support.

Each month, Support also organizes a Release Review Party (GitLab Internal only) to go over, demonstrate, and talk about new features or changes.

If you wish to participate in any of these activities, please discuss it with your manager, or the Director of Support, Global Readiness.

Develop your skills through learning and training (Weekly)

We are committed to helping you develop your skills through continuous learning. You can complete modules in the Support Training project.

The GitLab Learning and Development team provides opportunities for exploration and training.

Support Engineers are also encouraged to complete courses and certification from external providers. Speak with your manager to plan your learning goals.

What does success look like?

  1. Aim to complete a module every quarter (3 months). You can see how you're doing using the 'Support Training' activity link in your 1:1 notes. Here's an example link. The format is https://gitlab.com/gitlab-com/support/support-training/-/issues?scope=all&utf8=%E2%9C%93&state=closed&assignee_username[]=YOUR_USERNAME (replace YOUR_USERNAME)

An important focus for the Support Team in 2020 is to improve our Learning and Training resources to help you have a clear route to improving your skills and a better way to make your expertise visible to the team.

Improve our learning and training resources (Occasionally)

We encourage Support Team members to update or create Support Training resources.

What does success look like?

There's no goal for this area. If you have ideas of materials you'd like to create or update, speak with your manager. You can keep track of updates you've made using the 'Support Training Updates' activity link your 1:1 notes. Here's an example link. The format is https://gitlab.com/gitlab-com/support/support-training/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&author_username=YOUR_USERNAME (replace YOUR_USERNAME)

Help with hiring (Occasionally)

We encourage the whole team to help with the Hiring Process. If you would like to help in this area, discuss with your manager and start an Interview Training modules

What does success look like?

There's no goal for this area. When you've completed the training module:

  1. Promptly respond to requests from talent acquisition to grade assessments (everyone)
  2. Complete technical interviews when scheduled with you (after discussion with manager)

We'd like to make your contributions in this area more visible. Suggestions on how to do this are welcomed.

Edit this page View source