Support Driven Development
Support Driven Development (SDD) is a philosophy that emphasizes the importance of engineers and developers taking on support responsibilities. Coined by Wufoo co-founder Kevin Hale, SDD promotes a culture of "humility, accountability, and responsibility" by ensuring creators are directly involved in supporting their work. This approach offers several benefits. Firstly, support becomes the fastest way to learn a product, as engineers gain firsthand experience with user challenges and successes. Secondly, SDD ensures that those with the knowledge to fix issues are readily available, leading to faster resolution times and reduced outstanding issues. Thirdly, aligning incentives through SDD encourages engineers to prioritize quality and efficiency in their work, knowing they will be responsible for its support. Finally, SDD empowers engineers to build better support tools, automating tasks and streamlining processes, ultimately improving customer experience.
To implement SDD, Zapier utilizes a simple support schedule where engineers rotate covering support shifts, enforced by automated text reminders. This system ensures everyone contributes to support while allowing for flexibility and swapping shifts as needed. This approach has proven to be effective, demonstrating the power of SDD in fostering a culture of collaboration, efficiency, and customer satisfaction.
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.