I’ve got a few thoughts and ideas I’m going to write about here. These thoughts will connect the reality of evangelism and advocacy with the often imagined notions of what advocates and evangelists may do in their respective roles.
I’ve spent a number of years working in what is commonly referred to as evangelism and advocacy in the technology industry. Most of it has been focused around software development, development practices, and related topics. In addition to the years I’ve worked around evangelism and advocacy I’ve also done a fair bit of it on my own for my own purposes around community development, conferences, and other related things. The companies I’ve worked with as advocate or evangelist include; Basho, Tier 3 (now Century Link Cloud), Home Depot, and others.
There tend to be two key groups that these roles end up under: sales or somewhere near engineering. When it is under sales the evangelism word is often associated with the role along with other problematic issues. When the role is within or somewhere near engineering, the role is often found to be more respected and focused. In the end, both titles and roles under either group tend to be found doing similar work.
Reality Versus Perception
But this is where I want to dive into the realistic roles of evangelism and advocacy versus the unrealistic roles I’ve seen posted and asked for. Let’s talk about some of the common things I’ve seen that pose a seriously broken reality and are red flags. I’ll break these out to perceptions and then realities in the following. Toward the end, don’t worry, I’ll provide some solutions in case you are trying to hire this type of professional.
Perception: I often see descriptions where 50% travel is expected (or more), along with a host of other things like “must be able to write node.js, go, python and contribute to open source project and… and… and…”. To compound matters I often see where these roles need to communicate between departments and act as some mythical type of glue so that engineering can somehow get information from the customers that advocates or evangelists talk to. This is, to put it nicely, a truly odd notion when matched to travel, contributions, and a host of other requirements.
Reality: The reality is this is a pick one scenario. If you want someone to travel and speak 50% of the time the other 50% of the time isn’t going to be writing node.js, go, python and contributing to open source and doing technical meetings and leading groups or something. It’s going to be 50% travel, 20% planning, probably 20% resting and recuperating, and then maybe 10% doing something technical like coding or reading up on the latest technologies. The hard reality is these are not gentle task switches, but brash, hard, brutal, brain shattering task switches that nobody ever accomplishes them efficiently in any way. The fact is people people will actively or simply be forced to drop the ball when the perception is force pushed onto the reality of what will or can be done.
Scott Hanselman said it really well.
Remember that NOT answering an email is always an option. Dropping the ball is sometimes appropriate, especially for your mental health.
— Scott Hanselman (@shanselman) April 7, 2017
Do it. Drop the ball today.
— Scott Hanselman (@shanselman) April 7, 2017
Solution: If you want someone to travel, don’t expect them to keep up with technology. If you want someone to keep up with technology, don’t expect them to travel an excessive amount. Traveling 10–20% of the time is somewhat reasonable when combined with expectations of technical blog writing, coding, contributions, and other involvement. Maintaining a reputable brand for one’s self (i.e. ensuring people trust your code, contributions, and writing) is extremely important. Keeping the travel, code, contributions, and related efforts balanced appropriately with realistic expectations is the only way to maintain a solid self brand and reputation.
Perception: Publishing written articles via blogs and other mediums is by no means an easy thing to do. It takes a ton of work to write truly good, effective, and useful blog entries. Most people don’t even want to write things outside of the things they have to. Expecting an advocate to evangelize via blog posts and written word, with expectations around numerous blog posts as if it takes no effort is dangerous and sets an extremely bad precedent. but there it is, often in job descriptions and sometimes even with absurd requirements like; “write 4–6 blog entries per month on programming topics deep diving into X”.
Reality: There is no way anybody is going to deliver 4–6 blog entries while travelling, coding, contributing, and more. That’s just complete, utter, nonsense that is completely out of touch with reality. If you’re looking for a developer advocate or technical evangelist don’t put such notions in the post, it’s a massive red flag that says, “unrealistic expectations, stay away”. In all seriousness, if an advocate or evangelist writes a solid blog entry with code, repository, and other elements that actually work, they’d be lucky to get 1–2 blog entries of this level per month mixed with all the other things to stay relevant. To summarize, blog entries are a ridiculous amount of work, editing, and effort to do well.
Solution: Want to read and see the rhythm of really well done articles and tech material, give the Codeship or Digital Ocean blogs a read. The best thing is to have writing as a peripheral element that can be used in multiple ways. Write documentation, have someone mold that into a useful blog entry. Then flip it around and make blog entries into documentation. Whatever the case make it so that there is multiple people working to fold ideas and thoughts into blog material. Individuals slammed with all the blogging almost never works out, and if it appears to work out, it’s probably decimating other important activities.
Perception: We’ll line you up with plenty of speaking opportunities (says super hip and awesome company) and then you just show up and use your personality to present the technology we build! It’ll be super easy!
Reality: Oh hell no! Don’t sign up advocates and evangelists to speak. Otherwise you don’t have an advocate or evangelist, you have some mutant shill infomercial salesperson (I mean, unless I suppose you want a sham wow)! Hire a salesperson, or infomercial spokesperson if you need that, don’t conflate a technical advocate for this role! That’s not going to build honest, high integrity, positive reputation or brand recognition for the company or the individual. This is a lose lose practice to presenting at conferences, meetups, and related events.
Solution: Advocates, or evangelists need to be actively involved in determining where they travel, where they speak, and what element and aspects of the technology they’re advocating at those presentations. Provide options, suggestions, or even ideas but don’t force these, offer a path for them to determine these efforts. This provides the most effective, authentic, best brand, high integrity, solid, reliable, trustworthy, and most excellent presentations among these roles!
There are certain other things that come up when I’m a contributor on projects with regard to advocates and evangelists. It boils down to a really simple focal point, are they working on, building samples, contributing to projects, and generally helping me get done what I’m trying to build? Whenever I see Google, AWS, Microsoft, HashiCorp, New Relic, other open source projects, companies, or other organizations’ advocates I immediately pay attention when they’re building or working on projects that reflect what is getting done and needs to be done in industry. In the future I intend to research and put together a list of effective practices around these roles from two perspectives; that of the evangelist or advocate and that of the community member working with the evangelist or advocate.
Until later, cheers, and good luck hiring evangelist and advocates! It’s a challenge!