Support Driven Expo workshop: Support Engineering 101 (Notes)

Introduction

So why am I here? Why are you here? I hope it's to do better work as customer service professionals, a skill that humans in general, but especially full-time software and systems engineers sometimes lack.

Overview

Customer service is a valuable skill that we've all got ideas about; that's why we're here, right? Assuming that skill as a base, how can one transition into a role as a Support Engineer? That's what this workshop will explore. If you're already a support engineer or have a similar mindset about your work and/or the rest of the world, you may not get much out of this workshop as we're starting with the philosophical building blocks and applying them. In case that happens, I promise I won't be offended if you decide at some point it's too basic or you don't like the sound of my voice and stand up and walk out. I also appreciate being asked questions so don't hesitate in case you're curious about something I moved past too quickly.

Most or all of you are employed in some sort of customer service role, right? If you're not, you are clearly at least interested! What would you say your primary focus in that work is?

(hoped for answers to elicit from crowd: problem solving, customer service, educating, connecting people and ideas, writing, observing trends)

I'd say those are all part of support engineering - and more!

What kind of skills should you start with, and what does a solid foundation of on-the-job training look like?

I'm a hiring manager and have interviewed over a hundred folks for support engineering roles over the course of my career. While the job always has a technical component (aka buzzword list), the actual required skills are three, and every customer service professional has the first two:

