Hi. So, here’s another entry from my notes as an Evangelist. So many snippets I wrote to myself, translated here to blog articles helping, I hope, anyone finding themselves where I was. This one is the role of empathy. Perhaps it is not as obvious as you assume?
For the sake of argument, and I think that’s a fine reason, let’s consider Developer Evangelist, Technical Evangelist, Developer Advocate, and any other variation of a Developer Relations title to be the same. For the most part, they are. For me, here, I will use Developer Evangelist because that’s the title I employed for just under a decade at Microsoft. And, I like it.
If you work as a Developer Evangelist for Acme, your role is to represent Acme to developers who will never otherwise 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. You are not you, in a way.
This is the foundation, but this is not the most important part. Developing rapport and influence with a developer or developer community requires that you connect in a way different than a walking blog. The hearts and minds of developers are your endgame; strategies to reach that goal are what matter.
The problem, of course, with swag is that it reaches the pleasure centers of a developer’s brain but doesn’t establish a long-term connection. Give me your thing and I go to the next guy for his thing. It’s over quite quickly, even if you make it complicated with surveys or games to play.
If I have my way, I give swag to developers who are already my friends, already in my camp, already onboard. A sort of reward-swag, and not a bribe-swag. You’ll see the difference immediately in gratitude, plus your swag might even get some wear before it finds a trashcan or thrift shop.
Information. It’s only getting more difficult to keep up with changes in our industry. A Developer Evangelist has inside information unique and difficult to otherwise get. Insofar as information, presenting value to a developer is giving them something otherwise difficult to find or coalesce.
This, by the way, is a key way to get your sessions accepted at conferences. Bringing unique or generally obviated information to an audience is compelling to attendees and conference coordinators. There’s an art to creating a session title but bringing new or unusual information is a good starting place.
Validation. Developer and architects are suspicious of their own decisions. As a trusted resource, with more information than any developer investigating your product or technology, you have an edge. Providing validation to a developer’s work affirms them and makes them love you.
When you come across a developer doing it all wrong, you’ll want to balance reproach with respect. Tomorrow you leave, but they stay in that job, with that manager, working for a raise to pay their bills. You want to advocate for the developer; don’t feed their imposter syndrome. They’ll love you for it.
It’s worth following-up on this idea that as a Developer Evangelist, you have a sort of responsibility to ensure customers are implementing your product or technology correctly and on a path for success. First, earn the right to speak to a developer; then use that right to guide and correct cautiously.
Prescription. Most developers are willing to figure things out. That said, most developers love to have prescriptive guidance that side-steps the “dumb tax” they might otherwise pay in the process. Your value to these audiences is an explanation of how to get started and where to go next.
This type of information is ofttimes presented in case studies of other customers, sometimes we use phantom customers to get the point across. We can also get prescriptive guidance in developers’ hands through tutorials, technical white papers or personal odysseys of discovery we document.
Remember, empathy is your ability to understand or feel the emotional state of another person. Sympathy, on the other hand, is responding to another person’s emotional state. I am not suggesting a Developer Evangelist needs sympathy (though it does not hurt) but that empathy is paramount.
One of the most powerful ways to develop empathy of any type of developer is to live their life. It’s walking a mile in their shoes. If you wonder what a developer experiences when trying your product, try doing the process from scratch and documenting every single step along the way. It’s illuminating.
Another important corollary could be inclusive design. To really understand how users feel when they are using your application without the use of their eyes, try to use your application with your monitor turned off (or covered) and see how you fair. Again, like above, it’s illuminating.
It’s important to mention here that a Developer Evangelist can easily betray the good name of their product. Things like “Yeah, it’s not that stable” or “I’m sick of all these bugs, just like you” can undermine confidence or even the hope of confidence in a product. You might feel like you are being honest and genuine with your audience, but you are laying a foundation of distrust.
Here’s the take-away. Most developers are struggling. When you hear yourself thinking, “It’s not that hard” or “Just use the docs” then you might be falling into the same trap Stack Overflow moderators do. You are forgetting that every developer is in a different place and your job is not to prod them to work harder, but to encourage toward hope and help their lives, today, be better and easier.
Find ways to look at developers with empathy; a compassion that lets you be willing to talk slower, present 101 instead of 401 sessions, re-explain the very concept you have already explained a thousand times before, and look forward to their success, not yours.
For the sake of argument, and I think that’s a fine reason, let’s consider Developer Evangelist, Technical Evangelist, Developer Advocate, and any other variation of a Developer Relations title to be the same. For the most part, they are. For me, here, I will use Developer Evangelist because that’s the title I employed for just under a decade at Microsoft. And, I like it.
What is an evangelist?
Let’s start with a simple question with a complicated answer: what is a Developer Evangelist? Hopefully you start with “brand ambassador” where like an edge-of-the-empire garrison represents the throne and is the throne because the king or queen will never travel this far from England, you are the brand.If you work as a Developer Evangelist for Acme, your role is to represent Acme to developers who will never otherwise 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. You are not you, in a way.
This is the foundation, but this is not the most important part. Developing rapport and influence with a developer or developer community requires that you connect in a way different than a walking blog. The hearts and minds of developers are your endgame; strategies to reach that goal are what matter.
Give it all away
The first tool in a Developer Evangelist’s toolbox is swag. I have a love/hate relationship with swag. On the one hand, I love to see an audience’s eyes brighten when you give them something that has little value, but somehow means a lot to them, individually. My favorite swag is baseball hats.The problem, of course, with swag is that it reaches the pleasure centers of a developer’s brain but doesn’t establish a long-term connection. Give me your thing and I go to the next guy for his thing. It’s over quite quickly, even if you make it complicated with surveys or games to play.
If I have my way, I give swag to developers who are already my friends, already in my camp, already onboard. A sort of reward-swag, and not a bribe-swag. You’ll see the difference immediately in gratitude, plus your swag might even get some wear before it finds a trashcan or thrift shop.
The three other things
If swag doesn’t reach the hearts and minds of developers, what’s left in a Developer Evangelist’s toolbox? We have three things: Information, Validation, and Prescription. These are the things that really impact the behavior of a developer. Let me explain.Information. It’s only getting more difficult to keep up with changes in our industry. A Developer Evangelist has inside information unique and difficult to otherwise get. Insofar as information, presenting value to a developer is giving them something otherwise difficult to find or coalesce.
This, by the way, is a key way to get your sessions accepted at conferences. Bringing unique or generally obviated information to an audience is compelling to attendees and conference coordinators. There’s an art to creating a session title but bringing new or unusual information is a good starting place.
Validation. Developer and architects are suspicious of their own decisions. As a trusted resource, with more information than any developer investigating your product or technology, you have an edge. Providing validation to a developer’s work affirms them and makes them love you.
When you come across a developer doing it all wrong, you’ll want to balance reproach with respect. Tomorrow you leave, but they stay in that job, with that manager, working for a raise to pay their bills. You want to advocate for the developer; don’t feed their imposter syndrome. They’ll love you for it.
It’s worth following-up on this idea that as a Developer Evangelist, you have a sort of responsibility to ensure customers are implementing your product or technology correctly and on a path for success. First, earn the right to speak to a developer; then use that right to guide and correct cautiously.
Prescription. Most developers are willing to figure things out. That said, most developers love to have prescriptive guidance that side-steps the “dumb tax” they might otherwise pay in the process. Your value to these audiences is an explanation of how to get started and where to go next.
This type of information is ofttimes presented in case studies of other customers, sometimes we use phantom customers to get the point across. We can also get prescriptive guidance in developers’ hands through tutorials, technical white papers or personal odysseys of discovery we document.
Empathy
This is where empathy comes in. Understanding where a developer is on this scale is difficult. A kind of cold reading is an important part of personal interaction, and even reading the audience from on stage. It’s a mind-meld at scale. Changing your tone and intent on the fly is an important ingredient to successful Developer Evangelism.Remember, empathy is your ability to understand or feel the emotional state of another person. Sympathy, on the other hand, is responding to another person’s emotional state. I am not suggesting a Developer Evangelist needs sympathy (though it does not hurt) but that empathy is paramount.
One of the most powerful ways to develop empathy of any type of developer is to live their life. It’s walking a mile in their shoes. If you wonder what a developer experiences when trying your product, try doing the process from scratch and documenting every single step along the way. It’s illuminating.
Another important corollary could be inclusive design. To really understand how users feel when they are using your application without the use of their eyes, try to use your application with your monitor turned off (or covered) and see how you fair. Again, like above, it’s illuminating.
The magic
Communicating empathy is like magic. When you say things like “I know what you mean, the portal tells you to do it this way, but it never works, does it?” You are not betraying the good name of your product, you are empathizing with your audience. It’s the sort of warm rain to which everyone relates.It’s important to mention here that a Developer Evangelist can easily betray the good name of their product. Things like “Yeah, it’s not that stable” or “I’m sick of all these bugs, just like you” can undermine confidence or even the hope of confidence in a product. You might feel like you are being honest and genuine with your audience, but you are laying a foundation of distrust.
Here’s the take-away. Most developers are struggling. When you hear yourself thinking, “It’s not that hard” or “Just use the docs” then you might be falling into the same trap Stack Overflow moderators do. You are forgetting that every developer is in a different place and your job is not to prod them to work harder, but to encourage toward hope and help their lives, today, be better and easier.
Find ways to look at developers with empathy; a compassion that lets you be willing to talk slower, present 101 instead of 401 sessions, re-explain the very concept you have already explained a thousand times before, and look forward to their success, not yours.