Christian Heilmann

Answering some questions about developer evangelism

Friday, February 12th, 2016 at 2:03 pm

I just had a journalist ask me to answer a few questions about developer evangelism and I did so on the train ride. Here are the un-edited answers for your perusal.

In your context, what’s a developer evangelist?

As defined quite some time ago in my handbook (http://developer-evangelism.com/):

“A developer evangelist is a spokesperson, mediator and translator between a company and both its technical staff and outside developers.”

This means first and foremost that you are a technical person who is focused on making your products understandable and maintainable.

This includes writing easy to understand code examples, document and help the engineering staff in your company find its voice and get out of the mindset of building things mostly for themselves.
It also means communicating technical needs and requirements to the non-technical staff and in many cases prevent marketing from over-promising or being too focused on your own products.
As a developer evangelist your job is to have the finger on the pulse of the market. This means you need to know about the competition and general trends as much as what your company can offer. Meshing the two is where you shine.

How did you get to become one?

I ran into the classic wall we have in IT: I’ve been a developer for a long time and advanced in my career to lead developer, department lead and architect. In order to advance further, the only path would have been management and discarding development. This is a big issue we have in our market: we seemingly value technical talent above all but we have no career goals to advance to beyond a certain level. Sooner or later you’d have to become something else. In my case, I used to be a radio journalist before being a developer, so I put the skillsets together and proposed the role of developer evangelist to my company. And that’s how it happened.

What are some of your typical day-to-day duties?

  • Helping product teams write and document good code examples
  • Find, filter, collate and re-distribute relevant news
  • Answer pull requests, triage issues and find new code to re-use and analyse
  • Help phrasing technical responses to problems with our products
  • Keep in contact with influencers and ensure that their requests get answered
  • Coach and mentor colleagues to become better communicators
  • Prepare articles, presentations and demos
  • Conference and travel planning

How often do you code?

As often as I can. Developer Evangelism is a mixture of development and communication. If you don’t build the things you talk about it is very obvious to your audience. You need to be trusted by your technical colleagues to be a good communicator on their behalf, and you can’t be that when all you do is powerpoints and attend meetings. At the same time, you also need to know when not to code and let others shine, giving them your communication skills to get people who don’t understand the technical value of their work to appreciate them more.

What’s the primary benefit enterprises hope to gain by employing developer evangelists?

The main benefit is developer retention and acquisition. Especially in the enterprise it is hard to attract new talent in today’s competitive environment. By showing that you care about your products and that you are committed to giving your technical staff a voice you give prospective hires a future goal that not many companies have for them. Traditional marketing tends to not work well with technical audiences. We have been promised too much too often. People are trusting the voice of people they can relate to. And in the case of a technical audience that is a developer evangelist or advocate (as other companies tend to favour to call it). A secondary benefit is that people start talking about your product on your behalf if they heard about it from someone they trust.

What significant challenges have you met in the course of your developer evangelism?

There is still quite some misunderstanding of the role. Developers keep asking you how much you code, assuming you betrayed the cause and run the danger of becoming yet another marketing shill. Non-technical colleages and management have a hard time measuring your value and expect things to happen very fast. Marketing departments have been very good over the years showing impressive numbers. For a developer evangelist this is tougher as developers hate being measured and don’t want to fill out surveys. The impact of your work is sometimes only obvious weeks or months later. That is an investment that is hard to explain at times. The other big challenge is that companies tend to think of developer evangelism as a new way of marketing and people who used to do that can easily transition into that role by opening a GitHub account. They can’t. It is a technical role and your “street cred” in the developer world is something you need to have earned before you can transition. The same way you keep getting compared to developers and measured by comparing how much code you’ve written. A large part of your job after a while is collecting feedback and measuring the success of your evangelism in terms of technical outcome. You need to show numbers and it is tough to get them as there are only 24 hours in a day.
Another massive issue is that companies expect you to be a massive fan of whatever they do when you are an evangelist there. This is one part, but it is also very important that you are the biggest constructive critic. Your job isn’t to promote a product right or wrong, your job is to challenge your company to build things people want and you can get people excited about without dazzling them.

What significant rewards have you achieved in the course of your developer evangelism?

The biggest win for me is the connections you form and to see people around you grow because you promote them and help them communicate better. One very tangible reward is that you meet exciting people you want to work with and then get a chance to get them hired (which also means a hiring bonus for you).
One main difference I found when transitioning was that when you get the outside excited your own company tends to listen to your input more. As developers we think our code speaks for itself, but seeing that we always get asked to build things we don’t want to should show us that by becoming better communicators we could lead happier lives with more interesting things to create.

What personality traits do you see as being important to being a successful developer evangelist?

You need to be a good communicator. You need to not be arrogant and sure that you and only you can build great things but instead know how to inspire people to work with you and let them take the credit. You need to have a lot of patience and a thick skin. You will get a lot of attacks and you will have to work with misunderstandings and prejudices a lot of times. And you need to be flexible. Things will not always go the way you want to, and you simply can not be publicly grumpy about this. Above all, it is important to be honest and kind. You can’t get away with lies and whilst bad-mouthing the competition will get you immediate results it will tarnish your reputation quickly and burn bridges.

What advice would you give to people who would like to become a developer evangelist?

Start by documenting your work and writing about it. Then get up to speed on your presenting skills. You do that by repetition and by not being afraid of failure. We all hate public speaking, and it is important to get past that fear. Mingle, go to meetups and events and analyse talks and articles of others and see what works for you and is easy for you to repeat and reflect upon. Excitement is the most important part of the job. If you’re not interested, you can’t inspire others.

How do you see the position evolving in the future?

Sooner or later we’ll have to make this an official job term across the market and define the skillset and deliveries better than we do now. Right now there is a boom and far too many people jump on the train and call themselves Developer “Somethings” without being technically savvy in that part of the market at all. There will be a lot of evangelism departments closing down in the nearer future as the honeymoon boom of mobile and apps is over right now. From this we can emerge more focused and cleaner.
A natural way to find evangelists in your company is to support your technical staff to transition into the role. Far too many companies right now try to hire from the outside and get frustrated when the new person is not a runaway success. They can’t be. It is all about trust, not about numbers and advertising.

Share on Mastodon (needs instance)

Share on Twitter

My other work: