Devangelism: Finding My Feet - Part 1

Over the past 8 or so months I've been working full time as a developer evangelist at Esri UK. My role encompasses raising awareness of our developer APIs & SDKs, growing a community around them, and aiding developers make use of them to their full potential. Alongside this I also do startup relations, where I help onboard startups to Esri's Startup Program (free software for three years!).

I work on my own in the program, but I am supported by my fantastic colleagues sitting in the Tech Research department of the company. This also helps as I am constantly surrounded by forward thinking and innovative individuals. In the past 8 months I feel like I've learned a lot. The following post will pick 5 points of things that I feel have been of value to me over this time. They will predominantly revolve around operating as a developer evangelist, as opposed to what I've found effectual for engaging and helping developers (and startups). In my next post I will aim to cover that base.

Every developer evangelist role is different, as different companies have different goals from there programs. As such some of this may not necessarily apply or you may have a different angle on it, but hopefully some of the points may be useful if you've just entered a developer evangelist role. First up...

1. Documenting is Useful

What did you I last Wednesday? How valuable was that hackathon we sponsored 6 weeks ago? These are the kinds of things documentation can help with, and I'm really glad I've decided to keep track of. Alongside my Outlook calendar I keep a SharePoint (sigh) table of attended events with a host of drop down boxes and short boxes to help log events both upcoming and attended. I use it to help spot patterns in the value of events, whether they be attended, sponsored or spoken at (I might write about some of these initial pattern observations in another post). I think this holds additional value if you intend on doing your role long term, or growing your team. You can review last years events to help plan for next years. In addition with this method you might work out early that certain types of events don't really offer any real value.

Measuring event success is hard, but you can generally get a gut feeling afterwards of whether you thought it was worthwhile. You can also attempt to capture some of that gut feeling into qualitative and quantitative information (number of people at your talks, number of attendees at the hackathon, number of hacks with your API etc.).

Alongside event documentation, I also maintain a set of notes using Evernote, a to-do list using Todoist and a busy calendar using Microsoft Outlook. These four tools help me organise my working life. I've found that planning ahead has been invaluable, and getting events, meetings and calls into the diary as early possible allows for adequate preparation, and avoids last minute flurrying around.

2. Use Event Websites to Stay Informed

Event websites help you fill your calendar with relevant meetups, hackathons, and other events, whilst also helping find relevant sponsorship opportunities (if you have budget!). The major ones I keep track of are:

meetup.com
eventhunt.io
eventbrite.co.uk
techcitynews.com/events/ (London Centric)
campus.co/london/en/events (London Centric)

For talks I also used to follow calltospeakers.com but this appears to have stopped updating, which is a shame. You can use the information to figure out if you think the event is of interest or relevant. Also, for ticketed events I recommend getting them as soon as possible, even if you don't go, then you can always cancel later when you've decided.

3. Content is King

One thing I regret is not blogging earlier. Writing is a really great way to firstly compound what you've learned, but also share it with others. If you have written a cool demo, take the extra hour or so it takes to write a blog post about it! It doesn't even necessarily need to be to long, sometimes a working demo, explanation and link to the GitHub can suffice. You can use it as a base point to share with others, and again it helps you to document what you've been doing. If possible try and keep a counter and monitor comments, ratings and shares on your blog posts, this way you can learn quickly what works for you.

4. Start Small, Grow with Confidence

I came into developer evangelism with little to no public speaking skills. By no means am I now an expert, but getting some smaller gigs talking about technology aspects I feel comfortable in has helped me improve dramatically. It is easy to do yourself a disservice by applying to do a large conference with limited experience and surface level understanding of a topic, because 'It feels like what I should be doing'. I have come to realise research and practice are key. Chances are even in a room full of experts if you dig deep enough into the topic you can pull out interesting information they may not know about. If you can combine that with having engaging slides with great delivery, you're onto a winner. I find cloud hosted slides like reveal.js/slides.com are awesome because you can do live web demos without having to switch away into another window. I've also considered joining a toast masters or doing a course, as I've heard good reviews on both (we'll see!).

5. Make Friends, Stay Social

Making friends is great. It's one thing I've come to love about the role; I'm always meeting new and interesting people. The ability to combine technical understanding with making friends is pretty much my dream job. I was never really into Twitter before hand but I've come to realise it's a really powerful tool for maintaining relationships, learning and sharing thoughts. We can now interact with people, including strangers, all over the world in a matter of moments. It also appears haunt of choice for developer interweb socialisation, so that's where I've chosen to focus most of my efforts. I find TweetDeck a really useful way to stay on top of everything on Twitter, including multiple accounts (I run the @EsriUKGeoDev account too).

I also make a modest effort to maintain a LinkedIn profile, but I've yet to see much benefit from it, and it has a bit of a stigma around the developer community for being crowded with annoying recruiters. Esri UK is a enterprise oriented company so for me it makes a little more sense to remain active, especially since many GIS professionals dabble in development (the GIS scene is arguably not so active in the Twittersphere). In addition I see no harm in sharing content and staying connected on the platform so I imagine I'll keep it up.

Going back to Twitter, I've tried to avoid becoming a walking advert for the ArcGIS APIs, and I've attempted to stay as human as possible. I know I wouldn't want to follow a boring API tweetbot, so that's something I try to avoid being myself. Indeed the best responses and interactions occur from either funny, thought provoking or interesting content, not from API change logs updates. I would recommend to not be shy, to stay active, but also to stay away from flame wars or negative tweets; it won't bode well and it's a waste of time.

Bonus

Along the way I've picked up a lot of really useful information from other people. In all honesty I came into the role not fully understanding how to 'be' a developer evangelist. I found these sites useful in finding my feet:

Thanks for reading, I'll be following up with less generic operating lessons and more 'on the ground' evangelism thoughts in my second post. I am also keen to write a response to Rey's post in my third part, so stay tuned for that. If you have any thoughts on any of the points raised I'd be really interested to hear!

Published