Supporting the developers who use your API is a major part of the overall developer experience.

In this talk recorded at DevXcon, Bear Douglas shares her experience of running developer support programmes at both Twitter and Slack, with practical guidance and recommendations.

Transcript of Bear’s talk

Hi everyone, and thanks. So, we’ve talked a lot about developer support today from a bunch of different angles. And we’ve talked a lot about empathy. There was a great question at the beginning of the day today. And so, what I’m going to talk about is how you can keep developer support positive both for your users and inside your team. So, by way of introduction, hello. I’m Bear. I’m currently in Dev Advocacy at Slack. Before that, I was at Twitter working on Twitter’s API, the data product, and our mobile platform, Fabric. Before that, I was at Facebook working on Facebook’s SDKs and also on Parse. Before that, I have worked in some open source communities like Ember.js, and around helping developers for like the past seven years.

Now, listening to that list of brands, I’m sure some people in this audience have opinions on whether or not there were actually good quality support experience coming from any of them. Some of you might think, “Whoo, what does she have to say that I’m actually gonna learn from?” Or some, hopefully, some of those, you thought, “Oh, yeah. Actually, they do have pretty good developer support.” So, I’m not gonna stand up here and pretend that I have all the answers. I do have a lot of things that I’ve learned, and so most of what I wanted to do is kick off a conversation about support as dev experience.

I think we can all acknowledge that the experience that a developer has when they’re coming to you for help is a key factor in the overall DevX of your product, but how often do we really think about it in terms of the user journey? So, going back to the screen over here, this is what you see if you were using the Fabric plug-in to onboard your app to our tool. This is a screenshot from a while ago. But you come to this state where we’re telling you to contact support when something’s broken. And so, already, in your user journey, you’re starting off with somebody who has had a negative experience and now needs to be helped out of a bad situation. Granted, that’s not the only way that people get into support. Sometimes people just have a question, and either they couldn’t find the answer on your website or in your documentation, that’s also kind of a broken experience, or they’re frankly just being lazy. But the answer is somewhere there, but they don’t know how to find it, or they would rather talk to a person first. But there are multiple different inbound paths into support. And we have to think about, all right, once we get those people in talking to us, what is the best way that we can funnel them through so that they walk away feeling like they had a good time and a good interaction with our brand?

So, what does positive actually mean in this case? It might mean that they had a quick resolution to their problem. It might mean that, you know, they just really like you and the way that you interacted with them regardless of whether their problem was actually solved. At the end of the day, positivity is about feeling. And it’s kind of this hand wavy thing where we want people to walk away feeling good, but feeling good doesn’t always necessarily correlate to their problem getting fixed or the speed at which you got back to them. So, how do you get to positive and how do you stay that way?

There are lots of examples of brands that do a fantastic job of this. For example, on the consumer side, Spotify is awesome at this. If you ever tweet at SpotifyCares and you’re an angry customer, they do their best to turn you around publicly on Twitter. They’ll send you fun playlists of things to cheer you up. And they’re committed to helping people feel good about their brand. And that takes energy, and that takes effort. But at the end of the day, they walk away with something that actually has gotten them good press in the past and has gotten them a sterling reputation for giving good support.

So, for your business, when you’re thinking about, all right, good support is all very well and good, but what is this going to mean for us? It can affect a lot of things. It can affect adoption. If people are having trouble getting up and running with your product, and when they need help, they’re not able to find it, that’s a problem at the very basic level of are people even going to try your stuff? So, support can affect that there. It can affect the success rate of integration. That’s not just about the initial hump of, can we even get this running? It’s long-term. Am I going to continue to use this product? Is it easy to add new features? Do I feel like they’re pushing new features on me? Do I have the help I need when I’m trying to get something done? One of the things that we often measure in support, in fact, I think this is probably…

How many of you have had to do support at some point in your life? Yep. Did you measure CSAT rates with your developer support? Okay. Here’s something that it’s probably going to be pretty telling. How many of you have ever seen a CSAT score below 90% in developer support? Not that many. That’s awesome. Below 80%? Any hands? Okay. A couple. Anyone willing to say that they have seen something below 70%? Okay. So, I will tell you that people might not be in the room to cop to it today, but there are some platforms and some experiences where CSAT on support is way in the toilet. It’s like 50%, 60%, and…oh, sorry. Customer satisfaction. Customer satisfaction, see. Oh, its satisfaction, short for satisfaction. The question was, what was CSAT? And so, it’s a measure of how happy people are with your platform and with the answers that they’re giving you. And it’s one of the standard things that a lot of support teams measure.

