Earlier this year, Y Combinator partner and Wufoo founder Kevin Hale came to speak with 37signals about how to design software users love. Here’s the talk he gave at UserConf 2012, that inspired our support team to invite him to our company-wide meetup:

Kevin is big on making everyone at the company do support, and how that informs what he calls “support-driven development.” When everyone has to answer customer emails, they’re more invested in improving the product for the people who pay for and use it.

We’d considered a “5% support” model before, wherein everyone at 37signals would answer tickets one day a month. But it wasn’t primarily because we wanted everybody to get touchy-feely with customers; it was because we were drowning in tickets. We ultimately tackled that problem in other ways — by expanding business hours, hiring a few new people and creating a comprehensive help site. “Everyone on Support” no longer seemed imperative.

We were missing the main point, though. Putting designers and programmers and everyone else in direct contact with customers isn’t about putting out fires; it’s about fire safety. It’s about having the kinds of conversations that lead to better products in the first place.

The idea is hardly novel; plenty of successful companies (Amazon, Olark, Zappos) train every employee to work one-on one with customers. Paul English, CEO of Kayak, told Inc. Magazine:

The engineers and I handle customer support. When I tell people that, they look at me like I’m smoking crack. They say, “Why would you pay an engineer $150,000 to answer phones when you could pay someone in Arizona $8 an hour?” If you make the engineers answer e-mails and phone calls from the customers, the second or third time they get the same question, they’ll actually stop what they’re doing and fix the code. Then we don’t have those questions anymore.

But let’s face it: Few people are going to jump at the chance to answer tickets if they don’t have to. (“I don’t know how you guys do this every day” is a common refrain among developers who jump in on support.) Still, no one denies it’s good for them, or for the company. Ultimately, leadership has to believe it’s valuable, and be willing to get their own hands dirty too.

Fortunately, that’s the case here — after all, Jason and David used to answer all those emails themselves, so it was familiar territory. Shortly after Kevin’s talk, Jason asked everyone (via Know Your Company) “Is there anywhere we’ve been all talk and no action?”

The earful he received from the support team was what it took to finally get “Everyone on Support” implemented. Ann hopped on the case and assigned everyone in the company a “buddy” on the support team, someone they could go to with questions and who could proofread their replies if necessary.

We’ve been at it about eight months now. We still have some kinks to iron out — sometimes we’re fully staffed, for example, so the “EOS” person doesn’t have a lot to do — but for the most part, we’re pretty tickled with the results. A few discoveries we’ve made so far:
1. It’s an incredibly useful training tool. The fastest way to familiarize a new hire with our products is to have them answer questions from customers. Nathan, who joined us in July, says that he absolutely learns something new with every EOS shift. “As a new employee, that was vital to helping me understand what we’re doing and how we’re doing it. Seeing how some of our jobs get stuck in the queues (avatar uploads, project exports, daily mailers, etc.) really helped tie some of the things I see in Ops to what our customers are doing.”
2. Long-standing problems get fixed. It’s not uncommon for a designer to improve the way something is worded on our website during their EOS shift, or for a programmer to spend some time squashing a bug based on an interaction with a customer. Especially when we have sufficient coverage for the day anyway, that’s been a fantastic use of the EOS shift person’s time.
3. The workflow process has applications outside support. “My ‘real’ job is so scattered,” says Andrea, our office manager. “I’m usually working on 2-3 issues at one time. When I work EOS, I try to focus on one thing at a time, resolve. Focus -> resolve. Focus -> resolve. Applying that mentality to my real job helps me feel less scattered.”
4. It reminds us why we’re all here in the first place. Our customers are the reason we exist as a company — the reason we get to do the work we love and take home a paycheck for it. That can be easy to forget if you never interact with them. “Software engineers and designers are often divorced from the consequences of their actions,” Kevin says. Not so if everyone has a stake in making sure the product is a pleasure to use. “Ops can rapidly get detached from the customer, because all we’re doing is keeping the lights on and helping set up new apps,” Nathan adds. “EOS keeps me reminded of why we’re doing that, and how our customers use our products.”
Does everyone at your company have a chance to interact with customers? If so, tell us more about it in the comments.