Support cross-training for some
Misery loves company?
Last week I talked about why I think every new hire in your company should spend a little time with the support team as part of their company onboarding. Briefly:
Everyone should know how the support team operates
Everyone should understand why good quality support is so critical to customer retention and expansion, not to mention company and product reputation
The more people who have a basic grounding in your team’s support practices, the more backups you can call on when you are shorthanded, whether due to holidays, illness, or unusually high support volume
This week let’s explore that last bullet point some more: who outside the support team should be getting a deeper grounding in support processes, activities, and the support mindset? And why?
Customer-facing technical teams
The first group to look at is other teams that are both customer-facing and in technical roles. This is your sales engineers (SEs), technical account managers (TAMs), and the like. They’re obvious candidates for deeper support training because the folks in these roles are going to have very similar skillsets to your actual support engineers: they know how to talk to customers, and they know how to do technical work on your company’s product. And this training can go both ways—just as SEs and TAMs can be qualified to do support, customer engineers can easily learn to fill in for SEs and TAMs.
Why should they get trained?
Especially in smaller organizations, there is always going to be a skills crunch and very limited backups. If support engineers are sick or on vacation, there may not be enough other folks on the team to pick up the slack. And in times of ticket surges, product outages, and other incidents of high ticket volume, it can be a lifesaver to have a deep bench of trained support backups to call on to help manage the support load.
What training should they get?
Short answer: as much as you can give them.
Longer answer: due to the nature of their work, TAMs and SEs will probably have a lot of overlap with support training topics in their own onboarding and training processes. So it will make the most sense to focus on the stuff they’re not learning in their own jobs, which typically comes down to the specific processes and tools your team uses to provide support.
Ticketing system: In some organizations, TAMs, SEs, and other customer-facing teams spend a lot of time using your company’s established ticketing systems. If they don’t, then spend some time getting them up to speed with your ticketing system and your team’s norms around using it. Who is assigned tickets? Who gets CC’d?
Troubleshooting process: Again, depending on the organization, SEs and TAMs may be expected to do some troubleshooting for their prospects and designated customers, respectively, and their existing onboarding and training procedures will include product troubleshooting. If not, cross-training with support will help provide them a baseline of troubleshooting knowledge that they can use when filling in for support engineers, but also in their own day-to-day. What do the product logs look like? What are the most common stumbling blocks for end-users? What are the initial triage and troubleshooting steps your team employs to quickly get to root causes?
Support ticket lifecycle and escalations: Because they’re not living with regular on-duty shifts and multiple new tickets per day, folks outside the support team aren’t going to be as familiar with general support practices and runbooks. What are the expectations around ticket updates and resolutions? Where do you go when you need additional assistance around more esoteric product functions? How do you initiate a companywide product incident in case of outages or critical security issues?
Other technical teams
SEs and TAMs and other customer-facing technical roles aren’t the only ones in your company with technical skills. Most companies have at least one or two more major technical talent pools: software engineers and infrastructure engineers (aka DevOps). They aren’t customer-facing by any means, as their focus is entirely on building and maintaining the software systems that keep your product (and company) running. So why should they get support training?
Why should they get trained?
Two reasons: support backups, as described more above, and escalations. Let’s be honest here: software engineers and DevOps folks often aren’t interested in talking to customers directly, and why should they? In the normal run of things, they shouldn’t have to talk to customers. Any advice they may have can be shared with support engineers (or TAMs, or SEs, or whoever), and have them convey it to customers, and vice versa. But occasionally that’s not enough. Sometimes the most efficient way to get to the root of a particularly difficult bug, for instance, is to hop on a live call with the customer and bring along a software engineer who can drill straight to the source. When those situations arise, you’ll be a lot happier if the engineer in question has had a basic grounding in the support process and particularly the customer interaction mindset that support engineers are so good at. If a software engineer is going to spend the whole time barking at the customer, talking over them, and generally being unpleasant, your support engineers are going to be a lot less likely to want have them on a live call with the customer. Some training in support processes and customer interaction niceties will serve you well for those hopefully-rare occasions.
What training should they get?
As we previously discussed with the customer-facing technical roles, the ticketing system, troubleshooting process, and ticketing procedures and standards are going to be important to convey to these engineers in core technical roles. They’ll have a lot less regular grounding in any of these things, so you’ll need to ensure that they go through a similar onboarding process as your own new support engineers before they’re considered ready to take on backup support engineer duties.
As I alluded to just above, customer interactions and manner are going to be key to instill in internal technical team members before they’re expected to attend customer calls. Software and DevOps engineers are not guaranteed to have these skillsets, and they may never be as polished as you’d expect someone in a customer-facing role to be, but they can at least be brought up to a baseline where your support engineers won’t be reluctant to put them in front of customers in a troubleshooting or emergency situation.
Anyone else?
I’m glad you asked! Like I talked about last week, I think there’s value in everyone in the organization getting a basic understanding of the support process. While I won’t go so far as to say that everyone should get full support training and onboarding (though I think it would be great if they could), I think there are a few aspects of the job that should be known by as many people as possible across the organization. The more people on the team that have a grounding in incident response, for instance, the better off your company will be when things hit the fan and you need all hands on deck. And when the holidays come around and everyone wants to take the same two weeks off at the end of the year, your support inbox will be in much better hands if the skeleton crew remaining at work are all able to do basic ticket triage and handling in a pinch.
While there is probably not enough time during new employee onboarding to add ‘intensive support cross-training’ to the list of important training sessions, there’s no reason that you can’t conduct ‘Support for non-support engineers’ trainings periodically through the year. For other technical teams, work with your leadership counterparts on those other teams to create a more formal training curriculum to give their staff a thorough grounding in Support 101. While you’re at it, make sure your support engineers are able to fill in for TAMs and SEs too, though that’s a topic for another day (and probably for someone other than me to really explore). The broader their skill set, the more effective they’ll be in their own day-to-day work.
Thanks for reading Andy's Support Notes 💻💥📝!