This week, I wanted to dig deeper into the world of Developer Evangelists, one of the most important people in any tech company, with a focus on making developers aware of the platform.
As for any role in DevRel, their role is highly confused with a lot of others. A DevRel role always changes according to the company's needs and market fit. But, this is true for most unconventional or new jobs that get created due to a new development in the ecosystem. The Business to Developer (or B2D) market is fairly new, and DevRel, the key people in making it successful, must work in all pathways. They are the reason behind this ecosystem being much more inclusive, strong, and rewarding for everyone involved!
For the sake of this series, I've focused on an ideal Developer Evangelist job, shying away from the extra things they might need to handle alongside.
As the title suggests, let's clarify this in the beginning - Developer Advocacy and Evangelism are not the same thing.
People always argue that if you're in the field of DevRel, largely you're doing the same thing - i.e., talking to the developers. But they do not realise, as the B2D sector grew, the job role of DevRel expanded. This eventually led to all the different sectors, where the focus is on one aspect, and the knowledge of others adds to it.
The difference between Developer Advocacy and Evangelism is the same as between a Frontend Developer & a Backend one, a DevOps Engineer & a Cloud Engineer, a COO & a CMO!
A better way to portray this is, of course, imagining Developer Advocates as the ears and Developer Evangelists as the voice of a company's product.
Talking about a voice, a mic always comes into the picture. Developer Evangelists can be easily imagined as that person with a mic. Their ability to share information accurately and precisely is what makes them suitable for this job. Giving hundreds of talks in a year, Developer Evangelists are conservationists.
Being people whom developers tend to listen to, they are not just the mediators between a company and the outside developers using the product; they even help translate the product side to the internal technical team.
It is someone they listen to who can make a difference here. Developer Evangelists are those people. They have to experiment with whatever's going in the market and let the extended community know about it. A curious engineer will always ask questions like "Why?", "What if," "How can this feature be improved?", "How does this work under the hood?" - a Developer Evangelist should have an answer to that.
It's not necessary for them to be a specialist initially or to have a successful coding background. Still, while evangelising a particular technology, they need to be specialists speaking the specifics, addressing the pain points/specialties, and talking with developers in their language.
Just imagine an Evangelist promoting a cloud technology who does not know how Serverless works. It would be a nightmare for them to tell developers how to use it. Though no one expects them to know everything, people expect them to speak the language of a developer who will be using it regularly.
Developers are free to choose between products and tools. If the competition has a better product for a use case and the developers reach out to ask which one is better, a developer evangelist should admit the case. If not, they'll be behaving like a traditional marketeer, which would ruin the developers' trust.
While this might sound like a defeat for the evangelist, in reality, this has a huge impact on the community. Developers understand that the company accepts that they cannot be good at everything, and their focus is on improving the product and not just selling it. Developers appreciate evangelists as people who understand good technology. This can also be a great way of market research, where developers themselves will tell about the competitor product making it nice feedback for the product team.
The best source of outward communication by a developer product is their documentation. Developer Evangelists also make sure that the documentation is at par. For a developer-focused product, documentation is one of the most important reasons for being adopted by fellow developers.
Not just that, they act as a steward of open-source projects that the company starts or sponsors, including performing code reviews, contributing code to the project, writing public, open-source libraries to wrap APIs for the company's products, or even helping to integrate those into existing open source projects that might make use of them.
Additionally, they are directly in contact with the PR and Marketing teams to help them understand the importance of the projects and the role that open-source plays within them.
I once read someone consider Developer Evangelism as a job of speaking at conferences, meetups, or hackathons - using companies' money to go around and have fun attending them.
While attending events is a major part of their job, the above statement cannot be farther from the truth. No company will ever spend money unless they see results out of it. It might look just traveling on the top, but engaging hackers is one of the major tasks - showcasing the impact one makes here is the ultimate goal.
The times of COVID19 have clearly showcased the impact Developer Evangelists make. Every week we're seeing some great ways of making an impact making sure that the community stays together and grows together, even in the tough times.
It's not about a company; it's always the product that matters.
The ideas, the focus, the way of representation - it all depends on how it will impact the product and how it will impact the developer community!
Top comments (0)