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 on any of GitLab’s platforms: gitlab.com, GitLab Dedicated or GitLab Self-Managed
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 region 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 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:

• Intermediate: Focus is on managing and solving their assigned tickets
• Senior: Although managing and solving their own assigned tickets remains important, focus is on helping Intermediate Support Engineers to solve their assigned tickets both by assisting directly on tickets (pairing, internal notes, etc.) and by delivering training (mentoring, classes, videos, etc.).

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:

• Creating their work schedule with their manager
• Coordinating with others, such as their manager and their Support Pods, their day-to-day availability for ticket work
• Working with any Support Manager to take on higher-priority tasks (such as STARs or account escalations) based on customer needs

2. Work with your region 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 with their region, and with other regions as needed, to help all of Support to meet that goal. How?

1. Your region may have defined its own processes related to FRT. If so, please follow those. If not, then expect that each person in the region, including you, will be monitoring the global view throughout each day, taking tickets as they can, and calling out to the rest of the region 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.

Triaging tickets

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

1. The correct ticket form (such as SaaS, if they’re asking for GitLab.com support).
2. The correct priority
3. 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
6. If your ticket is STARred during your business hours, work with the on-call manager and the person who submitted the STAR to help address any concerns.
   1. You are not expected to respond or engage in a STAR if you are unavailable (for example, you are on PTO or its after hours). When you are back online, review the STAR thread to ensure you’re up to speed, and address any follow-up actions, if applicable.

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:

• Understand the customer’s real needs
• When you can’t do what the customer wants, find what you can do to help them
• Keep the customer informed at all times about what you’re doing and why
• With every interaction, clearly communicate the action plan including the due date and time for the next update from you
• Set, manage and reset expectations as things change

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 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 look for ways to help other Support Engineers with their tickets, such as by engaging with your Support Pods, by contributing to senior help sessions, by contributing to crush sessions, by pairing on tickets, by looking for help requests in the various Slack channels, etc.

What does success look like?

Success will look like a healthy balance between solving your assigned support tickets and helping others to be successful. 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.

Prioritizing work

Each Intermediate and Senior Support Engineer should generally be prioritizing their daily work according to the following list. Interviews, training, special assignments and other time-bound commitments are examples of good temporary exceptions to these priorities.

You should think of this list as a tool for helping you to make decisions. When there are multiple things to be done, these priorities should guide you toward deciding which of them to do first.

1. Handle:
   • emergencies if you are the Support Engineer On-Call, or if the Engineer On-Call needs help
   • incidents if you are the CMOC
   • account escalations if you are a DRI or contributing member on an active escalation
2. Handle STARred tickets that are assigned to you
   • assigned tickets that are STARred will ping the assignee and on-call manager
   • if your ticket is STARred during your business hours, plan to engage in the STAR thread created in the #support_ticket-attention-requests Slack channel to help address any questions or concerns
   • if your ticket is STARred outside of your business hours, you are not expected to engage, but do plan to follow up when you’re back online. The on-call manager will address any immediate needs.
3. Take tickets from the Global View, working from the top down
   • for a new ticket, provide a meaningful first response within SLA
   • for a rehomed ticket, let the customer know you’ve received their ticket, and set expectations for what will happen next
4. Participate in your Support Pods’ work
5. Make sure your assigned tickets are all up to date and progressing appropriately
6. Help on tickets assigned to others by:
   • posting an internal note with relevant helpful information, OR
   • answering questions the assignee has posted to Slack, OR
   • asking the assignee if they’d like to pair on the ticket, OR
   • responding directly to the customer, preferably only if a response is needed urgently AND the assignee is unavailable to work the ticket
7. Attend to indirect ticket work you have to do, such as:
   • docs updates
   • issue creation or contributions
   • training

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.

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.

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 every month, 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.

View page source - Edit this page - please contribute.