#developer evangelist

[geniodiabolico]

Dream Job

This is part of me literally being on the clock

Also on:

[manfredbo]

The job of a developer evangelist

At the Over-the-Air developer event in Betchley, UK (this is where they cracked the Enigma), I gave an Ignite Talk about the job of a developer evangelist.

I wrote about that event in my earlier post "Ignite Talk at Over the Air". Now the guys from Over-the-Air published a video of all the Ignite Talks. Please fined that embedded below.

You can read up more details about the Onion model in the "Developer evangelists and onions" post.

My talk starts at timestamp 37m 46s.

[manfredbo]

Ignite Talk at Over-the-Air (Bletchley Park)

I gave an Ignite Talk at the Over-the-Air event in Bletchley Park. Ignite Talks have a really interesting format: exactly 20 slides in exactly 5 minutes. Slides advance after exactly 15 seconds; so you have to be really concise.

I talked about developer evangelists best practices, which I summarise in my Onion model.

Please find my slides embedded below. These slides alone are not too useful if you did not attend my talk. That is why I paraphrase the narrative below.

  During this Ignite Talk here at Over-the-Air 2013 I would like to talk about Developer Evangelists and Onions. For the last 3 years I have been working as a developer evangelist and I would like to share some best practises which I summarise in the Onion model.

  So, to start with, what is a developer evangelist, actually? According to the Greeks, “evangelism” means “bringing the good news” – and indeed an evangelist’s job is to bring good news or in other words convey some useful stuff to her/his audience.

  As a sort of a definition I recently said to someone very crudely that “an evangelist is a technology person trapped in a marketing person’s body.” This is probably not too far from reality – but what certainly is reality is that this role of developer evangelists is very new; and especially with the increasing popularity of public APIs it is also very much sought after.

  The specialty of this role is that it is very diverse. An evangelist either covers or interacts with many other roles, such as development, marketing, product management, PR, support, or sales.

  In order to achieve this, an evangelist ideally has a very diverse skill-set. The first and most important skill – if you can call that a skill – is passion. Secondly, coding – as a developer evangelist you must lever lose touch to code. Furthermore, you should have a strong web presence or at least know how to use it. Public speaking is certainly a large part of an evangelists work. Communication skills in a broader sense which also includes social media platforms; and finally networking in the virtual as well as in the real world.

  Over the last 3 years I collected some best practices which I combined into the Onion model.

  At the core of this Onion or at an evangelist’s work are three pillars: The first one is events. Certainly this is the bread and butter of an evangelists work. You have to be present at events, or give talks, or organise your own events (developer days, hack events, trainings).

  The second pillar is communication, which can be “classic” means such as RSS or email newsletters but also and probably more importantly social media communication such as twitter or Youtube channels.

  The third pillar is content creation. This subsumes creating sample code, tutorials or Getting Started guides. Make these resources available for free and very easily accessible.

  The 3 pillars have a foundation which I call “sensing the market.” It is crucial to understand what are the pains and potential gains of your community and then feed this back into your work.

  At the top we have “acceleration.” You are never alone in your ecosystem but you usually have a partner network which you can leverage to accelerate the spreading of your message.

  This is the core of the Onion model. The second ring of the onion is pilot partner engagement which is beneficial for 2 reasons: First, pilot partners can give you a very early, quick and honest feedback about your APIs or software products which you can use to improve. Second, if you have a successful pilot partner project, you can use that as a show case. This leads me to the third and last ring of the Onion which is about general awareness activities. This is the area where you work with PR people or agencies to spread the word in a more general aspect to a more general public audience.

  To conclude, the job of an evangelist is certainly very diverse and challenging. But if you have a great product – a DICEE product as Kawasaki called it -- it is a hell of a lot of fun too.

  Developer evangelists are high in demand. Also, because the job is so diverse there are many different flavours. You don’t need to be excellent at everything. Focus on your talents and do what you love doing.

  (Thanks, Sam, for the pic of me in action.)

Find more details about the Onion model specifically at my earlier post "Developer Evangelists and Onions." 

[manfredbo]

Developer evangelists and onions

I wrote about what a developer evangelist is and about the purpose of an API strategy within which the developer evangelist plays a crucial role. Over the last two years I developed a developer evangelist model which I would like to describe here. Feel free to comment, criticize, re-use, or extend it. The beauty of this model is that it summarizes some of the most important types of activities of an evangelist and it is scalable. The model can be applied to a one-man-band evangelist as well as to a team of evangelists.

