Staffing levels and support coverage, part 1
Really? Another part 1?
Smaller topics first
“Okay, so we’ve talked about the four support coverage models, and we’ve talked about calculating the ticket load for your team, so we’re ready to actually learn how many folks you need on your team.” At least, that’s what I’d say if we didn’t have a few other small things to get through first. Each of these probably deserves an article of its own, but I really want to get to at least some of the actual coverage numbers this week. So for now I’ll just briefly discuss them for context.
Burnout
Remember what I said a few weeks ago:
It’s essential to remember that your engineers—and you!—are human beings, not machines. You need time off to recharge, you get sick, you have personal lives. Any support coverage structure that doesn’t build in redundancy for absences, either with or without notice, is doomed to degrade or even collapse sooner or later.
So far we’ve been in very abstract territory: X engineers times Y tickets equals… but it’s important to recognize that we’re dealing with people, not numbers. Make someone grind out tickets 8 hours a day, and most folks will burn out fast. Their productivity will decline and they may start looking for another job. What this translates to in hard coverage numbers is simple: don’t expect anyone to work at 100% theoretical ticket handling capacity for any length of time unless you’re prepared to lose that person.
Time to replace
Closely related to the topic of burnout, it’s important to have a handle on how long it takes to hire and onboard a replacement in the case of turnover. The longer it will take to replace someone, the more important it is to have a plan to handle support coverage during that time. If it takes a year to hire and fully train a new support engineer, for instance, it may make sense to be a little bit overstaffed at all times to ensure you have sufficient capacity after someone leaves and before their replacement is ready.
Time off
Similar to time to replace, but on a more temporary basis, you need a plan for picking up the slack when someone is out of office for whatever reason. Cross-training and grabbing assistance from other teams can work, but (especially in the case of sick leave) there’s not always time to plan ahead properly for coverage needs. It’s important to have some excess capacity on the team for times when you’re understaffed. One person can do the work of two, briefly, but you’ll pretty quickly start to run into problems with quality, speed, and of course burnout.
Surge capacity
No matter how well you’ve planned out support coverage, there are ebbs and flows to incoming customer issues. Some days you may have fewer than usual cases, some days you may have more—many, many more if there is an outage, or a bad software push, or… You need to have a plan in place before one of those high-volume days happens. Will you overstaff to ensure you have the capacity for a surge in demand? Will you have agreements with other teams that you can borrow their resources on short to no notice? Whatever the plan, think it through before you need it, not after.
Ad hoc
We’re starting with the easy one: in the state of ad hoc coverage, if you’ll recall, there are no dedicated support engineers. Therefore there are no specific staffing needs for support. But when we’re in this mode, our question is still ‘do we have the right number of support people?’ It’s just that this question is implicitly asked every time we think about whether the ad hoc model is still working, or whether it’s time to hire dedicated staff.
Of the smaller topics above, the one most relevant to the ad hoc support model is burnout. How long can your founder, or engineer, or marketer do double duty as a support person too? How long before they start to show the strain in doing their main job? It saves money in the short run to handle support with whoever is available, but over time other aspects of the business will begin to suffer.
Also important to consider is time off and surge capacity. Even if having your founding engineer answer support tickets is fine now, what about when they’re sick? When they’re too busy doing their regular job? Or if there’s a flood of tickets one day, maybe because of a bad code push they were too overworked to notice? If you don’t have a plan for that now, you’re going to find yourself in a bad support situation sooner or later.
Business hours only
If your business is highly regional—only customers in your own immediate area, or time zone—you can get away in principle with a single support person, at least until there are more issues than they can handle by themself. Issues are responded to during business hours in your time zone, and anything coming in outside that time waits until your engineer is back on duty. Burnout is a serious concern in this situation, however, particularly as the support load increases.
When your business-hours coverage starts to cover more than one time zone, it is imperative that you have more than one person handling support issues. Imagine if you decide to cover 9AM ET to 5PM PT: that’s eleven hours a day, which is significantly more than one person can work for any length of time. At a minimum you’d need one person starting at 9 ET and ending at 5 ET, and another starting at 9PT and ending at 5 PT. This also gives double coverage for a five-hour stretch in the middle of the day, which in many cases when the support load is heaviest. But, like the single time zone option above, two people is the bare minimum. As soon as one person is on vacation, or quits, you’re in trouble.
In both scenarios, a good rule of thumb is to have at least one more person than you need. In smaller teams, of course, this is more of a budgetary impact than in larger teams. Going from 1 to 2 is a lot more expensive, relatively speaking, than from five to six. This additional person gives you a good amount of wiggle room for covering time off, surge events, and team attrition.
At a large enough team size, probably around ten or so, adding one additional person is not sufficient and you’ll need to increase your spare capacity by at least two. But if you’re at that team size, your support model is probably already shifting into one of the more comprehensive coverage models anyway, so read on… NEXT WEEK!
Next time: off-hours coverage and full 24/7 in-house support.
Thanks for reading Andy's Support Notes 💻💥📝!