And into customer satisfaction also ties their willingness to promote your platform. Are they going to be telling other people, “You know, you actually shouldn’t use this product because it’s pretty broken and no one will help you when it’s pretty broken.” That NPS stands for a Net Promoter Score, and it’s a measure where you’re taking the number of people who are proactively saying, “I will recommend this to my colleagues,” subtracting the number of people who actively detract you saying, “This is a terrible platform,” and then just not counting the people in the middle who are like, “Yeah, I use it. It seems okay.” And that NPS score is something that people put a lot of weight on. Whether that’s correct or not, it is something that is one of the few things that you can really measure about customer support and feel like you have a concrete handle on what’s going on. And all of this, really, is a broadly speaking, a retention play. When you’re trying to keep customers happy with your product, a lot of it is because customer acquisition is really expensive. And once you have them in the door, you want to be giving them a good experience throughout so that they stay with you.

So, what can we do to make this support experience a positive one? We’ve already established that by the time somebody comes into your support funnel, the start of their user journey has been likely that something has gone wrong. They haven’t found the information they need, or they are experiencing something that’s broken. So, you have this initial negativity that you need to turn around starting from the very beginning. So, how do you do that? This slide is mostly a joke, but I realized that it could be that I’m 100% serious about how I’m phrasing this. Giving people the warm fuzzies, I mean, a little bit truly, we want to give people a good positive feeling about interacting with us. But this whole, this phrase, is intentionally a little bit trite. It’s very easy to say empathy. That’s it, like you just have to show them empathy. But what does empathy actually mean in practice, and how can you take a team that every single day has to deal with angry customers and turning them around and keep them positive, keep them empathetic when all they’re dealing with is people who are coming to them with questions and concerns?

I can tell you what it both does and doesn’t mean. Voice and tone is something that is kind of an easy answer where it’s like, “Oh, well, if you just are really nice to them. If you like use a lot of emoji and smile at them, and use exclamation points, they’re gonna walk away thinking that you are super nice and your brand is also super nice.” And don’t get me wrong. Voice and tone are actually very important. If somebody comes to you and you tell them they’re a complete idiot, that’s not gonna be a good experience for them. But it doesn’t boil down to just voice and tone. There is something in the way that you can express yourself that might come off as just a little bit insincere. For some people, emoji are a-okay. It’s how they talk. And because of the way that they speak truly being dotted with emoji and funny expressions and witticisms, it comes off as genuine because that’s who they are. But if you’ve ever written a style guide for your support, I have a lot of doubts about that, because whenever you try and push people into a mold where they have to express themselves in a certain way, you’re stripping the very basic level of how they relate to other humans. So, if they have to adhere to your style guide instead of being able to talk to people the way that they want, you’re already creating a layer of artificiality that you need to bust through in order to get to actual empathy.

So, for voice and tone, and I see some people smiling in the back. Style guides, don’t do it for support. Trust your people, hire people who you trust to express themselves like human beings. So, in this voice and tone, it’s a good idea to have basic rules about how you talk to customers. You should be nice to them, you shouldn’t yell at them, you shouldn’t swear at them even if they’re swearing at you. But this is the very shallowest level of what it means to show empathy.

The next thing is about engaging in real dialogue. If you have ever worked in support, and again, a lot of you have done it as part of DevRel, you’ll find that a lot of people come to you with what you might think of as dumb questions, and we’ve had a lot of people talking today about there being no such thing as a dumb question, and you should be thinking about whether you’re approaching it the right way if you think it that this is a dumb question. And that is definitely true. So, whenever somebody comes to you with a question, take it as a given that they know what they’re talking about, they’re a smart consumer, they’re using your product, and they have something that they’re trying to tell you. So, when you take the time to engage in real dialogue, not just like, “This is the problem. Thanks for your report. We’ll look into it never.” Having that dialogue, even if you don’t have any action that can come out of it right away, is really helpful for people feeling like they’ve been heard.