Here is how it works. The following figure shows the three main pillars at its core.

The three main pillars explained:

Events: As an evangelist you need to be present, at events, physically. These can be large developer conferences, developer days, barcamps, hackathons, workshops, or trainings. The difference between a developer day (e.g., bada developer day) and conference (e.g., API Strategy) is that a developer day is usually organized by one company or ecosystem player, whereas a conference is usually broader and covers more diverse topics. The physical presence is very important to be tangible by your audience and to add the personal touch to your product, which increases trust. It also helps tremendously in getting a better understanding of the real needs and pain points of developers.

Communication: Apart from physical presence a developer evangelist needs to be present in the virtual space and communicate. These can be ‘classical’ means such as an email newsletter or RSS, or social media such as blogs, twitter, facebook, or a Youtube channel. Ideally you segment your developers and provide relevant communication to each segment. In marketing-speak that is the segmenting—targeting—positioning process. I wrote about developer segmentation earlier, which may help. Finally, you want to let the community solve problems between its members. An open forum is a good means to achieve that. You could also outsource this to thrid parties such as StackOverflow like Netflix did.

Content: This is really the meat of the work of an evangelist. The quantity and even more important the quality of the produced content needs to be excellent. Relevant content in this regard are API reference documentation, simple getting started and how-to guides, sample code and open-source apps, app galleries (for inspirational food for thought), sandboxes or API consoles. Here is Apigee’s example of Twitter’s API console.

A very important maxim is simplicity. Developers have no time, so it must be crystal-clear what’s the benefit of your API or product and it must be dead-simple and quick to adopt. There is Pamela Fox’ notion of developer experience, which is a great guideline to follow.

In addition to the three pillars, we have a foundation and a top.

The foundation in my model is the constant sensing of the market or your community. That is achieved implicitly by being present in your community physically and virtually – as mentioned above – with open ears and eyes. But it should be enriched by explicit means to get a better understanding of the pains and potential gains of developers. Means can be online questionnaires, expert interviews, or focus groups, or a combination of these. I recently conducted a perceived-use value (PUV) analysis of an API program, where I combined expert interviews to identify new opportunities (features or services) with an online questionnaire to quantify these opportunities. The outcome was very insightful.

Sensing the market is very important to see on the one hand the impact of your work but on the other hand also to understand where the market is moving to, to spot opportunities and exploit them – e.g., by reporting insights to product development.

I call the top acceleration. You are not alone. Usually you work in a network of vendors and partners. These partners often have their own content distribution and communication networks and means. By working together mutually beneficial acceleration can be achieved. With the emergence of open APIs chances are increasing that your partners have API or developer programs themselves which can be leveraged.  

Finally, here is why it is called "Onion" model. What I described so far is only the inner core. There are two more layers.

The second layer around the core is about pilot partner engagement. These are usually early adopters who you work very closely with to adopt your technology. This is hard work and very manual because you want to provide a very careful and personal support. Getting pilots live has two main advantages: First, you get great feedback about your technology deployed in a real life setting and you can improve it accordingly. Second, you can use a successful pilot as a case study example and for general promotion and awareness activities.

This leads then to the final ring in the Onion, which is about general awareness activities. This is pretty much using classic advertising, promotion and PR means to spread the word about your product. This targets more at the general public and less at developers directly. It is advisable to work closely with PR and marketing people or departments of your company.

As indicated by the arrow in the figure above pointing from the center outwards, the activities encapsulated by the Onion are less regionally focussed the more you move outwards. Events and communication can be very targeted and regional whereas general public PR is very broad and less regional.

  Deploying several Onions

I mentioned at the beginning that the Onion is scalable. It is also adaptable. Ideally you would adapt the Onion to the particular segments. As an example consider the following scenario: you have two main categories you want to serve: big-head and long-tail developers (using Chris Anderson’s notion (see “The Long Tail”)). I call it ‘categories’ because for segments this classification is too rough. Secondly, you provide your APIs using two different access technologies: SOAP and REST. You can construct a matrix like the one shown in the figure below.

This matrix gives us four areas we need to cover with evangelist activities.

