How to become a developer advocate: Part 2, building empathy

Developer advocacy or technical pre-sales can be a great way to use your technical skills to help developers solve their challenges, but the transition also requires a number of soft skills. This blog post, the second in a series, shares four steps that can help build empathy with a technical audience, in both virtual and physical settings.

Read part 1: Public speaking

Read part 3: Finding your audience

Read part 4: Submitting to a call for papers

User empathy has been a key differentiator for me in building relationships with customers as well as internal and external communities. Empathy and integrity are critical to showing authenticity and building trust and are key differentiators in selecting and nurturing developer advocates at HashiCorp.

»Step 1: Live/show the work

The first step in building trust and empathy with a technical audience is to actually work in the space. Build a portfolio of real experience around the technical problems your community is trying to solve. Do a few on-call rotations. Don’t be afraid to share your horror stories. Talk to other people working in your area of interest. Listen to podcasts and news about the topic. Ask thoughtful questions.

I try to devote half an hour before a practitioner meeting to study up on their specific environment and use case and think about alternate ways to approach the solution. I want to come in with a series of questions that will help me be a better advisor.

Sometimes specific preparations may not be possible (at a conference, for example) so it is important to practice and understand common workflows and patterns for the technologies you support. When you are meeting with a technical person or team for the first time, listen to their challenges and environmental considerations and show integrity and humility in your approach.

Specifically, this means:

• Asking questions about why they made their decisions and what their constraints are
• Offering options with their constraints in mind
• Being completely transparent when they are already running an optimal solution for their environment or when your technology won’t work well for them.

Being honest about when your solution isn’t right for someone is one of the quickest ways to build trust. Conversely, one of the quickest ways to erode trust is to force-feed them a solution that won’t work well.

The key to understanding and empathizing is to work in the space or alongside them when there’s an issue. Once you’ve lived the nightmare of implementing a solution in production that was oversold and has no potential to fully deliver on the requirements, you’ll have a whole new perspective on the importance of seeking to understand the technical and political environment of the users you support.

Don’t be the jerk who collects the check and makes it someone else’s problem. Show up when your users have problems and stay with them as a partner through the grind. Encourage proof of concepts, build tools that show possible options, and test them with your users.

»Step 2: Be an ally

Being an ally starts with looking the part, from how you dress to how you behave. Reflect for a moment on your actions when engaging with your users. Do you present yourself authentically as an ally, or as someone that is asking them for something without providing real value? Your engagement and actions should be reflective of a genuine desire to help your users.

Specifically, this means wearing clothes that are authentic to your professional image but consistent with the audience you are meeting with and representing. My audience tends to wear jeans, t-shirts, and hoodies. I will show up in an outfit like that or maybe a t-shirt, slacks, and a jacket. At conferences, I try to incorporate an obvious piece of my wardrobe that makes me easier to spot in a crowd.

This isn’t about dressing for the job you want — that’s for meetings with managers, sponsors, and leaders. This is about dressing for the job you are authentically doing and visually differentiating yourself from sales, marketing, and others who are less technical and come with their own motivations.

Body language is also key in representing yourself as an ally. For example, in meetings, make it a point to sit next to the key technical people, who often sit opposite from the sales team or far away from them. This sends a signal to the technical audience that you are on their side and there to help them. It also makes it easier for you to ask questions and encourage your users to share their comments and thoughts with you.

When meeting someone 1:1 at a conference or other event, you can still work to sit or stand next to them as you explain technical concepts and features. This creates the sense of you being on their side while inviting interested passers-by into the conversation.

Watch and listen to the people you are engaging with — if they step or lean back, don’t be afraid to ask them the awkward question “why”, in the interest of learning how you can best help them. Remember, all of this works only if it is authentic to who you are and who you are trying to support.

Finally, even the most seasoned experts occasionally face questions they cannot answer. Be honest about what you don’t know and talk through your educated assumptions, then offer to follow up with the answer. Nothing is more important than finding a way to help your technologists be successful and being transparent with them about when and where they may experience challenges with your tooling. Work to help them avoid common pitfalls and push through challenges.

»Step 3: Follow up

Once you’ve shown up, asked the right questions, and given some possible solutions to address your users’ concerns, the next step is to check in with them in a timely manner and provide any additional information required, especially points that you promised to look up.

Ask them how your suggestions worked. Ask them about their experience learning and implementing your tools. If they had issues with any part of the process, dig in and figure out how to make it better. Update the documentation or build some content to make the process easier to understand. There are few truly novel challenges in a technical user base, so the information you gain from working with one user is likely to be helpful for others, as well, too.

»Step 4: Ask for feedback

Asking for feedback can be scary, but it’s essential to creating meaningful working relationships and building better tools for your users. Getting feedback can be a part of following up, or it can be as simple as asking people at the end of your presentation if they learned something valuable.

When receiving feedback, do what you can to separate the emotions from the feedback and seek to understand. For example, it may be easy to get defensive when you hear something like: “Your documentation stinks!” When you work hard on the documentation a statement like that can really hurt your feelings. But this is business and your business is helping your users even — especially! — when they are frustrated or don’t love the things that you create.

Some good questions to elicit better feedback in this case include: “What about the documentation did you find lacking?” or “How can we make it better?” If the open-ended question doesn’t get you more information, try a few guiding questions: “Was it a lack of detail for a specific task?” “Was it the ability to find the workflow you were interested in?” These may help you identify specific areas to improve upon, which then will send you back through the steps above.

Building user empathy is a key step in the path to developer advocacy, technical community management, engineering, and other technical roles tied to user success. Stay tuned for more installments in our series on Developing DA Skills.