Evangelist, advocate, community builder, whatever you want to call it, since Guy Kawasaki of Apple popularized the concept of “technology evangelism,” the role has become a staple addition for software outreach. New startups and corporations alike now often hire evangelists — a rather nebulous breed of employee between sales, marketing, engineering, and support. Evangelists tread many different camps, know their product in and out, receive feedback from the community, and work to better the product and consumer experience as a whole.

Nowhere is the title more relevant than in the API space, where Application Programming Interface (API) program advocates attend or host hackathons, create tutorials, give assistance, and more, spreading the good word of API on and offline. From advocacy at Google to Twilio’s evangelism, the precise makeup of developer relations is still being defined. With all this interest in a relatively new title, it made us question, what exactly does an evangelist do on a daily basis? And, most importantly, what advice do they have for creating a successful, thriving developer community?

So, we’ve reached out to the masters for their insights. For anyone seeking to become a tech evangelist, or who has recently been ushered into the role of promoting an API program, this is the article for you. For this Q&A session we interviewed five API developer evangelists from throughout the industry.

8 Important Job Roles of a Software Evangelist

1: Be sure who your users are

Most agree that the number one job of a software evangelist is to intimately understand your consumer. According to Daniel Rudmark, a senior researcher at Viktoria Swedish ICT, attracting developers to an API program must be grounded in empathy:

“I often find that organizations publishing APIs do not sufficiently recognize that developers are not paid up front for their work — they come to you for some other reason which you need to understand and support. Remember, they spend their valuable time on your API”

There is an increasing amount of diversity amongst third party developers — varying technical understandings, different industry backgrounds, geographical location, and more contribute to your user persona, who may turn out to be different than you think. According to Guillaume Laforge, product lead and APIs dev advocate at Restlet:

“There are tons of different developers, using different languages, different tech stacks, focusing on different devices… think about which ones to target first”

Evangelists must intimately understand this audience, but must also foresee shifts in audience that could occur as a product grows. Evangelists placed into a legacy community have just as an important role in sustaining and extending a user base. As Keran McKenzie, Developer Evangelist for the MYOB API program told Nordic APIs, it all starts with knowing your audience:

“In some ways I was lucky in that I inherited a legacy community so I had an initial base to start with, in other ways because of that legacy base, it dictated the path we took. Once you know your audience (and ”All developers“ is not a valid answer to who is your audience) you can begin to work out targets for building new community, plans for content & resources and event activity.”

2: Communicate the value(s) of the product

The next most important role of an evangelist is to efficiently communicate the value of the product. As developers are the lifeblood of APIs, they are the consumers that must be sold on the benefit of your API if they are ever going to use it. This role stems from a technical understanding of the product, knowing how the product stands out from its competition, and an easy, open relatability with others.

An evangelist must always be prepared to communicate value in many situations — whether it is a quick description to a colleague, writing tutorials in a developer center, a long-form blog post, or pitching a demo at an event,

“the primary role of a developer evangelist in forming a developer community is to help customers and potential users see the value and benefit in your product or API to such an extent that they themselves become evangelists for your company.”
– Liz Rush, Developer Evangelist at Algorithmia

A successful API program turns users into evangelists, thus enabling the most effective, time-tested marketing tool possible — word of mouth.

Awesome functionality is easy to communicate — for example, the Star API gives you real-time luminosity, color, and spacial data for over 100,000 astronomical positionings. Though there is certainly value in the data or functionality wrapped in your API, McKenzie adds that reputation is just as interconnected with value:

“In many cases however the value of the API is actually the value of your brand, your market and partnerships beyond the initial data/content or service”

3: Ensure the program is attractive and usable

It makes sense that developer experience (DX) has become a focal point for treating API services as usable products. As an API evangelist is the bridge from product to community, they must evangelize DX as well. Evangelists often build and upkeep developer-facing resources, such as the developer portal, SDKs, and language libraries.

“…you need to provide technical tools that enable swift problem-solving to avoid developers having to figure out the many quirks of your product”
-Daniel Rudmark

laptop-evangelist-nordic-apisWe’ve covered the many ways to improve API usability with things like content negotiation, hypermedia, API gateways, Mullet-in-the-back architecture philosophy, and much more. To be agile, API programs must balance simplicity and complexity, have ongoing testing, and always be compiling feedback from users on how to improve.

