# API Tricks & Dev Chat

Everyone on Support: Lessons Learned

How we all do support

Hi, my name is Alan, and I’m part of the support team at vzaar; but then… so is everyone. For the past 9 months, everyone at the company from developers (like me), to managers, have been taking turns doing a week on support.

We’re a company that pride ourselves on great customer support, and we are always looking for ways we can improve support throughout the team. When we read Basecamp’s experiences in the Signal v. Noise’s “Everyone on Support” blog post we were inspired by their findings, and decided to tweak their model into something which would work for a team of our size.

Every single (non-support) vzaar-ian is placed into a weekly rota. When it’s your week you get one ticket each day. Simple, right? Sort of.

Here are some of the lessons we learned along the way…

Developer acceptance

I would fully understand if you thought working support, even if only occasionally, seemed like a lot of hassle. To be quite honest, before my first week I was anxious that a big support ticket might consume too much of my working day, and that I’d be less effective as a developer. This proved not to be the case, and we saw very positive results from day one: I was the first to do a week on support, and the first ticket I was assigned resulted in a bug fix being released the same day. The result? One happy customer, and unexpectedly, one very happy developer.

Being able to tell a customer you’ve fixed their issue directly is certainly a buzz for a developer, who is usually at least one step removed from the customer.

Exposure to legacy code

As a developer, it’s easy to forget that the less well loved legacy parts of your codebase are used by customers just as often as the shiny new features you’ve been working on. Working on support helps you find the hotspots in legacy codebases you should spend time learning (or perhaps refactoring).

An itch to scratch

Issues can sometimes take longer than we’d like to solve. Exposing a developer directly to a customer issue will often mean that they make time to fix things.

A different perspective

The end goal I always keep in mind when I’m developing a feature is that I’m building a tool to make somebody’s life easier. The best way to do that is to understand everyone else’s role in the company. Working support will get you closer to understanding your customers needs, but will help you better appreciate the job your customer service staff do too.

How do I start doing this in my team?

Getting started is pretty straight forward, but there are a couple of caveats. Our experience is that Everyone on Support won’t lighten the load on your support staff; if anything it might result in a modest increase in your support staff’s workload, especially while your team gets to grips with the responsibilities of support. I would advise against implementing something like this until your support team is on top of your issue queue.

Given that, here is some advice we’d give to anyone wanting to try out Everyone on Support:

Don’t let people take the easy way out

Assigning tickets to team members on their support week can help ensure that they get a balanced and reasonable workload. Ensure that people get a chance to see different sides of the company to what they’re used to, keeping it interesting, but with a good balance of support inquiries relevant to the assignee.

Set reasonable expectations

Decide on what a reasonable load of work would be, based on the length of time your support staff normally spend on their tickets. As I mentioned, we generally get assigned one support ticket a day on our support week, however, we will adjust if a ticket turns out to be too big, or too small. If your company is large enough to handle taking people out of your production schedule for longer, you could even assign more tickets.

Don’t let support suffer, be flexible

Sometimes deadlines loom, and assigning a ticket to someone will result in a long delay before they’re able to start working on it. Instead of having the customer wait, anticipate scheduling issues and be flexible if someone needs to move their week. Make sure they still do it though!

Training wheels at first

Having support staff members proof-read your team’s responses can make you more confident in your replies, and help ensure that you get the right tone. For a challenging issue, consider pairing with a member of your support staff.

Get feedback on your new features

If a ticket comes in relating to a new feature you’ve recently shipped, you will probably be the best placed person to help your customers with it. Try and make sure you get assigned any tickets for newly shipped features. Your support staff will then be able to follow your lead.

Conclusion

I’d strongly encourage you to give Everyone on Support a try. I think your developers – and everyone else on your team – will feel the benefits, even if they don’t always admit it!