Hi. So, here’s another entry from my notes as an Evangelist. Many of the snippets I once wrote to myself I have now translated into blog articles that I hope will help anyone who finds themselves where I once was. This one is about the role of empathy. Perhaps it is not as obvious as you assume.
For the sake of argument, and I think that is reason enough, let’s treat Developer Evangelist, Technical Evangelist, Developer Advocate, and any other variation of a Developer Relations title as the same. For the most part, they are. Here, I will use Developer Evangelist, since that was my title for nearly a decade at Microsoft. And I like it.
What is an evangelist?
Let’s start with a simple question that has a complicated answer: what is a Developer Evangelist? Hopefully, you start with “brand ambassador.” Like a garrison at the edge of the empire that represents the throne because the king or queen will never travel that far, you are the brand.
If you work as a Developer Evangelist for Acme, your role is to represent Acme to developers who would otherwise never connect with Acme. For this reason, being “on message” is critical. For this reason, the theater of evangelism is important, and playing your role is imperative. In a way, you are not you.
This is the foundation, but it is not the most important part. Building rapport and influence with developers and their communities requires connecting in ways that go beyond being a walking blog. The hearts and minds of developers are your endgame. The strategies to reach that goal are what matter.
Give it all away
The problem with swag, of course, is that it triggers the pleasure centers of a developer’s brain but does not build a long-term connection. Give me your thing and I will go to the next person for theirs. It ends quickly, even if you complicate it with surveys or games.
If I had my way, I would give swag only to developers who are already my friends, already in my camp, already onboard. A sort of reward-swag, not a bribe-swag. You will notice the difference immediately in gratitude, and your swag might even get some use before it ends up in a trashcan or thrift shop.
The three other things
If swag does not reach the hearts and minds of developers, what does? A Developer Evangelist has three real tools: Information, Validation, and Prescription. These are what truly influence behavior.
Information. It is getting harder to keep up with the pace of our industry. A Developer Evangelist has inside information that is unique and difficult to otherwise find. Bringing that value to developers means giving them something they could not easily discover or piece together on their own. This is also a key way to get your talks accepted at conferences. Bringing unusual or overlooked information is compelling to both attendees and organizers.
Validation. Developers and architects are often suspicious of their own decisions. As someone with more information than most, you can provide validation. Affirming their work builds trust and affection. When you find a developer doing something “wrong,” balance reproach with respect. You will leave tomorrow, but they remain in that job, with that manager, working for that raise. Your role is to advocate for developers, not fuel their imposter syndrome. They will love you for it. You also carry some responsibility to make sure customers are on a correct path with your technology. First earn the right to speak into their work, then guide carefully.
Prescription. Many developers are happy to figure things out, but they love prescriptive guidance that helps them avoid the “dumb tax.” Your value is in showing how to get started and where to go next. Sometimes this comes in case studies, sometimes in made-up scenarios, sometimes in tutorials or white papers, sometimes in personal journeys you have documented.
Empathy
This is where empathy comes in. Understanding where a developer is on this scale is difficult. A kind of cold reading becomes part of personal interaction, even when reading an audience from a stage. It is a mind-meld at scale. Changing your tone and intent on the fly is an important ingredient in successful Developer Evangelism.
Remember, empathy is your ability to understand or feel another person’s emotional state. Sympathy, on the other hand, is responding to that state. I am not suggesting a Developer Evangelist must have sympathy, though it never hurts, but empathy is essential.
One of the most powerful ways to build empathy for developers is to live their life. Walk a mile in their shoes. If you wonder what a developer experiences when using your product, start from scratch and document every single step. It is eye-opening.
Another exercise is inclusive design. To understand how users feel when they cannot see, try using your application with the monitor turned off. See how far you get. That, too, is eye-opening.
The magic
Communicating empathy is like magic. Saying things like, “I know what you mean. The portal tells you to do it this way, but it never works, does it?” is not betraying your product; it is empathizing. It is the kind of warm rain everyone relates to.
It is worth pointing out, however, that you can easily betray your product. Saying, “Yeah, it’s not stable,” or “I’m sick of all these bugs, just like you,” can crush confidence in a product and create distrust. You might feel like you are being real with your audience, but you are laying a foundation of doubt.
Here’s the takeaway: most developers are struggling. When you catch yourself thinking, “It’s not that hard,” or “Just use the docs,” you may be falling into the same trap as a Stack Overflow moderator. You are forgetting that every developer is at a different place. Your job is not to prod them to work harder but to encourage them toward hope and to make their lives better and easier today.
Find ways to look at developers with empathy, with a compassion that helps you slow down, present 101 instead of 401 sessions, re-explain a concept you have already explained a thousand times, and look forward to their success, not yours.