New Version!

This is the original 2009 version of this handbook and quite a few parts are outdated. There is a new version available at Developer-Advocacy.com if you want to get more up-to-date information

Go to the new version

Remove the brand

One very crucial part to becoming a successful developer evangelist is to remove the brand from your thinking.

Yes, you work for a certain company that builds a lot of products, some of them cool – some of them terrible. The point of developer evangelism is not to get people excited about the brand or the company behind it though.

Instead it is about the products the company releases and even more specifically about getting developers excited about playing with them.

This only works when you are excited about the product. If the department that builds the product fails to get you interested in the product, don't talk about it – instead, work with the department to find the thing that makes it worth while for you. Anything you evangelise should answer one simple question: What is in it for me?

The products you evangelise need to get you excited and you need to know where they are going and who to ask for detailed information about them. If the product has no internal stakeholder or team that is a danger sign.

People working on products are actually not the right people to advocate them – they are far too close to the subject matter to find obvious flaws in the documentation or are fine with overly complex ways of invoking a certain functionality as they are used to them.

Your job is to offer them a way to translate this into easier understandable documentation and examples and challenge their current state of affairs. You do however need them to do a good job so be careful not to burn any bridges by being too critical. People spent a lot of time building what you want to tell the world about and are protective about it.

The real power of removing your brand goggles is that you will be able to work with rather than against the competition.

Work with the competition

As a developer evangelist you have to keep your independence. Yes, you are a specialist in the technologies of your company, but if you are oblivious to the world outside the company and preach a mono-culture you will not get far.

Fact: Your independence and your integrity is your main weapon. If you lost it you are not effective any longer. People should get excited about what you do because they trust your judgment – not because you work for a certain company.

Developers are terribly loyal to solutions and technologies once they are happy with using them. It is very rare to find a developer who is OK with jumping from PHP to Java to Ruby to C# to Python and in between Windows, Unix and Mac.

On the contrary – we do spend a large part of our online time bickering at each other that our favourite language is so much more powerful than anything else. Quite pointless, really, but it shows that developers have passion and passion is a good thing.

The same happens with companies. You get Microsoft fanboys, Google enthusiasts, Yahoo fans, Apple disciples, Adobe followers and they all hardly ever mix without arguing with each other about why their favourite company is the best.

All this means that as soon as you start talking about your brand exclusively the cards are stacked against you – either you'll preach to a choir or get shot down in flames.

You work around that in a few ways:

  • Remain an independent voice – talk about everything that gets you excited regardless of where it came from.
  • Become a specialist in a certain underlying technology or methodologies that all these companies and languages rely on.
  • Keep your finger on the pulse – have a good collection of RSS feeds to go through daily and tell the world about things you found and tried out.

The really fun thing is that every company out there wants to do what you want to achieve – make developers happy using their products. Therefore it is very important that you keep an eye on and in contact with the competition as much as it is important to be aware of what your own company is up to.

Example: A really interesting moment happened last year at the Ajax Experience in Boston. I was part of a panel of JavaScript library developers each representing a certain library. The audience was full of fans of all the different libraries and eager to see a big fight on stage. The first thing we did though was tell the audience that there is no point in comparing and bickering as all libraries want to do the same thing – make browsers behave and JavaScript development more predictable. We even pointed out what we appreciate the most about the other libraries. In the end the audience went home with a much more detailed picture about what each library does better than the other – not from the people building it but from their competition. Everybody won.

Show respect to the competition

You can't be a professional evangelist and bad-mouth the competition at the same time. We all are professionals and work on projects to make the web a better place. Different companies have different approaches and different internal red tape to battle. Pointing out weaknesses of the competition is a cheap shot.

You should also not forget that we are seemingly working in an industry that moves and shakes the world but a lot of this is inflation. The amount of people on the speaking, training and advocating market is very small indeed and whoever you cross will come back to you very soon indeed. Better to work together than to annoy each other.

Showing respect and interest also means that – once you realise that you can trust another – you start sharing ideas, resources, conference opportunities and even give each other sneak previews of things to come. And that gives everybody an advantage and makes our jobs easier.

Acknowledge when the competition is better

This is a hard pill to swallow for a lot of people – especially for marketing departments – but bear with me. If your competition has a better product than yours and people ask you which one is better do admit that this is the case. Whilst this sounds like admitting defeat in reality it shows a few things you can use to your advantage:

  • You come across as someone who appreciates good technology.
  • You come across as someone who does not fear competition but welcomes it.
  • Your competition feels that they've done an amazing job and will look closer at your products in return.
  • You will learn what people love about the competitor's product and can feed that back to your own product team.

Another thing to remember is that the product might be better but for a different audience. What gets developers excited does not necessarily mean mom and dad users can deal with it.

Example: Many people get confused when they see that as somebody who works for Yahoo I have a gmail account as my main email. The reasons are that I had it two years before I started at Yahoo and for me and the amount and kind of emails I get daily it is the right interface. Yahoo Mail, on the other hand is dead easy and feels very natural for people who use Outlook and get more office style emails.

Know about the competition

This is a classic marketing, advertising or even development step: before you build or promote something look around and do a competitive analysis.

In the case of developer evangelism you need to be up to speed with what your peers are up to as you will constantly get questions about it. "How does this compare to X, the new product by Y?" is a very common first question.

If you can answer that, your tech integrity gets quite a boost and – let's face it – it is fun to poke at the things our peers produce.

Build mashups using competitive products

Using the web services of your competitors is a great way to check several things:

  • What do they do well, that could be done better in your company's services?
  • Where do you get stuck? This is something to avoid in your own services.
  • How does it compare to your own services? What are the differences? Remember, these are the questions that people will ask you, and you learn best by doing.
  • How can these services be mixed with your own and how do they compliment each other?

Building something with a brand new API also helps your technological integrity and you can feed back problems you found to your peers in the other company. I've done that with several Google and Microsoft products and actually managed to get to know the right people when I have questions that way.

If you find that a new API by another company compliments one of yours nicely, build a mashup and show that to the world – this will be beneficial for both APIs and people see how easy it is to mix services from various companies.

Next: Work with your own company