• ability to communicate well
• customer empathy or ability to fake it consistently and believably
• the third is something anyone can choose to have, but you also have to DEMONSTRATE it: technical curiosity

  I don't hire anyone who doesn't want to learn some nerdy things. How much you know in advance is maybe key to you choosing to apply to my job, but is not key to how well you can do in the interview. My interview process is carefully structured to allow someone to succeed with:

  1. no formal/professional tech skills or training beyond helping less tech people with their everyday computer problems,
  2. and ability to google effectively, sifting through lots of data to find relevant details.

  Definitions

  In my world, a support engineer is one who has the capability of efficiently solving a range of technical problems for customers in a way that both advances the understanding, success, and behavior of the organization AND leaves the customer happier than they were. There are many other definitions like it, but this one is mine. To say that in a different way, a support engineer exercises customer support skills like empathy and interpretation, and combines them with engineering skills such as deep investigation and debugging, with the benefits of product expertise. All of this is done in a future-looking way: "I don't want to spend a long time answering this FAQ again. How can I efficiently change that for next time?". Further, when your audience is likely to be somewhat to very technical, so including some "why" can buy you a lot of customer empathy even for bugs/malfunctions!

  some relevant engineering principles

  • engaging your mind
  • efficiency - yours and customer's
  • thinking systemically (and systematically!)
  • transparency
  • providing context & workarounds
  • efficiency - yours and customer's (a second time!)

  Troubleshooting best practices

  • Troubleshooting is your primary, front-line, problem-solving skill. It pays to get GREAT at it! But it's not everything.
  • These (https://www.slideshare.net/SupportDriven/how-to-troubleshoot-anything-and-generally-be-more-awesome-at-life-matt-dale) are some best practices from Matt Dale. Support VP @ Illuminate Education (presented at an earlier SUPconf)
  • also mention:
    1. searching for root cause rather than proximate cause/symptoms
    2. estimating impact

  Next issue avoidance as applied to engineering problems

  • Concept courtesy of **The Effortless Experience**, one of the better-researched, statistics-backed books on "providing the best customer service".
  • Basic definition: Don't just answer the current question - also answer the question that will follow naturally when your answer is applied ("I've suggested clearing the browser cache...and here's how!") Leverage your product and domain expertise!
  • Understanding correlated features in the ecosystem - product, network, security, usability, interoperating across product boundaries

  Partnering up

  As engineers, we have to then go beyond finding the problem, and think about quantifying it for various teams: yours, Product, Engineering, Security & Legal

  Support team

  • leverage local expertise
  • improve internal documentation
  • is this something new that others on your team are already seeing/may have started analysis on, too?

  Product team

  "What can we realistically commit to on what timeline?"

  Engineering

  "Which team owns this? What related things might be relevant?"

  Security/Legal

  "What can/should I say? I have to provide a good "customer experience" even if the report is a non-customer asking for something from another team - offer to help make sure the loop gets closed "I've forwarded this request to Legal but let ME know via this thread if they don't get back to you in a reasonable timeframe"

  Example scenarios and bringing the science

  An example scenario, going from customer service to engineering-level responses

  Customer: "My website's SEO is terrible"

  What shall we try? Follow the steps from the troubleshooting best practices list!

  • plan: how urgent is the problem? how important is the customer? how much time do I actually have to spend?
  • understand: "what do you mean more precisely; what are the symptoms; when did this start happening?"
  • verify: "can I see it too?" "here's a link" "okay, I see the same thing and that does look bad but fixable!"
  • reproduce using domain expertise - test our service, search for appropriate meta info in the html
  • scope: "when did it change? did it ever work? is it on every site of yours?"
  • next issue avoidance "here's how to fix and why that fix works, AND how to effectively test the results yourself"
  • close the loop: Does the rest of the company need to know anything about it?

  also mention:

  • quantifying impact (expensive customer bugs get higher priority; affecting all customers = drop everything)
  • tracking trends, collating, and reporting (source some of http://supportfolio.com/bug_escalation.html)

  instructions for exercises

  1. pair up and grab a copy of the two scenarios
  2. each person reads to themselves their own scenario and first one, and then the other person, roleplays as the customer and attempts to diagnose and also advise to avoid obvious next-pitfalls.

  Exercise 0 (demo in front of the class - 5 min)

  goal

  demonstrate how the exercise will work

  exercise

  scenario

  • expressed: "my house is full of smoke, help!"
  • actual: just burned dinner

  greatest solution includes

  • immediate safety
  • empathy
  • discovering root cause
  • not insulting the customer
  • education

  and also considers some "meta"

  • is this a frequent problem that needs to be addressed systemically?
  • can we help others solve it if so? (education campaign, don't put metal in the microwave? or maybe work with manufacturers to improve practices?)
  • does anyone else in our organization need to know anything about this? (call in the fire truck if the fire were bigger/threatening other buildings)

  Exercise 1 (Next issue avoidance - 10 min

  goal

  practice troubleshooting and learn to look beyond the answer to what will be done with the answer and potential future problems

  Exercise 2 (Quantifying - 10 min)

  goal

  practice troubleshooting and think about what other related circumstances may be correlative/causative with an eye towards filing an actionable bug report

  Wrap up

  Engineering is largely a mindset. The specific skills you get aren't super important except in learning what you like to/want to work on - find something that doesn't frustrate you but instead excites you. How can you "taste test?" A few ways!

  CTA: Get into this and or improve your game!

  1. apply these kinds of principles at your current job - start examining and communicating trends, applying next issue avoidance, solving systemic problems.
  2. some good paths to self-training
     • Meetups! These are almost always pretty narrow in focus-so there are probably dozens near you-but the Node.js programmers guild is way different than the Designers powwow is completely unrelated to the Database Administrators Neckbeard Grumpfest. They should be free, though-so not a bad path to do some of that experimenting-very low cost of "tasting."
     • Doing The Thing. If you're a structured learner, online classes may be worth the $$ (cf Udemy for instance isn't a bank-breaker). If you're less structured, many of the tutorials out there assume 0 knowledge and build from there and those are nearly all free. Here's an example that was my first google hit for "getting started with Node.js", and it is way better than any list I would come up with even after researching for hours and having moderate expertise in that area.
     Forums are still good/great-you just have to find ones that are either broad enough to give you general skills or specifically about something you're already fascinated about. I personally believe in the power of being a generalist-but I also think that is a dying breed, and can be quite hard to sell yourself as without a lot of experience and some clues about how to spin it as relevant for people who aren't believers themselves. However-if I were trying to train a new generalist in tech-I'd say "hang out on stackoverflow.com serverfault.com". You'll probably end up "doing" some things to answer questions-but you can see a LOT and learn a LOT by just reading answers and the beauty of those sites is-you are ENCOURAGED to improve questions and answers by editing. No particular skill needed except communcation skills-but you'll absolutely pick some stuff up in the process. And then-hey-you also have a resume builder! "Look at my profile on Stackoverflow to see some examples of my work." Since the StackExchange network's gamification is guided and super useful and obvious, you'll get good guidance when starting from 0 at "things to try" and figure out where the sweet spot is for your skills now-and discover new spots to pitch in as those skills evolve.
  Go back to the rest of my Supportfolio