Let’s assume we don’t offer SOAP for the long-tail category (too much overhead, not popular, no adoption). Hence, there is no Onion in the fourth quadrant. We do provide REST for the long-tail, and in order to reach out to developers we deploy the whole onion except we don’t offer a pilot program for long-tail developers (second quadrant). On the other hand we do provide a pilot partner program for big-head developers, which are usually bigger brands but don’t do general awareness activities for this category (most of the work is done via direct work with leads) (see first and third quadrant). Finally, you can spot that in the first quadrant the content pillar is empty. We don’t specifically provide REST technology content for big-heads but refer to the content developed for long-tails.

This example should show how you can scale and adapt the Onion and deploy various of them customized for your developer segments.

  Key take-away:

As Chris Heilmann wrote in his Developer Evangelist Handbook -- which I also described in the post “What is a developer evangelist” -- the work of a developer evangelist is very diverse and so is the skillset. With the Onion model I try to bring this into a picture to structure this and to bring it in relation to each other. The Onion should also help to focus and prioritize and it will also show you which activities you need to do more of for which developer segment. Finally, it should also help in scaling your work, for instance, if you need to build an evangelist team and if you need to identify the skills you need to look out for.

[manfredbo]

The evangelist and corporate structures

In an earlier post, I described the traits and skillset of a developer evangelist. To be effective, however, it is not just up to the evangelist's characteristics but also very much to the corporate environment and structures s/he is embedded in.

Many larger and/or more traditional organisations have a hard time to really understand what an evangelist is and what s/he requires. (I can tell, I worked as evangelist for Samsung).

First and foremost, an evangelist is not (only) a developer, not (only) a marketer, and definitely not a sales person. But a bit of everything. An evangelist needs corporate structures that allow access to different people from different units such as technical, product development, support, documentation, training, marketing, and sales.

Furthermore, the evangelist needs a large degree of freedom. Micro-management is totally not appropriate. Remember, the basic assumption is that the evangelist is very passionate about the company's technology or API in the first place. Tight control is not necessary -- on the contrary it is frustrating and will make the evangelist leave sooner or later. The evangelist has the best overview and understanding to judge which activities are necessary in her context.

Related to this is also the 'freedom of speech.' Evangelists are the public face (facing developers). S/he needs a large degree of freedom what to say when and to whom. Communication (formal, informal, at conferences, hackathons or virtually via social media) is probably the evangelist's most important task. Complex and length approval process -- or heaven forbid a pre-defined tweeting roadmap -- are not purposeful.

A company (as one example) who really gets it is Apigee. I have several friends there and they understand the job of a developer evangelist. Here is what I found in one of their developer evangelist job posts:

...You’re often given a rigid company pitch & told to hammer it at as many sponsored opportunities as possible, asked to “leverage your existing online following” and are left with no time to code. Instead of pitchmen, we want our evangelists to be educators — finding cool technologies & use cases from inside & outside Apigee, learning from them & the people that build them and sharing the results with the world.

There will still be a lot of travel, a lot of cool people to meet, and lots of time in the spotlight, but our only aspiration for this position is to give you the freedom to show the world how passionate you are about apps, APIs & data...

Sounds good !

My key message with this post is that an evangelist cannot successfully execute her magic if the support is not given by the organisation accordingly.

[manfredbo]

The Art of Persuasion

Developer evangelism has a lot to do with persuasion (among others). Unfortunately, persuasion has a negative connotation. I enjoyed reading some of the works of Robert Cialdini. I provide a summary about how a developer evangelist could leverage that at the bottom of this post.

Cialdini claims that if persuasion is practised in “the right way” it will lead to the benefit of all involved parties. However, “deceptive or coercive use of the principles” of persuasion to trick someone is not just ethically wrong but pragmatically wrongheaded (very short-term tactic). Cialdini describes six persuasion principles, which I found very interesting and benefits can be deducted for an evangelists work.

Here is the theory: 1. Principle of 'liking' People like those who like them. People appreciate similarities (cf, attendees of Tupperware parties have very similar interests) and genuine praise. It is a good practise to establish a bond as soon as possible (goodwill and trustworthiness). 2. Principle of 'reciprocity' People repay in kind. Try to foster positive attitudes and productive personal attitudes. Lead by example. Be helpful. 3. Principle of 'social proof' People follow the lead of similar others (“peer power”). If my peers do it, I can do it (social pressure). A tactic can be to find allies or strong influencers within a group. 4. Principle of 'consistency' People align with their clear commitments once they made them. Try to get those commitments in an active way, get them in public, and voluntarily. An example for active could be that people explicitly say or write something. If something is stated in public it has more weight. Voluntary commitment is ideal. Forcing is only a short term tactic. 5. Principle of 'authority' People defer to experts. Thus, expose use expertise where possible, which increases credibility. 6. Principle of 'scarcity' People want more of what they can have less of. Harness the scarcity principle. Exclusive information is more persuasive than widely available data. What could be the key learnings from this for an evangelist?