So, take the time to be your own user research department every time somebody comes to you with a problem. If they have an idea that they think would make your platform way better, instead of saying, “Yeah, thanks. We’ll file it as a ticket for the backlog,” talk to them about what it is that they’re really trying to get at. Maybe they’ve come to you with a solution that they think is the best for an unstated problem where if you dig one level deeper, you find that these are actually problems that your product team is working on. And so, they want to hear what this user had to say about how they would prefer that you tackle that problem. There’s always something to be gained from engaging in real dialogue. There is a time cost to it, which we’ll get to in a second, but engaging in real dialogue is a way that you can concretely express empathy.

Follow up and follow through is something that can be extremely difficult when you’re doing dev support. You’re dealing with a barrage of information coming at you every single day through online channels, through people talking to you at conferences, and at meetups, and synthesizing that and making sure that you aren’t a bridge to nowhere can be really, really difficult. And it takes a whole team, and it takes leadership within that team to make you feel like, “All right. This is something that we have to do, we have to follow up on, and get into as a practice.” Because it’s so easy to hear all this feedback and keep it in here and then not let it trickle through to product.

So, one of the things that we’ve done at Slack that I think is awesome, and Twitter’s recently followed suit, is opening up our product roadmap on Trello so people at least know where we’re going. And if they come to us with this fantastic idea that they really want us to work on, we can point to our roadmap and say, “That is an awesome idea. Here’s where our priorities are for the coming year.” And then instead of having to tell them, “No, we’re not gonna work on this,” or, you know, “We might work on it in some unspecified timeframe X,” you can always align them with what your product team is thinking. And when you don’t have this veil of secrecy over what is actually a priority for your company, it opens the door to have those more honest conversations about where your priorities are, whether the problem that somebody is coming to you with will ever get tackled, and it doesn’t feel like as much of a burn if you tell somebody, “These are our priorities. The thing that you’re talking to us about fits in maybe in the long term, but I’m being honest this is what we’re thinking about it,” doesn’t feel like you’re rejecting them or rejecting their feedback. They’re like, “All right. Yeah, I see what you’re going for, but file my feedback for longer term in…” Instrumentation, I guess.

The last piece is something that we focused on a lot on the Fabric team, and it’s something that I love to do and I wish I could do in more companies but I haven’t done across the board always, which is finding ways to surprise and delight people who have contacted you. So, we actually had a budget and a quarterly goal every quarter around reaching out to customers in a proactive, positive way that would surprise them and make them feel really glad that they were using our product. So, somebody tweeted at me saying like, “Oh, it really sucks when you get reports from Crashlytics. I’m gonna be up all night.” And so, I just tweet them a coffee and said, “Good luck with that.” And people are surprised. They’re like, “Oh, I didn’t expect…I wasn’t asking for a coffee, but I just got something nice.” We would keep track of when some of our most active customers had new releases. We sent them cupcakes. And actually, once, somebody sent us beer when we had a release because they were like, “You’ve been great partners this whole time. We’re also keeping track of what you’re doing.” And that just takes it one level further in the relationship building.

It’s not that you’re just being polite to people when they contact you online. Really getting ahead of the idea of proactive support is really hard. It’s really hard when you have to be reactive all day to people who are coming to you with problems. But taking the time to remember just like one or two not scalable things to do that keep you human and keep you building relationships is super important. And I wanted to say that I haven’t been consistent about doing this throughout life, but it’s really easy to let empathy fall to the side when you’re talking about doing support at scale. Whenever you’ve got hundreds or thousands of people demanding your time and you’re a single person, it’s easy to default to no because it doesn’t scale. But I can tell you that having somebody reply that to you saying like, “I’m sorry. I can’t help you. It’s not scalable,” is like the biggest slap in the face that you could ever ask for. And so, specifically, trying to make sure that you occasionally do things that do not scale but are really worthwhile, is a good use of your time.

