Support Onboarding Buddy

You’ve become an onboarding buddy to a new Support Engineer. Congratulations! You’ve been granted a pivotal role in helping someone new learn about how to best contribute to our customers, our team, and our product.

Responsibilities

These responsibilities of the Support onboarding buddy are an extension of the GitLab Onboarding Buddy responsibilities, so please review that page first.

1. Help the new Support Engineer through any sticking points they have in their onboarding modules.
2. Communicate often with the new hire, and either help (or direct them to get help) when stuck.
3. Help the new Support Engineer adapt to and learn the role, by having frequent calls and pairing sessions to learn about our day-to-day duties.
4. Encourage the new Support Engineer to work tickets that push them out of their initial comfort zone.
5. If you will be out of office in the first 2 weeks, or have numerous commitments, consider discussing with your manager about either having someone else take on the role or to help clear some of your commitments, so that you can make sure you are present and can commit to the role.

Structure

During your time as onboarding buddy, you’ll be working alongside the new Support Engineer while they complete their onboarding. Consider the timeframes below to be estimations: the pace will really be determined by the new Support Engineer.

Ideas & Suggestions

Note that everyone’s needs are different, so consider the following as a list of ideas to customize to their individual needs. Not everyone needs everything from the below lists, but everyone would find at least a few of the following helpful.

First 1-2 weeks

• Meet and get to know each other
• Answer general questions
• Talk about your “schedule” and how you work every day - walk them through a few example days
• Talk about how to use tools like Slack, Navan, etc.
• Show them some helpful Slack channels
• Which Slack channels to keep track of daily
• Explain the SWIR and options for staying informed, like digest issues (and label subscriptions for a “newsletter experience”), the #spt_swir Slack channel, or the audio edition
• Show them some helpful handbook pages to read during onboarding
• Show them the GitLab architecture diagrams
• Show them some product or support-team-meta issues and clarify that they can contribute to anything
• Remind them they can get reimbursed for any books or training, and show them the Spending Company Money page. If it’s expensive, talk to their manager first.
• Show them our Testing Environments, and introduce them to GitLab Sandbox Cloud for GCP (which replaced support-resources)
• Help them update the GitLab team page with their info (one of their Onboarding Issue checklist items)

Pairings

• Introduction to Zendesk and how we use it:

  • Walk them through Zendesk and how to use it
  • Answer any questions they have about the ticket workflow handbook pages
  • Walk through your own process for choosing and answering tickets
  • Talk about setting salutations in signature
  • Show them how to create a ticket pairing issue
  • While trying to help them feel comfortable, we also want new SEs to develop the low level of shame value by going out of their comfort zone. Stress that there are no stupid questions (maybe share the most recent “silly question” that you asked) and encourage them to ask questions in different public Slack channels
  • Have them setup pairings with different subject matter experts when they feel stuck on a topic

• Pair on tickets:

  • Share your screen and answer a few easy tickets with them
  • If they brought any tickets to the call, answer those first
  • Alternate who shares their screen and answers the tickets
  • Reproduce problems whenever you can. Show them how to quickly spin up an instance using your preferred method (Docker, GitLab Sandbox Cloud for GCP, etc.)

• Customer calls:

  • Ping them when you have a customer call so they can shadow it
  • Show them how to find customer calls to shadow
  • Be available for their first customer call, if possible. If not, do what you can to ensure they have a shadow to help them out

What to do afterwards

• Over the first few months, if you have anything interesting you’re working on that you think they can learn from, ping them and see if they’d like to either pair or shadow you on it.

View page source - Edit this page - please contribute.