Similary (‘liking’) is crucial for establishing trust and credibility. Developers will not trust you or even dislike you if it is clear that you are not one of them but merely try to 'sell' them something.

Being approachable and helpful is probably a very good recommendation in general anyway ('reciprocity').

Furthermore, as a developer evangelist you have to be present ('social proof') and active in developer comunities: virtually (blogs, fora, social media channels) but probably even more importantly physically (meetups, hackathons, conferences).

Naturally, a developer evangelist needs to be the expert in a particular niche, which is the product or API you are representing. It goes without saying that you need to know this really well (principle of 'authority').

I am not sure how the 'scarcity' principle can be leveraged as a developer evangelist because usually you try to give away a much as possible. Perhaps exlcusive and hiqh-quality one-on-one support that genuinely produces results for your partner could be one of that case.

There is a great Harvard Business Review article by Cialdini, which summarises these thoughts very nicely.

[manfredbo]

What is a developer evangelist ?

Interestingly the role of a developer evangelist is becoming mainstream. I think this is related to the fact that more and more companies open up their assets and make it accessible through APIs. Now they need someone who can create momentum and trigger adoption of APIs or software technologies. Companies like Amazon, Apigee, Mozilla or Twilio officially recruit 'evangelists.'

The role of a developer evangelist is very versatile. It is probably best comparable to a product manager or sales person (as wrong as this may sound). The difference is that a developer evangelist usually comes from the technical side but needs to understand both: technology as well as marketing/sales. In my view, a developer evangelist is a hard-core marketer targeting a very niche and technical audience and needs to have good social and public speaking skills.

The best evangelist you can get is a person who loves what s/he is doing, is passionate about it and knows her stuff. Knowledge as so often is power. An evangelist is only credible if s/he knows her stuff and can convince with information.

Chris Heilmann is Principal Developer Evangelist at Mozilla and wrote the Developer Evangelist Handbook which certainly is a great start. He also writes that an evangelist needs a broad skillset, such as writing great code, be a good speaker and trainer, understands her audience, is a blogger, or is a good networker. In addition, an evangelist probably needs to travel a lot and be great in time management and personal efficiency.

Realistically it is difficult to cover all of these. A useful advice is to find out where you are really good at and what you love doing and then focus on this. There are various 'flavors' of evangelists. Try to find the right for you and strive for excellence.

Peter Drucker (management thinker and fellow Austrian) said about personal efficiency: "A person can perform only from strength. One cannot build performance on weaknesses."

[leggetter]

The things that hit home to me about this post were: 1. That Evangelism is very much seen as sales and marketing. Whilst I had some idea that was the case when I started my job at Pusher, I still didn't realise quite how much so. Does it have to be like that? 2. The job is hard. Seriously hard. You do a lot of cross discipline things. I mentioned this in my post on [a year as a developer evangelist](http://www.leggetter.co.uk/2012/05/20/a-year-as-a-developer-evangelist.html). 3. Time management is also hard. My experience is a little different to Rob's. I have moments of intensity when I'm traveling. But I have other times when I work from home and have to self motivate. Time management is difficult in both of these cases. During my two weeks in San Francisco I had a brief glimpse at what most weeks must be like for Rob. I'm kind of jealous. 4. "You Can Learn To Schmooze" - I seriously hope so, because I suck at it! In terms of giving talks I'm 100% convinced that practice is absolutely key. 5. "doing something well will always feel magical" - I've had this feeling and it tends to be when I've really helped somebody and they say thanks. It's not that I'm on the lookout for thanks, and I'd be really happy to see customers doing really well. But, when somebody goes out of their way to tweet or write and email it does truly feel magical. Here's an example of what I was most scared of and what I'm most proud of. I've never been a big fan of public speaking but I'm pleased that I've done it a number of times now and that, as Rob says, with practice I'll get better.