>> Hi, my name is Camille.
I run tech support at Clubhouse, a small startup, and I need your help.
And I know what you're probably thinking.
You seem like a really nice person, Camille, but how can I help you when I already have
so much on my plate?
I know it's been a long day, thanks for sticking around.
And we've gotten a lot of really dense information to process.
But I think by the end of this talk, we'll have a pretty simple and actionable plan.
You see, in support, we also have a lot on our plates.
Every time the phone rings or a ticket lands in the support queue or an angry tweet lands
in our Twitter feed or our CEO's Twitter feed.
This is from a couple of weeks ago.
Irate user and the CEO of GitLab.
Every time something like this happens we have to be ready to dig into the problem and
come back with a solution pretty fast.
For the majority of us in support, that's not a big problem.
The lion's share of problems we can knock out ourselves, but many of the problems we
face require attention from you, the engineering team.
By a quick show of hands, how many of you deal with bugs or escalations from the support
team.
Pretty much everyone and how many of you have a regularly scheduled time to meet with support?
Fewer.
And how many of you ever deal and respond directly to user requests?
OK.
About the same number.
Thanks for letting me know.
In the support world, it turns out we actually think about you guys all the time.
[laughter] It's true.
We're constantly devising ways that we can get you to notice us, get a little bit of
your attention, some of your time and get you to consider a closer working relationship
with us.
First we think we'll tell you stories.
Little things from the trenches, anecdotes like, did you hear about yesterday where one
of our users lost a whole day's worth of work due to that front-end change that we just
deployed and then we think, wait, these are computer scientists, they probably want to
see data, so we pull together all of these metrics and beautiful data visualizations
and thinking that you know, that's what you want to see, not just the casual story about
one user one time, but how many people were affected by this change and for what length
of time, how much data was lost?
But even more than stories from the trenches or metrics, what we found to work most effectively
in engaging engineering is a system called all-hands support.
All-hands support is system whereby everyone in the organization from the CEO, all the
way to the newest hire rotates onto the support desk at some regular interval and the goals
of all-hands support are many, but boil down to kind of three high-Level 1s that I've identified.
The first is just capacity.
More people on deck to tackle tickets.
The second one is appreciation for support.
Your support team is on the front lines of your organization dealing with all manners
of enthusiastic users and as we saw before, furious people or people who are just frustrated
and want to crush code and can't do it and the final level of support is empathy.
Providing context helps to make better decisions and when you can understand the user context
and their pain points, you can make better decisions in thinking about how you want to
implement something.
So all-hands support is a noble endeavor to be sure and I've seen all kinds of cool things
happen when engineering and support work well together.
I've seen third-party integrations happen, really cool internal tools and also there's
an opportunity for your customers to have a top-notch experience.
Some of my developers can push a super-fast bug fix and he's just like, wow, that never
happens with any other company.
So it can be really cool, but there's a dark side, too, and if it sounds wild to you, you're
not alone.
I used to positively hate all-hands support.
I remember at one company for example, we discovered that one of our developers was
using his support rotation time to answer tickets on an outside forum as opposed to
the tickets that were coming in from our paid users.
At another organization, big cartel, when they experimented with all-hands support,
their customer satisfaction, that's what Csat means, went straight down.
So, yeah, a lot of things can and do go wrong.
If you're not doing it on a daily basis, it can be hard to answer questions about billing
or dealing with feature requests in the right way.
There's also the simple fact that the support team is the biggest cost center and to leadership
I think it can seem a bit wasteful to rotate them that way.
All that having been said, when I started at Clubhouse, I really tried to go it alone,
but I immediately ran into a scale ability issue that I knew we weren't going to device
out of.
So I tried a sort of a medium way what I call is some-hands support.
Where you rotate some developers into support some period of time.
So far it's worked well at Clubhouse.
Those are process, people, and period.
So first is process.
Any good support lead has a good idea of what support looks like, and should look like at
your organization.
They need to have that codified and be ready to train your developers on that, in addition
to their regular workflows and their tooling, similarly as a developer, you have a defined
workflow that you like to use and it should be codified, as well and shared with the work
team.
I've personally experienced mysterious code being pushed by a rogue developer under the
auspices of helping a customer and so for the sake of this new burgeoning new relationship,
I Harmonize on process.
The second area is people.
Who does support need and who can you sort of afford to be loaned over to the support
desk?
At one organization, Automattic, which supports WordPress, those teams can tackle tickets
related to their specific product.
In addition to technical skills, you also want -- support also needs team players.
We need people with good communication skills and the ability to pick up the sort of communication
that's really effective on the support desk.
If you have certain developers who you feel like you hired just to kind of crunch code
heads-down, that's probably not the person that you want to rotate onto support.
That said, if you have a lot of that kind of developer, you might want to revisit Kevin's
talk and think about how you're doing hiring.
The third area is period of time.
What's the daily commitment?
What's the regular rotation?
It's on the support side we're happy to have as much developer time as you're willing to
give us, but again, for the sake and the health of this relationship it's really good to have
boundaries.
So make sure that that's clear to both parties.
In addition, you want to set a regular interval just to check in with each other.
How is this relationship going?
What's working well?
What needs to be tweaked?
In addition to that, it's always really good to share high level with the whole organization
about any wins that are coming out of this new regime.
So again, process, harmonizing process, support process, development process, people, what
people work, and which ones don't, and period of time.
The period of time, the commitment that you're asking from the users, and from the developers,
and making sure you're reporting back to the organization as a whole about how the whole
thing is going.
So process, people, period.
I think that's our basic plan.
Like I said at the beginning, I know we all have a lot on our plates, but with some more
hands on deck, I really think we can tackle it all.
Thanks.
[applause] >>
MERI: Want to give an extra shoutout, it's so so impossibly hard to do a really amazing
ten-minute talk and I feel like we've had a bunch of them today so if you just give
a round of applause to everybody who managed that.
So go ahead.
[applause]