As the application engineer responsible for your work (what cases you take, etc), it is up to you to exercise your agency and determine how to do the nuances of the job in a way that is authentic to you. As such, the purpose of this page is not to tell anyone how to communicate or prescribe exact steps, but rather to offer suggestions for consideration based on collective experiences and knowledge. The end goal is always for each member of our team to feel empowered to do the job of application engineer in a way that aligns with them individually.
No audience is a monolith, which means it’s okay to start with a general idea and remember that there will never be a single way that will resonate with every single person who comprises our audience. Our audience is that of developers and we could make many wrong assumptions about what developers like/don’t like. The good news is, we have amazing partners in marketing and design who have put in tons of thought to create our content guidelines (just search that here in the handbook and you’ll find all their resources), which can help you think about our audience from the perspective of what likely resonates most.
We are all somewhere on a spectrum of preferring information to be delivered in a way that is straight to the point or gets into all of the context. Structure can help you meet both ends of the spectrum in a single post:
It’s okay to skip the fluff. It’s okay to skip introducing yourself (everyone can see your title in Slack/email signature). It’s okay to keep the pleasantries brief – a quick “hi” can go a long way. TL;DR can be powerful to help offer a cue of what you really want to be sure folks read Provide all the context AFTER you get to the point. This lets you meet both ends of the spectrum (those who crave context vs those who do not). You can make it feel natural with prefaces like “To share more context…,” “To explain in more detail…,” etc. Imagine whoever is reading what you write is busy and may not read more than the first few sentences … how can you structure everything you want to say so that if they don’t read everything, they will still get the most important things? It can make someone feel unheard if you neglect to answer a specific question they ask, even if you know the question isn’t relevant to resolving their issue. Using bold headers, bullet lists, etc can also help break up long text to help folks orient to everything in a way where they can more quickly understand why what you wrote is so long.
Sometimes we have to prioritize work between customers, especially when we engage engineering for help. Try to orient your explanation to the customer in a way that is reassuring to them and doesn’t make them feel like the issue that matters to them doesn’t matter to us. A customer usually doesn’t care what else we have going on or how hard things are for us. They just want to know we care, we are on it, we are not going to ghost them, etc. It can help to tie the timeline to the issue. Something like…
This issue is turning out to be a little unique so I want to engage my teammates who work in this part of our code base regularly. I’ll see what their workload is like right now and make sure we give this attention as soon as we can. I am hoping to have an update for you in a few days at the latest…
…can go a long way to setting expectations, with context as to why, and in a way that another developer can appreciate, all while making it clear you are driving the process.
It can be very disappointing to have come to us with a question thinking something must be possible only to learn, nope … and developers know all too well that can mean we may never get to it. This disappointment can cause a lack of faith. This is why when a CE is assigned, we immediately bring in the CE to handle the conversation – their super powers allow them to have these conversations in a way that prevents churn risk. For our customers without CE, the risk of churn is lower, but we still want them to feel heard without us accidentally committing another team to something they may or may not do. You can help temper expectations with thoughtful adjective choice. “This is a great idea” might lead someone to believe we will do it. “This is an interesting idea” makes it a bit more clear there is a question for us to answer about whether we will do it or not. You can help set-up your product teammates for success by not saying things like “I am sure our team will want to do this…” and instead saying something like “My product teammates will consider this to see whether we can add it to our roadmap.” You can round it all out by filing a public issue the customer can have and engage on. That act alone makes it clear to the customer they have access to your teammates, too, and the process will be transparent. It’s even okay to encourage the customer to share any additional thoughts they have on the feature request issue and that they can ask for an update if they ever wonder where our team is at with it.
Sometimes we do need to say no. You can help folks work through their frustration by coupling a “no” with an invitation to react and imagining how they might feel. Something like “That is not currently possible. I imagine this is disappointing to learn. I can let my teammates responsible for this part of our code base know what thoughts you might have, if you want to share them.” This is very related to a feature request, but a little different if it’s something we have already said no to. Who knows, maybe sharing such details leads us to change our mind.
Honoring our guiding principle of staying at least a step ahead and never leaving the customer wondering what comes next can put you in control of the conversation. Usually customers only take over and get demanding when they feel like you don’t have next steps or it’s unclear to them what the next steps are.
Showing up for the customer as the one driving a call can make calls go smoother and relieve a lot of the stress they can have. A few ways that can keep you the one driving: Before you get on the call, set expectations: make the customer share what they want to accomplish OR tell them what is possible. It’s even okay to say something like: “I might not be able to solve this on a call, but I should be able to get what I need so we can get to resolution faster.” At the start of the call, restate those expectations that you put in writing before the call. During the call, when something comes up that you don’t know, usually with developers it goes better saying “Could be this, let me double check and confirm after the call.” If someone responds to that unreasonably, they are likely having a bad day and probably treating you differently than they actually want to treat you. After the call, share a summary of what you did and what the next steps are. After the call, follow through on your next steps.
Bonus: It often also goes better when you are the one to initiate the call vs waiting for a case to be going on so long the customer asks after 2–3 weeks and is already frustrated. And remember, it is 100% okay and encouraged to initiate a #rfh (request for help) with engineering via our usual workflow and in it, request that engineering join you on a call if you feel it will help you all resolve the customer’s issue faster.
You have to know a lot as an application engineer and that can get into your head and make you feel like you are anything but an authority. Just try to remember that to the customer you are … you are Sourcegraph. Keeping yourself in the position by choosing your words to be reassuring of that fact helps the customer trust you even while you need time to figure things out. When you bring in others to help and you say something like “I want to talk to my teammates” or “I want to talk to my teammates who work in this part of the code every day” shows the customer you are on it and you will get what they need much more than “I need to talk to engineering” or “I need to talk to [engineering team name].” Our customers don’t know all of our team names and they shouldn’t have to.
Sometimes the hardest part of the application engineer job is trusting how much you do know and projecting that confidence in a way that is reassuring to our customers, even when you have questions yourself. Saying “I don’t know” is honest, transparent, and likely feels natural. It can also trigger some folks to worry they won’t get the help they need. This isn’t our fault. This is the fault of many businesses who devalue their support teams and put them in awful positions to not be able to provide great support. Unfortunately, we sometimes have to take an extra step to prevent our customers from worrying we will be like just another bad support team.