Developer Relations Guide to Not Being a Support Engineer
Assume good intent and respect the user
Point to online forums or other existing resources
Pass off to official support channels where ever possible
Fail fast: Admit that you can’t help someone. Set limits on the amount of effort you’re willing to expend and then stop after that.
Gather as much information from the requestor as possible before attempting to find an internal answer, even if it seems like an easy question.
Existing support channels exist for a reason and are usually the most effective way to get people help. Help people find them as much as possible.
I’ve done developer relations at Google, which is a big company. At a big company, it can sometimes be hard to find the right support channels internally. Particularly for areas outside your immediate domain or sphere of influence. At Google, DevRel in most cases is not the support channel, it’s not part of our job.
I’ve also done developer relations at Docker, which was and is a small company. There too, there are dedicated support channels. It’s actually a bit easier in that context to find the right people to help out, and it can be more part of the role of someone in DevRel to provide that connective tissue.
So take this advice and modify it for your organizational context.
What this document is not about
In our roles in Developer Relations, we are often called upon to work closely with partners and customers. We are also called on to give presentations or answer questions as part of sales engagements. This document is not meant to cover those situations. And yes, there will be gray areas but hopefully the general principles will help and apply.
In Developer Relations, we hire people who want to be useful, helpful, and enable developers. Due to our prominence in the community and in the company, as well as our expert knowledge in technical areas, people will often seek us out to answer technical and product questions, even in areas that we do not have expertise in. But, this does not scale. Developer Relations in most organizations is not support channel. And Developer Relations is usually small enough team that we cannot scale effectively if we are answering a bunch of 1-off questions.
This is a collection of suggestions and strategies that can help you help others without draining the time of you and other team members. This doc is the collective wisdom of people who have spent too much time and frustration trying to help someone.
Respect for the user
Requests for information frequently appear reasonable on the surface. And to the sender they usually are. Big companies can be opaque to someone outside and difficult to navigate internally as well. People who aren’t specialists in our individual areas don’t usually understand how many people work here, and what the differences are between different product areas. If you work on kubernetes, surely you can help with email, or hardware, or mapping.
And for us they can be maddenly complicated, running us up against things like
- product boundaries
- who actually knows the answer
- what we are allowed to communicate externally
- legal concerns And so much more.
None of the advice in this doc is prescriptive. Your relationship with the other person - or a community that they are in - is important. Of course, we always want to be respectful of the other person. And in some cases, your relationship with the person asking may tip you from one strategy to another. If this is a friend or an important person in your network, someone active in the community, or a potential significant customer you may be willing to spend more time and energy trying to help.
On the other hand, your relationships with fellow team members matter as well. If you send too many requests to internal teams to help out just this once, they may become reluctant to help in the future, especially teams outside DevRel.
Processes and proceedures that they have in place to deal with these kind of requests are there for a reason. They exist to help people get the right answers and to help the teams scale. At most companies, in most cases this results in people getting the answers they need as quickly as possible. So respect for those process and proceedures are important to respecting and keeping relationships with peers.
Common One-off Support Scenarios
- Someone approaches you on Twitter or some other online medium and asks a question you can’t immediately answer.
- Someone emails you, whether your email is easily guessable or publicly available. This may even come in via your personal email address.
- Someone internally passes on a request asking you to help out a friend or customer. “Can you find someone in DevRel who can answer this?”
Common Types of Requests
- “Can I/my friend/my customer just talk to someone for 10-15 min about X”
- “What is the roadmap for X feature/product?”
- “I’m having trouble reaching support, can you help me unblock it?”
Common (bad) results of doing an enquiry
- DevRel Person 1 sends email “Hi, can anyone engage with person Z about problem X?”
- Reponse “+ThisOtherList Someone here may know the answer”
- DevRel Person 1 send response “Hi, can anyone talk to person Z?”
- Response “Please get more information about problem X”
- DevRel Person 1 either begs for someone to talk to person Z, or goes back to person Z and gets more info. That info is not enough so response “+AnotherPersonOrList might understand more/FYI.”
- AnotherPersonOrList responds “Please identify a specific chunk of information from person Z”
- DevRel Person 1 (crying at the keyboard) “Can someone please just talk to person Z, I don’t know anything about this area, I would like to make an introduction.”
- Response “+EvenMorePeople we need to know more about problem X before we can identify who can talk to them or if we can talk to them”
- Marketing Googler: “Person Z would like to talk to someone about Maps/Cloud/Python/ etc.”
- DevRel Person 1 “I would be happy to meet with person Z” logistics
- Person Z: “Thanks for meeting with me. Here’s my product pitch for 1 hour”
- DevRel Person 1: “OK, what is your question for me”
- Person Z: “What do you think of my product?”
- Pass off to official support channels wherever possible. If they are an existing customer, make sure they submit a ticket. If they haven’t already, tell them to do so and if you want, ask them to get back to you if they don’t hear back. If they have, make sure it wasn’t a short time ago: “Oh, you submitted that an hour ago, let’s give that a bit of time to get back to you.” If it wasn’t as recent, and you feel it is important, get information about the ticket (ticket number, contact information that submitted it, whatever will identify the issue) and then ask the support team to look into it. At that point you are probably done.
- Pass them off to sales when possible: If they’re asking about problem X, and they’re a potential customer, a sales person may be able to engage customer engineers. There’s usually some internal tools that let you look up whether someone is a customer
- Point to online forums such as StackOverflow or resources that already exist. If there’s docs you know about, point to those. One way of doing this is to say “Oh, other people might have that question too. If you post to StackOverflow/appropriate place to post, I’ll see if someone internally can answer it.” If it’s easy to answer, go ahead and answer there, or pass it on to someone on DevRel who wants to up their SO score. This way there’s an answer that everyone can benefit from, not just the asker. An answer likely to show up in search. Some folks will be reluctant to do this because it could expose something they are working on, or they don’t want to generalize their code.
- Fail fast: Be ready to admit that you can’t help someone. Set a goal of “I’ll only send X number of emails” to try to solve this issue before giving up.
- Before trying to find an answer outside of a support ticket, gather as much information from the requestor as possible before attempting to find an internal answer, even if it seems like an easy question. Especially if it isn’t your area of expertise.
- Some teams have internal question forums that are broadly subscribed to. Identifying several of those for your first request for help is a good way to get an answer internally.
- Never promise more than trying. You may not be able to get an answer to a question. Especially if it is outside your area.
- If you’re going to have a meeting, ask them to very clearly articulate what the meeting is about. “Oh I just want to run something by you” is often some sort of product pitch or it is a sign they don’t know what they want. Both parties will have a better experience if the goals are clearly articulated ahead of time. In fact, this may lead to a clarification that you aren’t the right person to talk to them.
- Roadmap questions are different dependent on the company you are at. Make sure you understand what can or can’t be disclosed to this person and what level of access to information they have. . People that “Just want to know when this feature will be added” or “Will support for X be deprecated by such and such date” are asking important questions for them. But your company has reasons for not disclosing information, or only disclosing under NDA to important customers. These kind of questions can be a good way to get people talking to a sales person if they have mechanisms for disclosing that information.
- Learn as much as possible. If this person has the question, there’s a good chance someone else does as well. It may point to holes in documentation, or features people really want or need. Understanding why someone is asking for something may also point to the answer or allow you to direct them to something else that will solve their problem.
- Be sure to share the knowledge internally, you never know what may be helpful to someone else. In fact, the origin of this doc itself is the result of sharing an internal discussion with someone who was asking how to handle these kind of situations.
- Make an active effort to follow up with the requester to find if they were able to find the answer or not. If you suggested certain paths but that did not ultimately help the requester, then you might need to change your decision tree and engage with internal folks to make processes better. This gesture also helps to build better relationships with users.
- Keep a doc with your common answers so that you can copy-paste. Saves a ton of time over a long period. But don’t link to that doc as an FAQ for people since they most likely won’t read it. Share that doc internally with relevant teams.