We've all heard of test driven development, behavior driven development, agile driven development, or whatever new "driven development" fad is hot.
I don't hear a ton about Support Driven Development though. What is Support Driven Development?
Coined by Wufoo co-founder, Kevin Hale, Support Drive Development is:
"injecting humility, accountability and responsibility into the development process by making sure the creators are also the supporters. If I’m going to build this, how does it affect me later when I have to support the user?" - Kevin Hale
In our words? Engineers do support. Or rather, everyone does support.
Why Everyone (Yes, Even Engineers) Should Do Support
1. Support is the fastest way to learn the product.
Support helps you learn and stay in touch with the product. Nothing teaches you faster what your product does well and what it doesn't do well than hearing a customer have problems with something or a customer raving about the problem it solves.
We recently hired our first engineer, James. We had him do two days of support to get up to speed. After the first week we asked what we could do better to help him get started. His answer: a full week of support. Nothing makes you learn a product faster than helping the people using it every day use it better.
2. You Can Easily Fix Your Parts of the Software
If the people who build the software also have to support it, then when stuff breaks the people who know how to fix it are there to fix it.
Our outstanding issues have gone down. We're closing tickets faster. Customers are happier.
3. Incentives are Aligned
When engineers, designers, or copywriters aren't doing support it's easy for them to get sloppy with their work. But if you have to support your own work, then you'll tend to look for the best solution the first time around. And if you don't, the first time you have to support the problem you'll want to jump in and fix it.
I do a lot of copywriting and add a fair amount of APIs to Zapier. As soon as I get a support issue where a customer has had a poor experience I'm instantly looking for ways to tweak a bit of copy to make something more clear or add new/tweak new fields to APIs to make them less of a hassle.
4. Support Tools Get Better
The great thing about being able to build things is that you can automate tasks that are inefficient. If engineers are doing support they'll find places that make support more challenging and will build tools to make support much quicker.
At Zapier we can auto-login as users, quickly see a users logs, go to their admin page or visit their Stripe page one click away. This used to involve lots of clicking around, but once engineers started doing support, support got a lot nicer tools and the time per issue went down.
5. Customers Get Happier
With everyone pitching in on support customer issues are resolved faster because the expert on a particular issue is going to see their support issue.
How We Schedule Support
At first it can be a bit challenging to get everyone used to doing support. What eventually worked for us was a simple support schedule. Micah, our main customer service champ, covers support roughly 24 hours of the week. Then James, Bryan, Mike and I rotate covering the remaining 16 hours of the week.
To keep everyone on schedule we have a Google Calendar that looks something like this:
Then this Google Calendar to SMS Zap sends a text message from our evil Zap Bot 15 minutes before their support shift starts. This keeps everyone on schedule.
If for whatever reason you can't do your support schedule you can easily swap with someone else.
