Made by
Made by
Saw the job spec didn’t realise i had to do all this… – Futurama Fry
I’ve been spending a lot of time considering what makes someone great for Developer Relations. I’m using this term rather than evangelist, advocate, or “Developer Pope” (thanks Michael Ludden) as I believe regardless of the title we all have the same task lists, similar stakeholders and usually the same communities to communicate with.
I’ve been a Developer Advocate for IBM Watson Data Platform (originally IBM Cloudant) for over two years, and I spent two years prior really wanting to work in Developer Relations. I began asking people already in Developer Relations about their backgrounds and experiences; luckily for me, I ran a little thing called Hackference, and through it had access to a slew of people either just starting or quite well established in this line of work. Pretty much everyone came from a developer background, either professionally or as a hobbyist, and hopped on to the Developer Relations train.
Over the last four years, a lot has changed, except one thing has stayed pretty common and standard across all the job specs and “desired skills” for Developer Relations jobs. When you look at these specifications they usually have these following rough requirements:
Now, in many cases these are still very much needed. But this isn’t everything, and companies that are hiring have been spotting this. I was at DevRelCon recently and Michael Ludden presented this slide which has a nice list of some tasks somebody in Developer Relations may and probably will do (regardless of the title attached)
.@Michael_Ludden the split of developer relations between evangelism & advocacy #DevRelCon pic.twitter.com/7tDDaiODCz
— Mike Elsmore (@ukmadlz) December 7, 2016
But this list, even though more comprehensive than what the majority of job specs state, still doesn’t tell us all those exact qualities that make a great person working in Developer Relations.
In the last two years I’ve seen people coming in to Developer Relations and being fantastic even though they’ve never released production code before. Some of the people I now ask for advice and guidance have come from Technical Writing, or even fresh out of university and have been Developer Relations as a graduate. So what are some of these extra things that don’t appear to be part of the expected.
No matter what you do in Developer Relations you need to be able to empathise with the people trying to use or engage with your product. Either from a technical code point of view or from a problem solving angel, life is a lot easier when you see it from the perspective of the product consumer.
It really helps if you’re a networker. I swear that I spend a good chunk of my time “sign posting” queries from one place to another. This can be on or off line, but if you can’t help directly then being able to redirect to someone that can help is just an awesome feeling. This can be on your product or company, a language, an API or even a community. Rey Bango had a really great slide to describe this:
https://twitter.com/RedRoxProjects/status/806561681602215937
Know your events. A big part of the job is finding communities and events to talk at or engage with. Your product may be really new, or you’re just starting in Developer Relations, so having a grasp of where to go to get started and build a positive reputation is a great start.
Lastly: be a good citizen. Pay it forward, remember that Developer Relations is still pretty new and everyone is still finding ways to do the job. If you need help, ask and people will always try to answer the questions. Another from Rey Bango on this.
https://twitter.com/jesslynnrose/status/806561558654578688
Anyone with an interest in technology and a desire to help can do the above. Anyone can learn the logic of problem solving, and as long as you know where to look for solutions you can be great at Developer Relations. Go forth, and have a wonderful job helping fantastic people achieve some incredible things!