Support engineering doesn’t often get as much attention as impressive functionality. After all, who wants to be fixing an assortment of minor issues when you could be building cool tools?

With that said, effective support is a crucial element of the software lifecycle, whether we like it or not. Our interfaces need developer feedback in order to be improved upon, and — even more importantly — they require quality maintenance to retain satisfied developers.

Thankfully, we hosted support expert Cecy Correa at our 2018 Austin API Summit, where she explained how to take the pain out of support engineering with a few easy rules.

The Two Paradigms of Developer Support

In the status quo for support engineering, there are two main options for providing support: the dedicated approach and the rotating approach.

As the names suggest, dedicated support features a team of dedicated support engineers who tend to all support tickets at all times, whereas rotating support features a rotating team of one or more de facto support engineers, who are selected from the development team for a given week or sprint and tend to support tickets within that time period.

Make Rotating Support Work for You

Cecy says that, by default, rotating support doesn’t really work. Sprints typically end before problems are solved, meaning that engineers provide little-to-no follow through on most tickets; the responsibilities are unclear for everyone involved, meaning that some responses never get sent even if the problem is fixed; and there’s a lot of inefficiency in the ramp-up period for support engineers, meaning that plenty of precious time gets wasted.

In order to make rotating support work for you, which is especially worthwhile if you’re a smaller team that’s pressed for resources, there are a couple of cardinal rules that make a huge difference:

Prioritize new issues

The first thing you can do to help a rotating support approach succeed is to prioritize new issues as they come up. Instead of pushing issues from the support feed into a lengthy to-do list (which, let’s be honest, probably years into the future), encourage developers to take the bull by the horns and keep their product running the way it should, by fixing newly discovered issues as soon as possible.

Own your tickets

The second rule for success with rotating support is to have engineers fully own any tickets that come in during their support sprint until those tickets are resolved. No more forgetting about support work when your sprint ends — if you started a ticket, you should take full responsibility for fixing the problem and getting back to the developer for as long as it takes.

How to Thrive with Dedicated Support

From Cecy’s experience, the dedicated approach to support works a whole lot better. Thanks to the increased continuity in each support ticket — with a single engineer responsible for everything from opening to closing it — the workflow becomes significantly more efficient, with no wasteful ramp-up times or hand-offs. What’s more, having a dedicated support team gives developers a reliable and consistent point of contact, thus cultivating stronger relationship building and consequently increasing customer retention.

Still, there are a few key rules for making the most of dedicated support. These are:

Develop an exit strategy

A common theme in dedicated support is to staff any new engineers in the company as support members, which allows them to learn the ropes without diving into any code. However, these roles often come with the expectation of becoming a fully-fledged developer after some time — which is often forgotten.

According to Cecy, an easy way to improve dedicated support is by ensuring some kind of exit strategy exists for engineers who were promised more. They need some way to “level up”, so to speak, whether that means taking on a more senior support position or getting involved with development.

Own all tickets

As in rotating support, ticket ownership is incredibly important. In practice, there are two main ownership patterns for support tickets, which Cecy refers to as “removed” and “owned.”

With removed tickets, the actual fix necessary to address a support ticket is dissociated from the ticket itself. This is to say that whatever team fixes the issue at hand isn’t responsible for replying to the ticket that initially identified it. As you can imagine, this results is a little-to-no sense of urgency for fixing problems, a lot of “throwing [responsibilities] over the fence,” and no real way to grade team members on their efforts. The only solution is to effectively communicate the importance and impact of support tickets, and hope that other team members care.

With owned tickets, whichever team carries out the fix is responsible for replying to the support ticket. Naturally, this results in improved continuity, more options for grading team members, fewer middlemen to confuse things, a greater focus on the client, and increased accountability — whew! — so this is Cecy’s recommendation for handling tickets.

General Tips for Providing Better Developer Support

Whatever approach you choose, there are a number of universal tips for improving the support experience for both your customers and your team.

We’ll start with setting boundaries. Instead of working willy-nilly, establish a suitable set of support hours that you adhere to. Support engineers have a tendency to look at and sometimes answer new tickets as they come in, which cultivates an expectation for unreasonably fast responses in clients, but having a defined work period circumvents this. Obviously, if you’re in a position to provide support round the clock, that’s ideal.

Next, allow — and even encourage — support engineers to have a buffer time for each ticket. Although at times it may be frustrating for the end user, an automated response reminding them to read the docs and FAQ can solve a lot of your tickets for you.

Finally, don’t allow clients to abuse your team. Working in support is working in customer service, which can be tiring on all levels. Nip rude customer behavior in the bud and you’ll preserve a lively and enthusiastic support team. After all, team sanity and happiness comes first, so a company culture that cares is crucial.