Proper design is unique to the service and thus complex to define — but you know bad design when you see it. Evangelists need to evangelize the best version of their product not only externally, but internally as well.

As with any technical product, support channels must be in place to aid onboarding. A good dev center and documentation should answer most of this, but the best evangelists will jump on a call to quickly aid a developer user to success.

4. Always be observing, talking, and gathering feedback

Evangelists are vocal. Online they blog, prowl Stack Overflow, maintain GitHub repos, manage developer-dedicated social channels, and respond to all comments or questions. Evangelists often take on a customer support role, and must offer rapid and effective customer service.

To Rush, the most important aspect of being a successful evangelist is a willingness to talk and answer people’s questions…no matter the setting…even the dance floor—

“…you have to be prepared to be ”on“ at almost any time. Yes, the majority of it is done at meet ups, online, conferences and the like, but honestly it happens at unexpected times too, ranging from someone who overhears you talking about algorithms in line at the coffeeshop to chatting with someone you just bumped into on the dance floor at a warehouse party.”

McKenzie sees transparency as “hugely important in the role of an evangelist. We are often the face/voice of the brand, so we need to be as open as we can.” As developers rely on the uptime and consistency of your product, this means communicating negative changes with care. When an API is updated or retired completely, the way a company delivers this message is often “more important than the message itself.”

5. Host, attend, or speak at events

Microphone in focus against blurred background

“The best thing you can do is roll up your sleeves and get involved.”

The sea of API-related events has expanded tremendously in recent years. A traditional event model has been to host hackathon competitions that encourage developers to build things with your API, often for a prize incentive. Proposing talks at larger conferences is also important to get the word out and learn from others. However, evangelists must be selective, and tailor their travel time and events to be in-sync with their program objectives. Often, this means supporting smaller events or partnering with other hack events rather than hosting your own:

“Too often people think building a community means running a hack event, we found that running our own hack events didn’t fit our API, however attending & participating (as a team vs API vendor) in hack events was invaluable for building out a community. The best thing you can do is roll up your sleeves and get involved.”
-Keran McKenzie

Digital events like screencasts or webinars can be helpful too. But physical conferences are places to share projects, discuss strategies, and easily network with people who have the same interests. How could we not append this role? :) Contact us if you’d like to speak at a future Nordic APIs event, and come to our API Stack Conference in April!

For evangelists preparing a hack demo, don’t miss our checklist on crafting an unforgettable API presentation

6. Build and maintain a knowledge center

wrenchBlogging is important, but some argue that building is even more so. A developer advocate creates content that speaks louder than they could alone. This includes instructive tutorials, integration walkthroughs, and shared stories from the developer community, all organized with beautiful site architecture and design. All this does a lot to support your API, but at the end of the day, documentation is king.

“In the API world, you have to treat the documentation and content you provide as your number one priority as an evangelist. If you have poor or no documentation for your API, most potential customers won’t be able to use it and will give up almost instantly.”
-Liz Rush

LaForge adds that the onboarding process and documentation should be constructed in a way that appeals to the specific use case for the API:

“Spend a lot of time on the on-boarding process, how developers get started, with great API documentation. But not just ”reference“ documentation, but thinking hard about concrete use cases, in terms of scenarios: developer X wants to do Y, here is how to do it with the API.”

7. Translate technology trends

Evangelists help revitalize stagnation. Following fluctuations in technology can help an API program be agile and responsive to industry momentum. Adam Duvander, a developer advocate at CenturyLink Cloud, began his career writing with Wired and ProgrammableWeb, and continually shares what he observes and researches in the field:

“I translate back-and-forth between the technical and non-technical to put trends into context”

Framing the technical in a way that entrepreneurs, marketers, or designers can comprehend is helpful for all involved. A learned, vocal, opinion on innovative tech strides, whether it be microservices, Golang, or Docker, etc., can be greatly appreciated by a community that depends on your specific tech to survive.

8: Build a community of heroes

At the helm of the API ecosystem, the evangelist fosters a sense of community around an API. If your marketing team executes all of the activities stated above (on top of having a stellar product) you should see overall usage increase, and a community emerge around the service. That being said, there’s a fine line here — you can’t really force “community” to happen. Evangelists can only encourage its evolution. Be helpful, but don’t be a drag:

