02 Aug 2015, 17:01

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.

05 Jun 2015, 17:13

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!