But so, all of this is very aspirational in some way because there is a reality that doing this day in and day out can be pretty hard. So, when you’re trying to create these positive customer experiences, you also have to think about your team that’s getting barraged with negativity. They’re sometimes taking some flak for customers for things that they really had no control over. And they’re also often doing this on their own. A lot of online support happens one-on-one through email. You might have a forum, but people are basically on their own all day. So, how do you make sure that your team can continue to stay empathetic when they’ve got this inbound constantly? It’s really hard. And there are a couple of things that I have learned about supporting supporters. And again, I say this with a caveat that I haven’t always been the most consistent, but they’re things where, in an ideal world, we’d be great about them all the time.

The first thing is to nix your case tool tunnel vision. And what I mean by that is that if you work in any sort of developer support, chances are you’re using something like Discourse, you’re using Zendesk, or UserVoice, or any number of tools that manage email communication back and forth. And when you’re doing that all day, it can be like, that’s the only thing you see all day. You’re not talking to your teammates, you’re talking to external customers. And all of the metrics that you’re responsible for, your time to first-response, your customer satisfaction all come from this tool. And that’s an extremely isolating experience. It’s nearly impossible to stay empathetic to people when all you’re seeing is a computer screen day in, day out.

So, ways that you can get people out and about and not just looking at these tools all day, try and have a standing team lunch. That’s something that I wish I could have done. A lot of us are were remote. When you have a remote team, that can be really tough. So, just having a regular stand-up where you get to talk, get to communicate, know that you’re not the only one pulling to make all of this better for your customers can be super helpful. Even just having a continued chat where you’re just pinging into your room saying, “All right. These are the things that I’m hearing today. Anyone hearing similar things from customers? How can we band together? What’s the status on this product?” That level of communication and of connectedness can really help out.

The next part is about venting with your team. You take a lot of the brunt of negativity when you’re on a support team. And it’s not healthy, and it’s not fun to have to bottle that up inside and just be a sponge for a lot of people’s bad vibes. So, you need to give your team a way to let it out, but you also have to set boundaries on how you let that out because if at the end of the day you’re like, “Oh, Mr. Grumpy Pants over here doesn’t know how to do a simple Google search for the answer of what we totally posted in our Docs. Well, Mr. Grumpy Pants, you’re on your own.” It’s, you want to get that out and be like, “People are being jerks to me, and I can only take so much.” But if you start to trash-talk your customers, you get into this awful negativity spiral where you stop being empathetic because you figure all your customers are stupid. And you can’t do that. So, you have to give your team a forum where they can vent the bad vibes and get support from one another without getting into trash talk about customers. So, how you navigate that with your team is going to be a little bit individual, but I think it’s perfectly fair to say like, “All right. Come and talk to me or come and talk to our teammates. Maybe don’t put it in chat. Talk about it aloud.” It’s ephemeral, it goes away, and it can…then no one can point to that as like a long history of you’ve been creating this negative tone on your team.

Another thing that I have had a teammate do that was especially great was say, “Hey, guys, we’ve got this angry customer. Who wants to turn them around?” And then the person who volunteers is like, “You know what? I’m gonna do it. I’m getting in there and I’m gonna turn them around.” And then when they turn them around and there’s a positive response on Twitter, we all celebrated, we all get up and clap. And that is kind of like the opposite of venting, right, that can help take something that is extremely negative and by acknowledging that it took some sort of Herculean effort for you to turn this person around really helps you feel like the job you’re doing is a good one.

Again, with a barrage of inbounds, especially when you’re supporting hundreds or thousands or hundreds of thousands of people is managing urgency on the team. When everything feels like a trash fire, nothing is a trash fire, right? So, you have to figure out what is actually a huge problem, and when can people feel like, “All right. I can sign off from my computer. I can go to bed. I don’t have to be thinking constantly about what’s broken and what is going to cascade into terribleness if I leave my computer for a second.” So, one of the things that we did was we instituted a support on-call, which helped a lot. It meant that you were the number one triage person for figuring out if something was actually urgent, and if it was, reporting it to the product team, and being the one point person to figure out messaging it out to customers after the incident had been resolved.

And I’ve seen this on a lot of really high functioning support teams is that they have an on-call system just like many ops teams do. You are responsible for incident management. You’re responsible for making sure that other people are brought in at the right time if you need support. And it helps the other team…the rest of the team not have to feel like everything is on fire all the time, and it’s a huge thing for your mental health.