I like to talk about “being in their face” but “out of their way”. We need to be visible, the developer community need to know we are here to make them heroes in their own right, at the same time we need to put everything in place so we can be invisible and out of their way.”
– Keran McKenzie

For McKenzie, community building means constructing all the tools for support — resources, documentation, articles, tutorials — everything that enables a community to be as “self sufficient and effective as possible.”

“A community could emerge out of the blue, by simple virtue of having a useful and popular API…but more often, you’ll have to encourage developers to use your API, by providing on-boarding resources, easy demos, developer portals with top-notch documentation, a forum, a super reactive support team… you’ll have to play on several fronts to get a community to form, especially on the communication channels you’ll open up with that community.”
-Guillaume Laforge

What does an Evangelist do each day?

The daily work of developer evangelism and advocacy comes down to responding to the user’s needs. But, certain tasks come up often enough to get a general idea of the role. Through interviewing evangelists in the field, we found that some of the tasks they perform on a daily basis are as follows:

Customer relations Events Support
Social media activity Travel Respond on Stack Overflow
Authoring blog content Host webinars Dev center maintenance
Weekly newsletter Speak at events Test the API
Recognize and award hero developers Research, gather feedback Work on Github helper libraries

Evangelism vs Advocacy

There is arguably enough of a difference between the job roles of an ‘evangelist’ and ‘advocate’ to make certain distinctions.

In the proposed 5 level maturity model for developer relations, advocacy is at the top, defined as a two-way dialogue in which developer support and gathering feedback is paramount. In the same hierarchy, evangelism is a rung below, and consists of attending conferences, explaining, and the like.

DevReloMeter nordic apis

Use the DevRelOMeter to see if you’re practicing ‘evangelism’ or ‘advocacy’

Writing on his personal blog, ex Pusher advocate Phil Leggetter analyzes the dev relations mission statements for Google and Twilio. Using these cues, Leggetter built the DevRelOMeter, a cool tool that will tell you if your team is actually performing evangelism (awareness & acquisition) or advocacy (product support & retention).

What developer relations — or devrel — consists of will inevitably be unique to that company, but critically considering the ROI for certain activities surely helps.

Q&A Section

What lends to the best interaction with customers? How do you help developer users the most?


I think it’s the unexpected events that tend to lead to best interaction. Let me give you an example. Last year Jack Skinner & I were in Auckland, NZ for an event when a support ticket from a developer came through. We were just a block away, so Jack headed over to their office just at 5pm as they were packing up. He spent an hour or so with them going through the issue, making sure things were solved and delighting this customer. They were not expecting Jack to turn up, let alone go that extra mile to ensure everything they needed was solved. Of course we can’t always go out and see customers like that. Sometimes it’s as simple as picking up the phone vs emailing a response as a great way to drive a delightful experience the developer community.


“From my research where I have both performed a great number of in-depth interviews and analyzed video recordings of developers having used APIs I would say that the number one way to help developers is understanding what developers may be struggling with and make sure to resolve these issues. The tricky part is that such information seldom reaches the API provider and that the developer often just quits working with the API. This means that you need to be very mindful about how you deal with and act on the (little) feedback you actually get – it is quite often just the tip of an iceberg.”


“Be kind, be friendly, be helpful, try to provide the best level of support, and on-boarding experience. Then when your API evolves, be sure to keep users updated, try to avoid breaking compatibility if it can be avoided, try to improve the API (improve usability, response time, provide more features)”


“The best interactions come either when a developer has integrated the API and are delighted at how simple it was and just want to say ”thank you“ or when a developer is having trouble with a certain part of the API and I’m able to help them out and get them back to building their application.”

How do you retain users?


“In our space our developer program is much more than just an API. It’s about a partnership…retaining developers for us speaks to building a true partnership. I personally spend a lot of time with this group of developers talking about their customers, their solutions and how to bring those to market.”


“In the API world, the question of customer retention is primarily taken care of with one simple rule: don’t break things. Of course, this is dependent on what you’ve done to bring users in: you have to prove the added value of your service, show how easy it is to integrate & use, and more broadly speaking, solve more problems than you create for your customers.”


“User retention is the job of the entire company. If the product works, is priced well and has good support, account management and much more then users should be retained! I don’t concentrate on user retention exactly, as I see evangelism as more outreach and finding and supporting developers…though I do pitch in with support on social channels, such as StackOverflow and GitHub”

In your opinion, is dev evangelism support, sales, marketing, or a new breed of employees?


