Everyone Can Contribute: Making Support Effective Through Contributions

Presented at Support Driven Expo 2022 on October 20, 2022.

Everyone dreams of talking to someone who can solve their problem. Opening up ways for Support team members to contribute to documentation and code will improve the customer experience and the company’s efficiency and we can prove it!

Full write-up: https://wp.me/pHQ83-279

Transcript

1. Cynthia "Arty" Ng, Staff Support Engineer
   Everyone Can Contribute:
   Making Support Effective
   Through Contributions
   

   View Slide

2. About me
   ● Many Customer Service-related roles
   ● Teacher > Librarian > Support Engineer
   ● Management experience
   ● At GitLab 4+ years
   ● Staff ~= Manager
   ● Documentarian
   

   View Slide

3. Credit: Mathias Appel, CC0, via Wikimedia Commons: https://commons.wikimedia.org/wiki/File:Red_Panda_Waiting_For_Lunch_(31133617581).jpg
   

   View Slide

4. GitLab as of 2022-10-01
   ● 2000+ team members
   ● Fully remote in 60+ countries/regions
   ● 130+ Support Engineering (including managers)
   

   View Slide

5. Making Support (more)
   effective
   

   View Slide

6. Answer the following questions
   ● Do you work in Engineering?
   ● Do you have a Support team?
   ● Do you have a backlog?
   ● Do you want to increase your velocity?
   

   View Slide

7. Have your Support team
   contribute docs & code!
   Yes, really.
   

   View Slide

8. Common blockers
   

   View Slide

9. Support teams don’t have
   write access to docs.
   

   View Slide

10. Support teams don’t have
    read or write access to
    code.
    

    View Slide

11. Everyone dreams of
    Support fixing their
    problems.
    So how do we get there?
    

    View Slide

12. Part 1: Give your team access
    ● Talk to Development and Product.
    ● As many projects as possible.
    ● Ability to submit contributions to docs or code.
    

    View Slide

13. Part 2: A well-defined review
    workflow
    ● Build trust with Development.
    ● Have a process designed for anyone to propose
    changes, and get it reviewed.
    ● Make it easy for Support to contribute.
    ○ Example:
    https://docs.gitlab.com/ee/development/contributing/merge_request_workflow.html
    

    View Slide

14. Part 3: Avoid the small things
    ending up in your backlog
    Skip this:
    1. Support opens issue
    2. Product & Development
    schedule it (at the expense
    of other work!)
    3. It gets fixed
    4. Support finds out later
    Get this:
    1. Support submits a fix (and
    send a link to the customer!)
    2. Development reviews
    3. Fix gets merged
    

    View Slide

15. Based on: https://gitlab.com/gitlab-org/gitlab/-/merge_requests
    Number of MRs merged by Support team member in main GitLab project
    

    View Slide

16. Support focus on bugs.
    Development focus on features.
    

    View Slide

17. Build it into Support
    ● Provide & budget time
    ● Job responsibility
    ● Performance review
    ● Onboarding
    ○ Example:
    https://gitlab.com/gitlab-com/support/support-training/-/blob/master/.gitlab/issue_templates/Documentation.md
    ● Key Performance Indicator (KPI)
    

    View Slide

18. Source: https://about.gitlab.com/handbook/support/performance-indicators/#support-mr-rate
    Average number of MR merged per Support team member
    

    View Slide

19. Source: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/82147
    

    View Slide

20. Source: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/79845
    

    View Slide

21. Source: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/81777
    

    View Slide

22. Source: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/81886
    

    View Slide

23. “I've seen minor contributions to the
    documentation directly deflect tickets, make
    answers frequently asked support questions
    publicly available/discoverable, and even
    mitigate or avoid customer emergencies. [...]
    I estimate each time the upgrade docs are
    updated by a Support team member, at least a
    dozen future support emergencies are
    mitigated.”
    - Greg Myers
    

    View Slide

24. “If a docs or code contribution I write helps a
    customer or another team member troubleshoot
    a problem in a more efficient manner on their
    own or it resolves their problem completely,
    that’s a win for me. It’s a very satisfying feeling
    knowing that something you did is improving
    the efficiency and user experience for everyone
    else.”
    - Anton Smith
    

    View Slide

25. “Having your code or docs update reviewed is
    an excellent learning experience that leads to a
    much greater, low-level understanding of the
    product and its components. If this doesn’t
    make us more effective Support Engineers, I
    don’t know what does.”
    - Łukasz Korbasiewicz
    

    View Slide

26. How do we make Support
    more effective?
    

    View Slide

27. Have your Support team
    contribute docs & code!
    

    View Slide

28. Everyone can contribute
    

    View Slide

29. Thank you
    

    View Slide

30. Twitter: @TheRealArty
    SD Slack: @arty-chan
    about.me/cynthiang
    cynthiang.ca
    Cynthia “Arty” Ng
    

    View Slide