I’m in between jobs after spending 15 years as a developer evangelist.

Last week I lost out on a position for a REST API Developer Evangelist role that I had interviewed for primarily because I lacked in-depth knowledge of a specific PHP API that I had never used.

I’m not going to name the company because I like their product and the well known developer that I interviewed with, but it started me thinking about the role of technical evangelist and how technophiles often confuse the nature of the role and it’s success.

A number of other people with extensive developer evangelism experience have shared with me in the past that they were rejected out of hand for what they believed was a lack of “bit level” experience.

Lets start with understanding what a Technical Evangelist is (and from here on in I’ll be specifically referring to Developer Evangelism). The Technical Evangelist’s role ( for a software vendor as opposed to a consultancy) is to produce two sets of results.

1.) Net New Adoption
2.) Increased Customer Satisfaction & Dependence

Technical Evangelists that represent consulting companies have a bit of a mission. That of presenting the technical expertise of their firm in the hopes of selling its services.

Even technical evangelists that don’t represent a specific company still have the goal of encouraging adoption of the technologies that they evangelise (usually because it’s the one THEY have chosen).

You will often hear Developer Evangelists describe themselves as “Impartial Trusted Advisors”, and becoming “trusted” is a great way for a technical evangelist to increase their influence but in actuality, there is no such thing as a truly “impartial” technical advisor.

So this bears the question, what does it take to be a really successful Technical Evangelist and how does that translate to a really valuable technical evangelism program?

Sure, a technical evangelist need a strong technical acumen. When I joined Microsoft to do Technical Evangelism for .NET it was an unreleased product. I’d played with it for about a week before I started the interview process at Microsoft. When I joined Mozilla to catalyze HTML5 App Evangelism I was far from a client side expert. After all, one of the fundamental tenants of ASP.NET (before MVC and Razor) was that you didn’t do client side work. It was all drag and drop.

So in taking various evangelism roles that focused on technologies in which I was not omnipotent, how did I succeed?

The dictionary includes a definition of an evangelist as : “a zealous advocate of a cause”.

This is true of Technical Advocates as well.

Remember that I suggested the primary goals of a technical evangelist are to deliver “net new” adoption and increased user (customer) satisfaction.

The technical evangelist has secondary goals as well, like product feedback, support costs reduction, customer specific problem solving, direct sales opportunity support, etc. and some of those can be facilitated by low level expertise, but in general – bits and bytes hacking is of secondary value.

I mean, once you have written a for loop, they are pretty much in the same whether you’re writing C#, PHP,JavaScript, Python, etc.

I suggest that you don’t think about Technical Evangelism as “here’s what my product can do”, but rather “look what you can do with my product”. It may sound like a semantic nuance at first blush, but it’s not.

Let me share a couple of examples.

In 2001 when I started working to drive ASP.NET adoption (.NET was in Beta havng been previewd at the 2000 PDC) I focused on Web Services. The big deal about Web Services was not the technical details of building or calling a service in ASP.NET becuase ASP.NET and Visual Studio made the syntax pretty much the same as working with any .NET object.

What resonated most with the (literally) thousands of developers I presented .NET to was not the new / diferent ways they could do things with Microsoft’s shiny new technology, it was how the simplicity of .NET would let them change the KIND of development they could do. How they could build features and applications that were impractical or impossible with earlier tool sets.

In 2008 we (Microsoft) released the ASP.NET AJAX extensions and the initial uptake from developers was “different” than we expected. The reason, I felt, was that while we were showing developers “how” to use the new “APIs”, we weren’t really doing anything to help change their thought process in regards to ASP.NET based problem solving.

After all, ASP.NET developers weren’t used to thinking in terms of how world wide web apps really work, their model at the time was really designed to emulate the “client server” paradigm. The idea that an application could have functionality apart from “full server round trips” was foreign.

So I built a series of 30 or 40 concise videos with sample code that demonstrated “AJAX Patterns”. Patterns like “Predictive Fetch” , “Partial Page Updates”, “Display Paging”, “Incremental Display”, “After Processing” and “Persistent Communications” (http://www.asp.net/web-forms/videos/aspnet-ajax). What mad people excited was not new ways to do old things, it was NEW THINGS that could do in general.

The right content, demonstrations and sample code made people say “I need to move to .NET because I can easily build great apps (or great features into my apps) with that tool set.

While some amount of technical expertise was prerequisite, it wasn’t a deep expertise that made the evangelists on my team successful. To the contrary, I think only a couple of the folks on my team of a dozen or so ever developed really deep expertise. What made them great technical evangelists was their mix of technical aptitude and exceptional communication skills.

As a team we learned to answer the questions prospective customers had, even if they were as yet unasked. We learned to match customers needs with the capabilities that our products could provide and we learned to “shorten” the learning curve by creating content and giving presentations made complex problems and solutions simpler – rather than getting lost in the weeds of technical minuta.

So (IMO) Technical Developer Evangelists are …..

– Engaging speakers and recruiters
– Pre Sales Engineers
– Post Sales Support Engineers
– Solutions Consultants
– Cheerleaders
– Coaches
– Social Directors
– Authors
– Organizers
– Managers (or events or projects)
– Applications Developers

Have you even met great developer evangelist ?

What made him or her great in your eyes ?