Looking around I am amazed how big the whole “developer evangelism” thing has become since we started it and I wrote the developer evangelism handbook (now updated with a new section on pre-emptive writing). I am also humbled by how many people cite it and mention it to me as a source of inspiration.

I find, however, that there is still a lot of confusion as to what developer evangelists do, and I also find lately that a lot of very obvious marketing and PR messages get sold as developer evangelism.

What we do as developer evangelists

Developer evangelism for me started out of the necessity to have an unbiased, sane voice for developers out there. We don’t sell products, we explain them and let developers make their own decisions about using them. Our main goal is word of mouth and people using the materials we provide. This means first and foremost one thing: being honest and real about what a product does and how it is useful for developers.

We also need to be the spokespeople for developers in our companies. We should know what people use out there and what they want, what excites them and how our products match those needs.

And this is where a skill comes in that can rub people with traditional marketing and PR tasks and skills the wrong way which I call pre-emptive writing.

What is pre-emptive writing?

What I mean by pre-emptive writing is that when you for example blog about a product you do not only praise its usefulness and show what it does for people but you also slip out of your role as a salesperson. Instead think of how you as a developer would read this were you a fan of a competing technology or other products.

Then you include and answer the arguments that you would write as comments to your own post playing that devil’s advocate. Instead of taking the traditional route of not mentioning flaws that might go undetected or obvious similarities to other products you mention them with the arguments that make them interesting for you. For example:

• If your product has a flaw that needs ironing out you mention what can happen and how to recover or fix the issue. You also list the obvious feedback channels people can use should that problem happen to them. As developers we know that stuff breaks – it is ridiculous to claim otherwise and let people find out the hard way
• If your product is very close to a competitor’s you explain that this is the case as the other product is a very useful thing and it wouldn’t make sense to reinvent the wheel if it runs smoothly. You point out the differences and benefits your product has – for example that it ties into a larger set of products or that it is available open source or performs better in a head-to-head comparison. People make these comparisons in any case – if you anticipate and do them in their stead they see that you are one of them and that you are not blinded by your own advertising. If the similarities are very obvious it would make you look like a very uninformed person or not very skilful liar not mentioning them

Why is this important?

Three words: de-trolling your feedback. Right now our jobs can be incredibly frustrating as the feedback we get (and marketing and PR also looks at) is largely polarised. You either have fans praising what you do over the moon or fans of your competitors pointing out that they already did the same and you are catching up.

Of course you also have comments full of vitriol by people who just hate what your company does and want to repeatedly tell you that, but that is a thing you can happily ignore.

By pointing out the obvious pros and cons of your product to people you prevent a lot of obvious hateful or overly excited comments. Yes, this will cut down on the number of comments you will get but it will also start a more interesting conversation.

Another effect of pre-emptive writing is that you don’t have to prepare a counter-statement – you already did that. In a traditional marketing world this is what you do. You don’t say what’s wrong but you prepare a statement for the press when things go wrong. In most cases you prepare this statement after things went wrong with a lot of stress, phone calls and “we need to deal with this now, people are re-tweeting and re-posting the bad messages all over the place”. This is stress we can avoid.

Getting pre-emptive writing out can be tricky as it is against a lot of basic beliefs of sales and marketing. But you are a developer evangelist – this is your job. Pre-emptive writing and constantly questioning your own products makes you one of your audience and keeps you their spokesman – a developer evangelist.

Comment on Facebook, Google+ or LinkedIn.

I am a developer evangelist. I’ve written a handbook about it and I have fought and lived for the role for a long time. I think it is very important for a company to have a person that understands tech and translates it into understandable content for everyone out there. It is also important to have that person to be the mediator between the tech and non-tech people in the company.

I am also my biggest critic – I record all my talks and listen to myself later on cringing when I find things I can improve. This is the reason why I want to ask you for help to make my (and more and more others) job to be more accountable.

Right now being a developer evangelism means you do a lot of good but it is hard to measure what you did. Of course there are low hanging fruit when it comes to measuring the success of talks for example:

• Collecting Tweets right after a talk – which is tricky as they tend to be very polarised – people either hated or loved it
• Number of new contacts (business cards) – I know a few companies that have this as a metric. Seems a bit eighties to me and not meaning much unless you also get some good conversation out of the contacts
• Number of people in the room – might actually be that the other talk in the other track was boring
• Conference feedback forms/speaker rate (and similar sites) – this suffers from the same issue as tweets, really

Other things can also be measured and should be listed as successes:

• Partnership with companies met at conferences – getting free accounts to their services for yours
• Invitations to other speaking gigs – especially hard to get ones
• Connections with other speakers – getting them as judges for own competitions or to come and speak at your office/events

I’ve been speaking with other people in similar roles and the really interesting thing for us is not the immediate numbers but what impact we had. Sadly enough it is really hard to get information about this. Of course it feels good to have people come up to you directly after a talk or training and thank you for what you did, but what I really want to know is what people did with the info I dished out. Therefore it would be super useful to me if you told me about any of the following things:

• How have your used things you learned?
  • Have you given an internal training?
  • Is your team now using this technology or product?
  • Did it help your career (did you start using it and found a new job)?
• Did you re-use some of the material for training or pitching to a client?
• Have you build and released a product differently after the talk/training? This information would be total killer to get!
• Did you join developing an open source product? – did the talk get you out of your 9-5 mentality and make you do something different?
• [your idea here] – in essence I would love to hear how my work has affected you and what you did about it

If we’d get this information it would validate what we do and give us a reason to keep pushing ourselves. Please, share. Thanks!

The best way to tell me about things is by sending a Tweet to @codepo8. You can also contact me on the email in the footer of this blog, or on Facebook. I also hang out on IRC freenode #HTML5 a lot.

Yesterday I spent my evening updating the Developer Evangelism Handbook:

The updates include:

• A new chapter on preparing good slide decks for presentations
• A new, cleaner print version of the book (yes, I battled with Word)

The rest remains the same:

Developer Evangelism is a new kind of role in IT companies. This is the handbook how to be successful in it.

A developer evangelist is a spokesperson, mediator and translator between a company and both its technical staff and outside developers. If you think this would be a good role for you, here’s the developer evangelist handbook which gives you some great tips on how to do this job.

Using the handbook you’ll learn how to:

• Find great web content and promote it.
• Write for the web and create engaging code examples.
• Use the web and the social web to your advantage to reach, research and promote.
• Prepare and deliver great presentations

• Buy Developer Evangelism as a paperback or e-book at Lulu.com.
• Read the whole book for free as an HTML version online at http://developer-evangelism.com
• Download the new chapter as a sample chapter (1.65MB PDF)

Things that made me happy this morning:

• The Developer Evangelist Handbook is going nuts. 10300 hits yesterday, so far 12400 today.
• Amazing photos of naked Obama and unicorns – in case you wondered if the web is sane by now.
• Reconstructing 3D models of cities from Flickr photos is a pretty amazing research/tool/design.
• Proof that the quick brown fox really jumps over the lazy dog%
• CSS Prism is a tool to analyse CSS files and show the colours used in them
• Snook blogged about CSS text rotation and dug up the old IE transitions as a fallback – they are terrible though.
• 100 things our kids may never know about is a cool list of tech nostalgia
• BootXChanger allows you to change the Apple logo when your computer boots up
• Gheat is a pretty cool tool to overlay heatmaps on Google Maps