One of the things that I talked about earlier was these moments of delight that we had a quarterly goal for. And I think was actually important that we set this as one of our quarterly goals that we measured up against because time would come, like we’re doing our mid-quarter check-in and saying like, “All right. How are we doing on bringing delight to customers?” And sometimes we’d be like, “Oh, we haven’t done anything. We’ve got money. What are we gonna do with it? Let’s spend like $100 and send somebody a great swag package and get a bunch of love.” And taking the time to step away from, “All right. How are we scaling ourselves? How are we doing with serious business supporting customers?” And thinking proactively about the fun, about the happiness, about the relationship building is a really good way to get back into that realm of thinking.

And the last thing is talking to the rest of the team who are not doing support, your product team, your engineering team, about the love that you get from customers, too. So, the funny thing about being in a support organization is that you both get the flack for things you’re not responsible for, and you also get a lot of the credit for things that you’re not responsible for. So, you can feel kind of like you’re in this double bind where it’s like, “Great. Yeah. I’m really glad you like our product. I like it, too. I did not contribute code to it, but this is great.” So, when you share that love with your broader product team, it can really help counteract some of the negative effects of dealing with unhappy customers all the time. Sharing the love helps you feel the love.

All of this and about managing support as part of your daily life and your emotional state and in your career leads me to talk about something that I think I would at least would like to talk to the whole room about, which is, support, as it figures into the broader career of people who are in developer experience. So, quick show of hands in the room. How many of you have the title developer evangelist? Okay. Developer advocate? Okay. Developer something something engineer, like developer tools engineer, developer experience engineer? Okay. How many of you are support engineers? Okay. So, in that generalized bucket of developer experience, developer evangelism, developer advocacy, different people have to do different things at different companies. That’s a very trite way of expressing that for some people, Dev advocacy includes doing support every day. For some people, Dev advocacy is just the outbound talks and writing documentation, and there’s a whole n’other department that handles developer support. And I’ve seen a bunch of different models at different companies, but one of the things that I’ve noticed is common is that it’s very hard to fight the perception that support is a dead end job. And I say that with some trepidation because it’s not a great thing to say in front of a big audience of hundreds of people who have all had to do this at some point or another. But I think it is kind of an elephant in the room that needs to be addressed.

Often, you see people who are coming in to engineering with non-traditional backgrounds, and for one reason or another, they say, “Oh, they haven’t met our engineering bar in side interviews. But you know where they can go? They can go to support engineering.” And it sometimes gets heralded as a way that you can get your foot in the door inside an engineering organization. And I think we have to be very critical about how often that’s true. How sticky is the floor of starting in in support? And what can we do to build ladders, either so that you can grow in being a support engineer, or give people an actual path up and out. And that’s something that we can do somewhat as developer support managers or developer advocates. But the key thing here is to maintain empathy not just for the people who we’re serving, the customers, but for our own teammates. When we hire them, what are we promising? Are we saying that you’re gonna be working on tickets all day? Are we giving them a path up and out? And how are you investing in your team? Are you giving them training? Are you giving them other projects to do so that they can do what they want to long term inside support? And one of the things that can really help people maintain empathy in their day-to-day support life is if they know that this is one broader step on a ladder that’s going to take them somewhere.

For example, if you’re doing support day-in day-out, you probably have an incredibly clear picture of what’s broken with your product and what your customers want and need. So, if you’re going to take that to become a product manager, you actually have a lot of context that people don’t have in terms of synthesizing all the feedback. You probably have some basic user research skills that you can parlay into doing some other types of work for your organization. And so, I don’t have a clear point here, but I did want to call this out as something that’s important because for people who have support as part of their role, for some people, this is like the thing about their job that they hate the least and they want to put it in a box. And for some people, they love it. And at the end of the day, your customers can feel when the people who are doing support at the other end feel like it is the part of their day that they want to put in a box and would prefer never to look at again. So, when we’re thinking about how we hire support teams, and how we support them within organizations, keep this top of mind. What career path are you giving the people who do support for you? Because at the end of the day, like we talked about, support quality has deep effects on your product, and how people adopt it, and how they think about it, and even on your brand. So, again, I don’t have all the answers. I just wanted to give people food for thought. And so I would love to continue the discussion with some of you later on today. Thank you very much.