Devangelism: Finding My Feet - Part 2

At the beginning of June I wrote part one of 'Devangelism: Finding My Feet'. This post is the follow up of my experiences as a Developer Evangelist at Esri UK over the past ten months or so. The article is a continuation of the previous post, touching on a few things I have learned and feel may be pertinent for other people undertaking a roll in developer relations. Hopefully if you're new or interested in developer evangelism you'll find something of value in reading it. I am always open to feedback, so let me know if there's anything you want to comment on or discuss. So, without further ado...

6. Don't Go it Alone

It is common for developer evangelism teams to be small, in sometimes (like my own) to be singular. I'm very fortunate in that I have colleagues around who are able to aid me if necessary, but I can imagine that not everyone has the same support network. I was lucky to come across multiple evangelists throughout the day job; partly through events and partly through the London Technical Evangelist meetup group. Speaking to evangelists/advocates who'd been doing the job for a lot longer than myself certainly helped. There are multiple reasons why I think this was useful but the main points for me were avoiding unnecessary mistakes, learning about other's techniques and metrics, and finally getting my head around what I should even be doing.

There have been a few conversations that have stood out to me were along the way. Starting chronologically, my first bit of dev relations beginners wisdom came from chatting with Eddie Zaneski (SendGrid) at OxHACK. Eddie has boundless enthusiasm, and handed out a lot of advice, if something isn't getting done or sorted, sometimes you just have to take initiative. Another conversation was with Phil Leggetter (Pusher) at API London about metrics and what's effective (a topic I've come to realise is pretty hot in developer relations at the moment). Lastly, having sushi with Chris Traganos (Evernote) when I was in San Francisco and discussing the pros and cons of various methodologies, in particular webinars and learning about what had worked for him. Acquiring knowledge and wisdom from people who had a few years experience has been invaluable.

Another aspect of this is the ability to partner up with others for events. For example I was keen to run a hackathon, but I didn't really know if I could do the whole thing by myself. Luckily I ran into Rod Burns (Inmarsat) are now we are running one together in September (GeoHackDay). This is something that just wouldn't have been feasible on my own.

7. Stop, Collaborate and Listen

Hacks that use your APIs at hackathons often won't necessarily materialise into anything after the hackathon is over. Hacks are generally somewhat ephemeral; which is cool, a lot of the time that's the point of a hack. It gives people have a chance to play and explore new technologies. Having said this, there is sometimes opportunity to make more out of the project after the event. Why not offer to help the team produce a blog post about their work and help promote it on your networks? This is a mutually beneficial venture; you help someone write a great post about their hack, you and your company hopefully gain a little more exposure for your API. Without wanting to sound too corporate the company you work for has no doubt already invested heavily in the event, why not try make as much as possible from it? Especially if it's in a way that builds relationships and helps people expose their hard work.

8. Never Stop Writing Code

It's really easy to get bogged down in emails and admin. I think it's really valuable to stay active on development projects, whether that be work related, side projects or a combination of the two. I know the majority of evangelists efforts are generally focused on working demos, potentially SDKs, but generally less on larger problems. I think this is generally OK, but it's important to bear in mind the disparity between how you might be using your APIs and how external developers are using them.

One thing I've also seen value in is working with emerging technology as they can make for more interesting material for talks. For example a few months ago I was working with Polymer (0.5) to build some Esri web components (maps, layers and so forth). This made for great talking material as it was topical but also provided a good platform to demonstrate and explain some cool aspects of Esri tech, especially with the release of the Polymer 1.0 and the experience of transferring that project over.

9. Get Stuck In and Follow Up After

At hackathons, it's really easy to just focus on the people who are using your company's technology. What I've come to realise there's so much to be said for helping people regardless of what they're working on. People will remember the feeling when you helped them get there hack working with 30 minutes to go. Similarly, if you can spare the extra couple hours in the evening after you're expected to stay (to reside back to the hotel) then again, people will appreciate your effort. That being said, don't beat yourself up if can't due to other commitments; just be present when you're present.

After it's all over if people show interest in your tools or make an awesome job of using them, follow up can be really key in retaining that person as an advocate and user of your API going forward. Using tools like Evernote, Todoist and Outlook Tasks have really kept me in check with regards to follow up and maintaining good relations with people. Above all else genuineness and willingness to help others will shine both at events and in follow-up.

10. Pick Your Strengths

One thing I've come to realise is that it's a dark and dangerous road trying to learn every language, framework and technology. It's just not sustainable. Instead I've found benefit from picking a few things that interest me and focusing my time on those. In my case that was that I am predominantly a web developer and I find WebGL and web components interesting. If you're an iOS developer at heart, don't try and wing a talk on Android development; it will become quickly obvious especially when people start asking questions. This being said I can certainly see benefit on having a surface level knowledge of many different technologies. For example (from a web development perspective), understanding the basics of Angular, Ember, and React etc. without having to know those frameworks inside out. This will make your conversations a lot easier due to the vast number of people will meet along the road. In other words, it seems that a T-shaped knowledge of the industry is probably one of your safest bets.

Bonus: You can't do Everything

The burnout is real. Be selective and focused on what you decide to invest your time in. I learned very quickly that you will swiftly become jaded and disappointed if you try and get to every event going. Instead hand pick your events. You may find it beneficial to focus on events where you have a platform i.e. talking, sponsored events, workshops etc. This was especially true in my case as I am unfortunately in living quite far from the tech hubs of the UK. It takes me over an hour to get into London, then perhaps another 20-30 minutes to get to the venue. Trying to get to every possible meetup on the tech calendar was just not realistic. Pick and choose what you invest your time in, and when you do go, go prepared and leave ready to act on the outcomes.

Published 02 Aug 2015