Preventing burnout on support teams
Or at least mitigating it. I’m not a miracle worker!
It takes quite a while to hire and train a support engineer. Now imagine that after going through that process, your engineer quits after six months. Why? Because they were spending all day responding to support issues that could have been avoided through better documentation. Because they had seen customer-reported bugs and feature requests fall into a black hole over and over again and finally gave up trying to make a difference. Because, in short, they were burned out.
That’s one reason burnout is so dangerous on support teams. But it’s not the only one. Even if they don’t leave, folks suffering from burnout are going to lead to more problems for your team down the road.
They won’t be as motivated to find underlying causes of problems, or dig deeper when customers report issues
They may not bring up to customer success—or maybe not even notice—signs of unhappy or frustrated customers
Burned out employees are not happy employees and that poor attitude may be contagious, particularly if it’s coming from a more senior team member
Even if they do their best to conceal it, customers are good at sniffing out whether the engineers they’re dealing with are enthusiastic or just faking it
So given all of that, how can you minimize the occurrence and severity of burnout? Let’s start out by looking at the wide variety of things that support teams are commonly responsible for.
Support is more than just ticket handling
Particularly in startups, everyone wears a lot of hats. The more versatile the employee, the more variety of tasks heaped on their plates, and support engineers are often the most versatile employees a startup will have. They have to have good interpersonal skills, strong technical chops, and a genuine desire to solve problems. Those skills can be put to good use in a lot of other domains, such as:
Documentation
Bug reporting and reproduction
New feature requests
Creating (and sometimes presenting) training materials
Customer success activities
Sales engineering
Deployment services and professional services in general
All of these tasks can be critical to the success of a startup, and support teams are often capable of handling all of them and more. Many of them are arguably already in the realm of support, since (for example) better documentation directly leads to better support outcomes down the road.
Better still, employing your customer engineers in other things beyond constant support issue handling helps prevent burnout! Regularly bringing new tasks into your team’s day-to-day helps keep things fresh, lets them develop new perspectives through varied work, and generally improves their overall work experience. Of course there is a balance to be struck between novelty and familiarity, but most teams would benefit from a broader definition of “support work.”
Setting aside time for other projects
Now, saying that is one thing, but actually making room in the day for these other tasks and projects is another entirely. If you are not careful to actively clear space in the day for non-ticket-handling activities, they will fall by the wayside every time under the never-ending stream of customer issues.
It’s important to point out here one of the easiest ways to screw this up and stress out your team even more in the process: expecting them to do all of this other work in the downtime between handling incoming issues. It doesn’t matter if they’re on ticket duty for eight hours a day, goes this school of thought, since there’s plenty of downtime when nothing is coming in where they can work on docs, or reproduce bugs, or whatever. This may sounds fine on paper but ignores an important fact about the human brain—we’re actually really bad at multitasking. Every time we have to switch context we have to basically reset our brains to prepare to take on the new task, and that takes time.
Much better is to set aside specific times for this non-ticket work. If your team is big enough to manage it, the easiest way to arrange this is through on-duty shifts. For specific hours, each engineer is responsible for new tickets coming in, and outside those hours they are free to work on other tasks and larger projects that require deeper concentration. Of course, if not much is happening while they are on duty they are free to pick up those other tasks too, but they aren’t forced to get all of their non-ticket work done in the interstices.
How we did it in my last role
Our eventual charter as a multifunctional, multi-expertise team was arrived at almost accidentally. As the founding support engineer, I quickly realized two things:
There weren’t enough incoming support issues to keep me busy, at least initially
There were, however, lots of other things to do that happened to play well into my existing skillsets
And so, without explicitly deciding to, I found myself building a cross-functional support organization by default. By the time I was ready to hire my first additional team member, it went almost without saying that they’d have to be able to:
Help improve our documentation
Work closely with Engineering to reproduce bugs and validate fixes
Generate sample scripts for customers to demonstrate API functionality
Help onboard new customers through architectural discussions and hands-on deployment assistance
… in addition to our bread and butter of efficiently handling support issues. And we hired accordingly. We looked for flexibility in our candidates almost as much as experience doing technical support and general technical skills. As our team grew, we tried to diversify the overall skills of our team to make sure that we had someone for almost any eventuality. Some were stronger in writing, others excelled in live troubleshooting, yet others thrived writing tools for the team to facilitate our internal and customer processes.
And according to their own skills and interests, our team members always had something to work on in their off-duty hours. This was the second main prong of our team structure: folks were on duty for part of the day (from four to six hours), and in the remainder of their time they were free to focus on other tasks and projects, providing variety and, ideally, limiting the risk of monotony and burnout.
How I might do it differently next time
Nothing is perfect, of course, and the setup I just described was no exception. There are a few places we could have done better.
Diversity of skill sets is never as easy as you may think. No matter how hard you try, it’s hard to get the exact mix of skills you may need at a given moment. We always struggled finding Windows expertise, for instance—our talent pool was always more Linux-heavy.
Some skills are important for everyone to have. In the interest of seeking out folks with broad ranges of skills, we didn’t always focus as heavily as we should have on some of the foundational skills like written communication. This led to a longer onboarding and training period than we’d have liked.
Know what really matters. Until we really dialed in what was needed to be successful on our team, we had a few false starts like the above.
If you build it, they may not come. Just because you have a broad range of skills on your team doesn’t mean they’ll all be put to use immediately, or ever. If you hire someone with very specialized skills, you may have a hard time finding things for them to do outside standard support work. Make sure they have other, more prosaic, skills too.
Don’t be too rigid about off-duty activities. Sometimes there honestly is little to do other than following up on old tickets or working on a gnarly bug reproduction. Don’t fault your engineers for doing the work there is rather than casting about for something more exotic just because that’s what they “should” be doing.
Pay attention to individual stress and motivation levels. Don’t just assume folks are doing well because you’re giving them a good variety of things to do, or assume they’re getting burned out because they’ve been handling a lot of tickets lately. Talk to them to find out their perspective on things.
Technical support can be difficult and monotonous, but it doesn’t have to always be like that. With some attention to workload and diversity of work, you can help your team stay interested and engaged.
Thanks for reading Andy's Support Notes 💻💥📝!