This blogpost was originally published on my DevRel Medium blog.

Back in November 2017 I moved from full time software engineering work and started working as a developer evangelist. As this was just about a year ago, I decided to write this post as a retrospective of sorts on how I’ve come to see and understand the field of developer relations.

My work falls under the umbrella of developer relations — DevRel. This has come to cover many types of work with one major thing in common — working with external developer communities, enabling them, and bridging the gap between the “outside” and the “inside” developer worlds.

Professional enablement

I have come to understand DevRel and my work as all about enablement of developer communities. Enablement, as in — my output is making other people better.

I’ve come to find parallels between DevRel kind of enablement of external developer communities, and the “regular” technical leadership — the main difference is only the audience. Instead of enabling a small internal team to always improve be better, the “teams” we enable as DevRels are entire communities. The personal touch is not necessarily gone, I see it just more distributed across more people.

We sometimes use different tools, and some tools we use in different ways than before, but the core objective of enabling people is the same.

For example, as a DevRel I review a lot fewer pull requests on GitHub than I used to as a developer, yet on the other hand I create many more repositories with sample code and prototypes. GitHub — the tool is the same, yet the patterns are different. 🛠

Throwing stuff at the wall and seeing if it sticks

Open source, code samples, and prototypes are only one aspect of my work. Besides that I also write, speak, or work on larger projects or initiatives — mostly associated with brand awareness.

Figuring out what activities to focus on is pretty much a trial and error process. Come up with an idea for a project or activity, develop it, get some feedback, iterate and release it, or go and experiment with something else.

This year I did larger initiatives like the State of Kotlin survey and the DEV contest, that had me writing, speaking about, and project managing various aspects of the projects. These were the successful bigger projects, but on the other hand I also worked on some initiatives that didn’t really see the light of day.

We either decided to change course or decided the things weren’t worth doing at that time or in that situation. Changing course or dropping a project is just a nature of the work. ♻️

That “glamorous” jet-setting lifestyle 🕺🏻

Throughout the year I also spoke at a few events or conferences across Europe and the US. Some of it supporting State of Kotlin, and some of it other developer content. By my count I did some 15 events this year — between conferences and meetups, a lot of which required some form of air travel.

As much as I love speaking, hanging out with developer communities everywhere, and adore easyJet’s lack of legroom, I can’t shake the fact that this activity doesn’t scale for me. I alone cannot be at enough events to cover substantial ground and make meaningful impact.
Conferences tend to happen in “seasons” — with a lot of events clustering in the spring season between March and May, and the autumn season between September and November. Even having just a few speaking engagements can mean being away for a large part of a month.

The glamorous nature of DevRel travel is something along the lines of: plane, hotel, speaker dinner, 2 days of conference, plane. There is very little room to actually see the places you travel to outside of the conference venue, hotel room, and the airport lounge.

I would sometimes try to extend my trip with meetings with local communities — especially when flying long distance here jetlag is a thing, and there are substantial tech clusters in town, but more often than not I’m just in and out. In addition to everything I’ve mentioned, another downside of travel is that it can be damn tiring, traveling a lot can make you seriously prone to burnout which is bad. Very bad.

As my focus has been on other projects, I’ve seen conferencing as a nice to have, rather than a must-have. I feel that I’ve overdone it a bit this year, and in 2019 I’ll reduce my conferencing. Play to your strenghts, I guess.

I got quite good at packing though. 🧳💪

It’s only marketing (but I like it)

Pusher’s DevRel falls under Marketing. There’s been a lot of debate of where DevRel should sit within an org, and I personally believe that it doesn’t matter that much at all — or better, there are other factors much more important than the org chart.

On a daily basis I help and advise my colleagues on the best ways to interact with developer communities. I spread brand awareness through projects. We get stuff built. It works. 🚀

I also help our engineering and product teams with Android and mobile advice, by giving feedback on the APIs and the docs I’m playing around with, and also by having my ears to the ground in the communities I am part of. Same goes for Support and Sales — dotted lines everywhere.

Working within marketing has exposed me to a whole new skillset and way of thinking. Something I don’t think would have learned to appreciate enough if I stayed in engineering. 📊

DevReling solo

Inside the bigger marketing team, I work in a team of me, as the only DevRel in the company.
Would I love to have more DevRels to brainstorm with? Of course.
Is it a deal breaker? Not really.
Is it a strange thing to have DevRel team of one? No — many teams are like it, although large teams are becoming more and more common for larger orgs, the prime example being Microsoft.

Having no immediate team this forces me to talk to and be closer to people from not only my own department — getting the aforementioned dotted lines to work.

And the support network? The DevRel community is my team. There’s a Slack channel, meetups, conferences, and there are people I can meet up with pretty much wherever I happen to find myself.

You’re never really alone in DevRel. 🍀

The 🥑 tribe

Many DevRel folks have started adopting the avocado name and the avocado 🥑 emoji in their online profiles to describe their work. I believe it was this post by Mary Thengvall that started it all — Developer Avocados: The Good Kind Of Fat.

Starting from there, we’ve come to fully embrace the 🥑 banner, and there are now several Twitter lists, like this one from Quintessence Anx, as well as regular posts of avocado themed swag and gadgets floating around. Call it an internal joke, a secret handshake for the age of Twitter.

The DevRel community is fantastic, and definitely one of the most welcoming communities I’ve had the pleasure of being part of — if not the most welcoming one.
Something something folks who help other folks for a living tend to be nice folks. ✨

Onwards and upwards

And what’s waiting for me in 2019?

The main thing would be focus. In this year I’ve tried to cover every product we have. We started off with one product, and added two more throughout the year. In 2019 I will cover less ground and focus more on a single product.

I am not quite sure yet what specific activities I am going to be doing, but I imagine it’ll be integrated across various channels — be it written, spoken, recorded, with the emphasis on scaling the impact. I have high hopes for video as a channel. I’ll also be giving fewer talks — but most likely around 5 in the whole year. Not a zero, but way less.

Onwards and upwards, it’s going to be exciting 🚀.

Resources

DevRel Collective community — https://devrelcollective.fun/

Business Value of Developer Relations, book by Mary Thengvall: https://www.amazon.co.uk/Business-Value-Developer-Relations-Communities/dp/1484237471/

DevRel Avocados, Twitter list by Quintessence Anx: https://twitter.com/QuintessenceAnx/lists/avocados/members

Sympathy for the DevRel, talk by James Governor: https://redmonk.com/jgovernor/2018/11/23/sympathy-for-the-devrel/