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.
6. Review the changes made to the modules, access requests, and onboarding issue, since those get updated frequently to be able to guide them properly.
7. Align with their direct manager on the direction they want them to move, when it comes to the pace of progress, and the modules to work on.

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 and get acquainted.
• Ask them how frequent they would like you to check in, and whether they profer async or sync communications.
• 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 and 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.
• Remind them of their office equipment stipend, and show them the expensing equipment handbook page
• Explain how to use the stipend and how to submit an expense in Navan
• Show them our Testing Environments, and introduce them to GitLab Sandbox Cloud for GCP
• Encourage them to create MRs for the handbook or docs if they see something that needs to be updated.
• Help them update the GitLab team page with their info (one of their Onboarding Issue checklist items)
• Consider doing async slack check-ins to see if they have questions that they might be reluctant to ask, or something they might need your help with.
• Consider splitting the info you are sharing with them over several meetings/pairings, to avoid getting them overwhelmed.

Week 3+

• Remember to review their open modules with them to see:

  • if they need help with any tasks, and remind them to check out the tasks they finish, and close the modules
  • if they have any open modules that don’t seem to fit their path at the moment and discuss it with them

• Consider scheduling a regular chat aside from the pairing session(s), or alocate time in your regular meetings to discuss their progress, concerns, and what they need help with.

Pairings

• Introduction to Zendesk and how we use it:

  • Walk them through Zendesk and how to use it
    • Show them how to use the different macros, and advise them on the most used ones.
    • Show them how to leverage the different apps on Zendesk
  • 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

• Working on tickets:

  • Show them how to create a ticket pairing issue using pairfy
  • 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 set up pairings with different subject matter experts when they feel stuck on a topic. Specify the experts by sharing their full name or gitlab username, to avoid confusion.
  • Walk them through the GitLab calendars, and show them some group pairings in their region that can be beneficial to their development. Consider sending them a link to them

• 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.)
  • Lead by example, following our “handbook first” value when checking for workflows

• 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

• After closing the on-boarding issue, discuss with them the different focus areas, and ask them what training module they might be interested in picking next. Guide them to the subject matter experts and the spt pod slack channels (if any). Send them the full names of the experts and channels in DM or add them to a shared doc if you have one.
• Consider keeping a frequent check-in/chat/pairing with them (ex. monthly)
• 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.