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?
(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:
no formal/professional tech skills or training beyond helping less tech people with their everyday computer problems,
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
Troubleshooting best practices
Troubleshooting is your primary, front-line, problem-solving skill. It pays to get GREAT at it! But it’s not everything.
searching for root cause rather than proximate cause/symptoms
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
Added to notion migration list
Introduction
Overview
Definitions
Troubleshooting best practices
Next issue avoidance as applied to engineering problems
Partnering up