At Basecamp, we’ve been running an initiative called Everyone on Support for nearly five years now. Each person in the company, whether a designer, developer or podcast producer, spends a day every eight weeks or so responding to customer emails. As Emily wrote a few months in, EOS quickly proved its worth: Direct contact with customers gave people a new perspective on our products, first-hand experience of the problems users were facing, and a reminder of what we were all working towards together. Lessons were learned, bugs fixed, and cross-team relationships were strengthened.
And then we got busy. With customer requests climbing, the support team lost some important people, and those that remained developed an unhealthy obsession with “inbox zero”. Our stress was infectious: Folk would turn up to their EOS shifts eager to help and leave deflated because they’d barely made a dent in the email queue. Each of them had a dedicated support team buddy to ask for help, but rather than “bug us” with questions, they’d spend hours down help-page rabbit holes. And on the rare occasions that things were quiet, they got bored because we weren’t leaving them with anything to do.
Something was very wrong, but the support team was too busy to notice. We didn’t have time to check in with each other, much less the people who were joining us for the day. We’d started Everyone on Support with the best intentions of not turning our coworkers into part-time firefighters, but that’s exactly what they became. Month after month, people would show up, grab the kind of requests they’d seen before, respond to as many as they could before their eyes started to swim, and clock off feeling bad because they hadn’t kept pace with the pros.
We hired some wonderful people, and reset our expectations for the support queue. While we took the time to train our new members, we paused EOS for a few months. That meant that we could put our whole focus on training, and take some time to think about how to do all-hands support right. As part of fixing our unhealthy behaviours, we carved out some time for “research and innovation”. I spent that time working out how we could invite our colleagues into the new, healthier space we’d created for ourselves. Here’s what we did, and what we learned.
Clear expectations are everything
Right from the start, we wanted to be clear about what Everyone on Support is. We put together a guide to outline what we expect from our guests and from their buddies on Team OMG (our pet name for the customer support team at Basecamp). A doc called What is EOS? What is EOS NOT? reaffirms our original goals for the scheme and how we’re going to achieve them together. It also reassures folk that they aren’t fodder to paper over cracks in coverage. We’ll work together to ensure their shift will be interesting, useful and fun.
Hands-off all-hands
As a bad manager in a previous work life, my initial impulse was to impose a solid structure onto EOS. On their first support shift, each person would respond to X number of login emails, then level up to billing issues, before starting to look at feature requests, and so on. I drew up a detailed syllabus, and asked for help fine-tuning it. Jim pinged me, and we had a great conversation, including the following question:
What does the loosest implementation of this look like?
The company as a whole has been moving towards a more structured way of working for a while, but a lot of Getting Real and Rework are about doing less. How can we capture that spirit in EOS? What’s the smallest amount of work we can do to give the most support to the folks doing EOS?
I decided to scrap the syllabus. Using metrics risked the kind of anxiety around speed people had experienced in the past. Being too prescriptive would suggest that there’s only one way to succeed in support. And neither of those things got us closer to our goals for EOS.
I turned my gaze to the work we’d done to onboard the new members of the support team. OMG had done a great job of building a loose framework to support the learning of the newbies, and that felt like a better fit for what we were looking to do with Everyone on Support. I salvaged some bits from the abandoned syllabus, and repurposed them. When EOS would start back up again, everyone would have a collection of resources and some advice on handling common cases.
Basecamp is a company which values independence. The best approach was to give everyone everything they need to succeed, and then get out of their way.
Communication is key
Basecamp’s support team are thoughtful, kind humans. Instead of telling them how to manage their charges, I encouraged them to talk it out, and discover the way that person works best.
I suggested that each EOS day start with a discussion about what our guest supporter wanted to do, and end with a catch-up about how it went:
Your job is to help ensure that your buddy has fun, learns something new and feels good about their shift. Creating the experience that best works for them is going to come down to good communication.
A two-way street
Team OMG is full of good listeners (it’s our job!), and we’re as interested in learning from our coworkers as we are in teaching them. When updating our buddies list, I tried to pair people along shared lines of interest. Time zones made this tricky, but I’ve managed to connect support folk interested in research and product development with specialists in data and design, and the two-way insights have started to flow.
One size does not fit all
When training new OMG team members, we recognise that everyone learns and works in their own way. That’s something we’ve built into our approach to Everyone on Support: for some people, we pick emails that will be of interest and provide hints as to the answers; for others, we leave them to it, and stand by in case they have any questions.
Once someone’s comfortable with email support, it’s up to them how they spend their time with us. If something fits in a single day, and is going to benefit our customers, then it’s a good use of a support shift. People on EOS have squashed bugs, launched customer research projects, improved our internal tooling, leveled-up our external documentation… and that’s just the start!
Everyone on Support is a work in progress, but it feels like we’re going in the right direction. For six months now, we’ve been running a much more chill, cheerful — and constructive — version of EOS. I’m going to keep steering it with a light touch, and check in with people, to see how they feel about where we’re headed. Basecamp’s approach to all-hands support aligns with our values and how we choose to work as a company — so you may not be able to apply everything here to your own initiatives. We didn’t get it right on our first try, and we’ll make more mistakes in the future. It’s worth it.
Do you offer all-hands support? How does your approach differ to ours? Or are you thinking about rolling out something similar in your organisation? And what concerns or challenges are holding you back?
Let us know in the comments! 🖤
Great read, James. How do you guys deal with open cases assigned to one of the members of other teams after their “shift” has ended? Is your support team taking over again?