Having had a bit of a traumatic experience at a previous job, I came to my position as Customer Success Lead with a firm opposition to having any of the developers on the team respond directly to customer feedback. My concerns about devs on support (also known as All Hands Support) were manifold but boiled down to three high-level worries:
My Three Main Reservations About Devs on Support
Communication Style: The guys on my team are all wonderful fellows but for the most part they don’t do a lot of customer-facing work. So I was naturally concerned that they would not be able to craft an email that hit the right balance of attentiveness and concern. Also, to be honest as a woman, we are (for better or worse) often trained to do this kind of emotional labor and to be protective about letting men do it.
Time Suck: The developers here at Clubhouse were hired for a myriad of reasons but chief among them was the fact that they could and would write code and accelerate the development of our product. I’ve seen developers at other organizations go down major rabbit holes dealing with (sometimes minor) support tickets and feared that could happen here.
Timeliness and follow through: I knew that even when my team did a great job communicating with users and managing their time, they still were likely to just let tickets fall through the cracks, since (again) support was not their primary responsibility. I’ve seen this work poorly with other — much larger — teams, and so I was naturally worried.
Why Devs on Support Has Been Worth It Anyway
Scale: We are a small but growing company and more people on support increases our ability to quickly and effectively service our ever-increasing user base. It also frees me up to do more, since my role as Customer Success Lead includes not only support but documentation, customer development, UX, sales/marketing, and product management.
Real-World Use Cases: Responding to tickets has exposed the developers to more people who actually use our software and their real-world concerns in a way that has often been more effective than me just telling them about it. Talking with users about challenges they encounter has definitely helped the devs make decisions about how best to implement certain features.
The Quick Fix: Assigning tickets about a particular feature to the person who built that feature means that you can oftentimes get a speedy fix for any bugs related to the feature. Directing real user feedback to the person who built it can also give them a get a better sense of how it is playing out “in the wild” — which parts work well, which are confusing/disliked.
Easier Access: Since the boss told everyone they would be responding to support tickets, everyone now just understands that support is part of their job here at Clubhouse. I no longer have to feel like I am “bugging” the developers by asking them to look at a support ticket-related issue. It’s not a bother, it’s something we are working on together.
How I Make Devs on Support Work For Us
Process: Before we onboarded all the devs onto support, I created a process doc and directed everyone to it. I also told them to feel free to ping me if they ever had any questions about how to respond to a ticket. At the start, many of them sent me draft responses to review just to make sure they were on the right track. 9 times out of 10 the responses were spot on, but I think that process made me much more comfortable “loosening the reins”.
Oversight and Ownership: As part of the above-mentioned process, I maintain the responsibility of assigning tickets. Every once in a while, an urgent ticket will come in and some one will grab it before I can assign it to them, but even then I go in and make sure it has been correctly categorized. I also keep an eye on responses and make sure tickets are closed in a timely manner.
Avoiding the Time Suck: Every once in a while, a dev *does* unfortunately go down the rabbit hole. A user asks for a feature that should be “easy” to implement or reports a bug that the developer can not replicate but is eager to diagnose and fix. Tickets go back and forth, time ticks away and it just feels like the wrong use of time. In these cases, I will talk to the developer to see if we can manage expectations by thanking the user for their feedback or bug report, creating a ticket in our internal Clubhouse (linked to the Zendesk ticket), and letting the user know we will get back to them when we have an update.
Engagement Guidance: I’ve found developers to have an enviable commitment to building and fixing, but oftentimes customer support is more about listening and learning (more on that here). In guiding developers on support, I will sometimes suggest that they ask more questions before they touch any code. Sometimes the user just wants to hear from us, find out what we’re thinking/planning, and better understand how our product works. Oftentimes, I will just take those kinds of tickets myself, but I think it’s important for the developers to pick up a few of those themselves and deepen their understanding of our user base.
Conclusion: It Works If You Work It
While this experience has opened my eyes, there are many ways it definitely could have gone awry and many situations in which it would have been slightly less than ideal. If we were an org that did KPIs or any time tracking, having devs on support might not have worked for us since they don’t always jump right on tickets and even when they do, they have a tendency to either sit on them for longer than I would or just forget to close them out. Also, if we had no documented process or if I failed to maintain ownership of all the tickets in our Zendesk, it might have been tough going. That said, we need to be mindful of a few things if we want this to continue to work for us.
Iterate and Educate: As our user base grows and our product changes, our documented support process will need to evolve. We will need to continue to train new developers on support about the process as well as potential rabbit holes. Bugs should be documented and triaged but not all bugs can be or even need to be fixed right away. It will be important to keep an eye on when and how bugs get tackled as things scale up.
Some Hands on Deck: Just because we have some developers on support doesn’t mean all of them need to be on board. We are strategic about who on the team is assigned to support, and I am strategic about when and to whom I assign tickets. I aim to strike a balance between effectively addressing our users’ concerns and making sure we can still devote the majority of our time to developing our product and our business. As we grow, I’m open to cycling team members on and off as necessary.
Try Not to Micro-Manage: Using the backchannel is useful when I want to give feedback or suggestions, but I like that our responses aren’t canned (for example, our Australian dev calls everyone “mate” in his responses). I want to make sure I continue to guide without stepping on anyone’s toes.
Having developers on support can absolutely work, but you have to be:
– strategic about who/how you assign
– prepared to manage/support the developers, and
– committed to owning (and iterating on) the process.