I have been directly involved in developer relations for almost a decade. Indirectly, for about another five years on top of that. When I first started, there was only the term "evangelist". Over the years, for one reason or another, the term "advocate" has become more mainstream. And all along there has been some aspect of "community". In this post, I will set out my views on these roles as I have come to relate them to others.
It is difficult to tell when exactly the "hype cycle" came into being, but it is most commonly associated with Gartner, and has become a prominent (albeit not without flaws) model in the Information Technology industry. The hype cycle consists of five phases.
The first phase is the "innovation trigger". This is when an idea first manifests itself on the market. Note the keyword there of "idea". While there may be no shortage of examples of given technology in action, the business model remains relatively unproven at this point.
Peak of Inflated Expectations
Next up is the "peak of inflated expectations" phase. Eventually an idea takes hold, somebody, somewhere, runs with it, and before long there are a handful of individuals/companies touting how great the idea can be.
Trough of Disillusionment
Not every idea can be a winner however, and as such comes the "trough of disillusionment" phase. If supporters of the idea cannot bear actual fruit, the idea will likely die off here ... Or potentially slip back on the overall curve.
Slope of Enlightenment
Now we are getting somewhere. The idea has "crystalized" (as Wikipedia puts it), has likely seen a second or third iteration, and companies are starting to understand how to use it to their benefit. This is the "slope of enlightenment" phase. The idea has become mainstream, but implementations still lack broad adoption.
Plateau of Productivity
At the "plateau of productivity" phase, a business model has been established - or at least a definitive return on investment. At this point you can talk about the idea at pretty much any industry event, and people will at least know of it, if not have specific opinions about it.
While the hype cycle (curve, really) can be applied to just about any market, in the context of IT, we are talking about technologies in use by developers. In that respect, providers of the idea will be looking to get their implementation into the hands of developers. In my view, developer relations roles cover the entire hype cycle.
What differs however is how vendors will want to relate to developers in the context of where their implementation sits on the hype cycle. Companies driving their idea up the peak of inflated expectations will relate to developers differently from those whose idea has become an industry standard. This is the foundation of how I break down the roles of evangelist, advocate, and community manager.
The term "evangelist" borrows heavily from a religious context - specifically the evangelistic model found in Christianity. In the religious context, an evangelist is primarily interested in getting as many people as possible to hear their message. Ideally, an evangelist creates converts. Converts then in turn evangelize others, and so on and so forth.
Within the context of technology, specifically the innovation trigger and peak of inflated expectations phases, this is exactly the type of role you want on your developer relations team. You want to achieve as much mindshare for your idea as possible.
You do not have a community at this point (or not much of one), and the technology simply is not mature enough (or not adopted broadly enough) to shoot for much more. As such this will be largely a one-way conversation, and you should be okay with that.
Do not mistake creating mindshare through evangelism with sales. All developer relations staff should be deeply technical, motivated by the idea itself, and not be coin-operated. I will circle back with more thoughts on this in another post.
As your idea progresses up the peak of inflated expectations, and moves into the trough of disillusionment, you are going to need more than a one-way conversation to get through the tough times ahead. You are going to need staff that can interpret feedback from a growing customer base, into actionable terms for product management - an advocate.
Note that while there is now a two-way conversation happening, that the primary goal of an advocate should be to champion the needs of the developer (customer), not the technology (company). An advocate needs something to advocate for - this is the developer, hence "developer advocate".
That being said, product management will likely also have ideas of their own that they wish to vet against developers using, or looking to use, their technology. As product management has the job of running a product, there is only so much of this work that they can do themselves. A developer advocate can help scale the reach of the product team.
If the product team has a feature they are considering, an advocate will know just the right customer for them to talk to, and know how to make that connection. Product teams should not only embrace the function of the advocate, but also relish the feedback and chance to connect with customers.
Keep in mind here that at this stage of the hype cycle, an idea is still working towards mainstream adoption. It may be that the way customers want to use the technology differs from how the company views that technology being used. This can cause friction between advocates and the product team. Senior management would do well to remember that the advocate is representing the customer (read: where the money is at).
As an idea pushes up the plateau of productivity, and becomes mainstream, there is potentially (usually) less work for an advocate to do. The idea has become mainstream. Everybody is using it. Communities have formed. The business model has largely solidified. An advocate can provide customer feedback all they want, but the idea has really taken on a life of its own at this point.
Here is where I see the evangelist role resurfacing.
Borrowing again from Christianity, nothing gets a congregation (those with the religion already) more excited than a visit from the evangelist out in the field. The flock is excited to hear the latest news about the growth of their religion from the front lines. First hand.
In technology terms, when it comes to an established product, one that is mainstream, the role of the evangelist is important to keep people informed about said technology, and to keep the interest alive. Evangelists at this stage of the hype cycle will largely communicate specifically what their company is doing, from a features perspective, within the context of the overall technology market.
Last, but certainly not least, is the role of community management. As it relates to the hype cycle, communities will generally begin to form organically (on their own, without funding from the vendor), roughly around the trough of disillusionment. This work will continue through the plateau of productivity.
This is about the same time as the advocate comes on the scene, and continues through the resurfacing of the evangelist. Both of these roles however have their work already cut out for them. Expecting them to additionally manage a community will result in a diminished ability to do either role.
Presentations take time to create. Demonstrations of the latest features, especially on software still under development, can be especially time consuming. Travel takes time. As communities grow to the tens of thousands, or even millions, it will simply be beyond the scope of the evangelist and/or advocate to adequately manage the day-to-day interactions.
When a social media outcry surfaces because of feature/pricing/business changes, it is critical to staff community managers to keep the lines of communication open.
This is a high-level outline of how I view developer relations roles and responsibilities. I have not said too much about the day-to-day motivation, operation, and management of these different roles at this point. I intend to cover those topics in future posts. This is a broad brush stroke designed to resolve ambiguity in these roles, and where they most add value.
I will close with a thought to consider further...
Developer relations is a long-term, strategic, investment. Make no mistake about the investment required to do it correctly (time and money). In general however, an operational charter of the evangelist/advocate should be to plot where the technology will be in a year, and start seeding those concepts in the present. If you are making that investment, then talking about what is already in the market is a day late and a dollar short.