Introducing Research & Innovation Days on Support

Customer support is a double-edged sword and can be both rewarding and draining. Helping people feels good, but constantly empathizing with strangers can get exhausting. We all hope that the good outweighs the bad, but that’s not always the case. When the scales are imbalanced and there’s stress at and about work, it’s easy to forget that work doesn’t have to be stressful.

Our team answers (mostly) emails and (some) phone calls seven days a week across four continents. Each person works 40 hours a week in Autumn, Winter, and Spring and 32 hours a week in Summer. But, 40 hours a week of nonstop emailing doesn’t allow folks to synthesize the data they just internalized to help guide Basecamp in an interesting direction. How can we analyze feature requests if our energy is zapped at the end of the day, the end of the week? How can we help shape tech support culture at-large if we don’t have time to benchmark or conduct research? Our team is comprised of fourteen badass thinkers with diverse backgrounds, so why aren’t we giving them space to think and collaborate? Finally, how can we introduce more calm into a stressed team?

Over the summer, I convinced Jason and David to let support stray from the 37signals mantra to “hire when it hurts,” which allowed us to hire two people when we thought we were looking for one. Part of my proposal included a schedule that set aside one or two hours per day for each person to work on something other than contacting customers, to be decided by self-selection. When Jayne, relatively new at the time, and I discussed what she could work on during her time off from contacting customers, I encouraged her to use her background as a research assistant to help guide her. That’s how we came up with the name Research and Innovation, or R&I for short.

There’s an element of trust in this type of structure that is essential if your team wants to try this out. Don’t micromanage people’s projects, but do offer suggestions and guidance when asked. I know that each person on the team will spend their time wisely and at their own pace. Ideas aren’t born from ether; they are born from consideration and formulation, research and comparison, all of which require time and space. If someone spends a day formulating an idea, then it was a day well-spent. It’s important not to question that judgment. (If you’re questioning someone’s judgment, then you should also be questioning their position at the company.)

When the time came to execute the concept, we decided to piggyback off our four-week summers: each support rep’s “summer day” during the rest of the year is now their Research & Innovation day. That allows for easier scheduling, gives us an idea of how the summer will look, and provides a full eight-hour shift of uninterrupted focus.

It’s been about a month since we introduced this structure to the team. Some folks do lengthier demos, teaching users. Some create industry-specific accounts to share with users. Some track and analyze feature requests. Some benchmark with other support teams. Some create content for our help documentation. For the record, these were all things we were doing before we introduced R&I. The difference is that instead of squeezing a quick pitch or a fast demo into a ten-minute slot between emails, we can now take our time to do our best work.

Beyond doing our best work, we’ve also noticed a shift in tone and attitude. The team is more involved in the goings-on at Basecamp. We’re happier, more relaxed, with better morale.

Here’s to a calmer 2017!