Camille E. Acey

1. Getting all our bugs into one place rather than scattered between Trello, Phab, Jira, and Slack (we chose Clubhouse, natch!)
2. Devising a priority system and prioritizing our bugs
3. 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:

1. 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!
2. 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.