“It’s definitely a merger of all three. You can’t be a developer evangelist if you can’t cut code, likewise if you can’t have a solid sales conversation, discuss go-to-market plans and of course actually get out and market your API, then you aren’t going to go far…. Finding a Developer Evangelist is (I think) one of the hardest roles in business to fill. When you find someone, do everything you can to nurture and hold onto them.”


“This is a contentious question among evangelists — in fact, many don’t even use the term ”evangelism“ because of the fact that it has become nebulous and often misapplied to sales engineers or support engineers. I think of evangelism as a new but growing role different from support, sales, and marketing. Since evangelism is often most popular among companies that provide APIs, the terms don’t fit quite as well since these traditional divisions are often blurred, especially in the startup world.”


“It’s really at the crossroad of all those activities. That makes the job even more challenging and interesting because you can tackle different classic areas: a developer-oriented evangelist might be more keen on crafting a demo for supporting a customer, another one with a creative personality might love authoring great articles and documentation resources, etc….It’s also the kind of job that you can tailor yourself, depending on your own aspirations, as well as according to the needs of your company.”


“At Twilio we are part of the marketing organisation and that works well for me. We may perform support tasks, but getting out there in developer communities and talking to developers face to face and online is the priority.”

For More on the Importance of API Evangelists, watch this talk by Tony Blank of


i-love-apis-shirt-nordic-apisThe actual tasks an API evangelist performs will often fluctuate, especially as roles are blurred in the startup world, as Rush points out above. Arguably, openness and transparency triumph in the position. If you are going to have an active voice in the developer community, it definitely helps to integrate these core ideals into your presence.

At the end of the day, API programs want apps to flourish — meaning that evangelists are only successful when the developers they support are successful. Phil Nash, developer evangelist with Twilio, framed it well when he told us:

“I am successful when the developers I serve are successful, whether that is writing a Twilio app or not.”


Thank you to our interviewees for participating in this Q&A! We didn’t intend to be exclusive with our panel, and hope we get the chance to talk with other API evangelists and advocates on the topic in the future.

Bill Doerrfeld

About Bill Doerrfeld

Bill Conrad Doerrfeld is an API specialist, focusing on API economy research and marketing strategy for developer programs. He is the Editor in Chief for Nordic APIs, and formerly Directory Manager & Associate Editor at ProgrammableWeb. Follow him on Twitter, visit his personal website, or reach out via email.

  • Lorna Mitchell

    This was such a valuable insight, thanks! I’m a developer who also writes, speaks and event organises for fun so I’m really interested in becoming an advocate. My worry though is that it would be hard to go back to being a developer afterwards because such roles are seen as non technical. Does anyone have any advice/experience for me?

    • Hi Lorna, really glad that you found the article useful. This is a great question, and I’m sure others who have made the transition can respond better than I can, but my two cents would argue that if you can strut your programming know-how by demoing your product or related frameworks at coding events, participating in building out GitHub libraries, creating extended code tutorials, and the like, you can retain credibility as a developer while also doing the work as an advocate. If an evangelist doesn’t dig into code at a developer-attended event, for example, they may find an apathetic reaction.

    • Greg Bulmash

      While you’re not building large scale apps, you’re definitely writing code. Part of being a Developer Evangelist is having the chops to be credible and authentic as someone talking to developers on their level. If you can’t understand their problems from their point of view, how can they trust your advice? So any evangelism org worth its salt is going to make sure that there’s time budgeted in your schedule for writing code, for playing with the newest frameworks and libraries, etc. As noted in the article, you not only have to know how to do what’s needed to day, but you need to be a bit of a futurist and keep an eye on what’s coming.

      OTOH, most of the people I know who moved out of Evangelism moved into Product Management because that’s where their interests were leading them and Evangelism is a great transitional space for filling in the gaps between Developer and Product Manager.

  • I really appreciated this post. Thanks so much.

  • Greg Bulmash

    Great article, Bill. For me, the hallmark of a good article is whether I have to stop and write down all the thoughts it starts pinging around in my skull. Did that three times here. I’m actually ramping up in a new company on a new product and just going through the descriptions in this helped me focus my thoughts on things I needed to do and questions I needed to ask.

    • Awesome- really glad it was that helpful for you. thanks for chiming in below too – happy to get your perspective in here in at least some form. What is the new company / role?