In case you missed it, here is everything I said in my Lead Dev AMA the other day
I had a few questions that would be great to get your thoughts on. You mentioned that ‘Some hands support’ can work well at big and small organisations. Are there any specific use cases where you’ve seen it work particularly well?
Well a lot has changed since I gave that talk and I now work in a much more sophisticated support organization. When I was at Clubhouse, the support staff were decidedly less technical (I hate the term “nontechnical”) and we were fairly reliant on engineering for doing deep investigation into issues and pushing fixes.
“Some hands” then meant being particular about which engineers we pulled into customer issues. We wanted to make sure we were bringing the right engineers who had enough familiarity with the components and code base to diagnose and (hopefully) resolve the issue. Cycling through the entire engineering team might have just caused more trouble than it solved.
Here at Nylas, everyone on our support team is a support engineer. They all need to have some ability to read and write code and work with the same APIs and SDKs that our customer use every day. With that strong foundation, we’ve worked with our engineering team to institute an escalations process which ensures that we are only passing a small percentage of issues to Eng and that ALL the communication with customers goes through the support team.
Could you share a little more about how you get buy-in from engineering team members for a support rotation?
Nylas had cycled through a few rounds of “firefighter” Eng teams by the time I got here (the last incarnation was called “Hot Shots”) and it was clear to everyone that it simply was not working for us. Engineers did not like spending all day fixing other engineers’ bugs and they often ended up getting pulled off bug fixing to do feature work. So when I proposed that we do away with the Hot Shots team, I think there was a collective sigh of relief.
- Getting all our bugs into one place rather than scattered between Trello, Phab, Jira, and Slack (we chose Clubhouse, natch!)
- Devising a priority system and prioritizing our bugs
- Setting up a regular cadence to meet about status
In your experience, what does Day 1 look like for an engineer on support?
At both Clubhouse and Nylas, the initial touchpoint is ALWAYS with the support person. Support should own the conversation from start to finish. When we bring an engineer in to the conversation, we should always be standing by to make sure the discussion stays on target to resolving the customer’s problem.
Right now at Nylas, most urgent escalations go to the Eng on-call so that person is already at the ready to be interrupted. Otherwise, assignments happen round robin at a weekly meeting so people know they are responsible for a particular scope of work and all the information about who in support to reach out to with questions is on the Clubhouse Story. When in doubt, people ping Alexis our AMAZING Escalations Lead.
Oh yeah, that is another thing. You need someone to coordinate!
Our Escalations Lead is responsible for tactical comms between Product, Engineering, and CS. I own strategic comms (as a member of the leadership team). I am also, of course, an escalation point and can flag up something as ON FIRE when Eng (occasionally) pushes back.
Managing Escalations is a tough job, so you should definitely get someone really sharp and persistent to handle it. Oftentimes, she has to roll her sleeves and pair with the engineer to move the issue forward since she is frequently more knowledgeable about how the system works (or errr should work )
Thanks so much, Camille. It’s really interesting to hear about the different support approaches between Clubhouse and Nylas. Are there any core learnings from the approach at Nylas that you’d recommend for organisations that might not have support engineers?
Well a few things:
- Let the customers team own the customer conversation all the way through even if an engineer is stepping in to help out. The Eng team may know the code but the customer support person knows the comms. Let them do what they are good at!
- Keep educating your support team. One reason I hate the term “nontechnical” is that once devs brand people as such they oftentimes start dumbing things down in their communication with the people they’ve branded as such.
If you hire support people with high aptitude and keep educating them, you may be amazed at what they are capable of. You don’t need a CS degree to parse or write code. There are tons of great online resources and people can learn a LOT on the job if you are empowered.
Camille E. Acey 
Leave a Reply