And by a developer advocate I mostly mean myself, since all of us have slightly different approaches based on our backgrounds and region. This includes having advocates in China, Japan, South Korea, or France for more than four years to foster local communities and plant the seeds that you can maybe harvest later, which I find a lovely metaphor for our job.

My personal goal is successful users. That is mostly around education (what is possible, how have best practices evolved, what are common problems, and how can they be solved) and helping them solve their problems. Only when people are successful with your product, they’ll spread the word and potentially become customers. That is a natural extension of their success and not something I would or should be pushing. Otherwise, your perception will switch to sales very quickly, and that isn’t a win for the position.

Generally, I’m good at keeping myself entertained. While we have shared goals and visions, a lot is up to each one of us. This can be both great and terrifying. Depending on your mindset. it gives you all the freedom to pick up relevant and interesting opportunities as you go along, or you’re constantly questioning if you’re doing the right thing. I’m definitely in the great camp — also because:

It’s easier to ask forgiveness than it is to get permission. – https://en.wikiquote.org/wiki/Grace_Hopper

Events #

Probably my main activity is speaking at conferences and meetups (no paid slots though) as well as creating talks and demos for them. And sharing materials with colleagues — either slides or providing demo instances, for example, with Strigo. In the past years, I have consistently spoken at 100+ events and traveled more than 200 days, but I’m generally sticking to the EMEA region — from Ireland over the Nordics to Russia and Isreal plus down to South Africa. On top of the content side, this involves a lot of travel arrangements and coordination.

Speaking also includes demos at interested companies. Those are often called lunch & learn or brown bag lunch (BBL), which are particularly common in France where my colleague David is our master of BBLs or Aravind in India.

In Vienna, I’m running the Elastic Vienna, ViennaDB, and Papers We Love Vienna meetup groups. Not all of them are strictly work-related, but they do fit the general ecosystem and broaden views as well as contacts.

On top of that, I do a couple of Elastic trainings per year. And we’re getting more into webinars and virtual meetups now as well, both to scale and because of the current health situation.

Solving Problems #

If you’re asking a (technical) question on the @elastic Twitter account there is a high chance that I’ll be answering. Hopefully — with — a — good — solution — or — two — (or more).

On a related note, trust and integrity goes a long way in the bigger picture here:

I’m also helping out on our official Discuss forum and Slack group as well as on StackOverflow. And while I’ll never answer more questions on Discuss than my colleagues Alexander, David, or Mark, I’m making up for it on our internal #technical-questions Slack channel. Because that is a great multiplier to help more folks from us to help the community. This is where you learn and try out things yourself — it is like the fast track to the problems of many other people. My Sales Development Representative (SDR) colleagues even made it into a meme: Meme for helping with technical questions

Open Source #

Open Source is where Elastic started, and as our founder and CEO Shay keeps saying:

Open source is a distribution model that allows us to build community. It’s a force multiplier.

My three focus areas there are:

  • Google Summer of Code and I’m very happy that after 2018 we’re one of the mentoring organizations in 2020 again.
  • An area we’re currently building out is sponsoring of other projects we’re using. Like cURL and quite a few others — more to come.
  • Bringing back feedback from the open source community to our engineering, product, and sales teams. It is a delicate balance, but someone has to speak for the open source side inside a company as well.

Internal #

Working with the community isn’t a one-way street. The point isn’t only to spread the message but also to bring feedback back into your organization. Besides GitHub issues and Slack messages, we also have a very active mailing list for sightings. This is our place of sharing any mention of Elastic products (good and bad) or what competitors are up to. It is great to learn about the field, what is working, what is broken, or about common issues.

If Apple Mail can be trusted, I have recently sent my 1️⃣0️⃣0️⃣0️⃣th message to that mailing list.

Other Tasks #

Especially my Asian colleagues like Jongmin, Martin, or Xiaoguo spend a lot of time on localized content. And it helps a lot in many regions. But I’m less convinced about it in Europe and the German-speaking area in specific. That is why it is less of a priority for me:

  • Recreating existing content in German feels like a rather dull task for me — it already exists, and I would instead explore additional topics. And since our documentation and code will always be in English, there is no way around it anyway once you want to dive a little deeper.
  • You’ll either end up with a wild mix of Denglisch (Deutsch + English) or create hilarious texts trying to find German words for things like observability, Jaeger intake, ingestion, Operator,… that I find almost impossible to read myself.

There are more, but most of them are infrequent or quick to do on the side:

  • File GitHub issues or pull requests as things come up in discussions, especially around documentation.
  • Review content for community members either for an event or a written article.
  • Give internal feedback on upcoming features, blog posts, or announcements.
  • Help out at an Elastic{ON} Tour stop.

Less Relevant #

Something I find less relevant in that discussion is titles and departments:

  • Titles are generally abused. Some prefer Community Engineer, Community Advocate, Technical Evangelist,… but I would see it as a personal preference rather than a clear distinction in the end.
  • The only thing that is constant with a fast-growing company like Elastic is change. I have been all over the organizational chart, and it has never actually changed my job (yet).
    When I was hired we were a DevRel team directly under the CTO. When our lead Shaunak wanted to move back to development, we were split up, and each advocate joined a different engineering team — mine was Infrastructure since that was my background where Drew had to adopt me. After that we were joined together again in a Community team in Product under Tyler; until Product was folded into Engineering, and we were a Community team there. Only to be then moved to Marketing first led by Mark now by Kelley. I’m not yet sure where we might be going next.

What counts in the end is that it’s a technical role spending most of the time for and with the community. No title will fix that if your role is to sell directly — regardless of where you are in the organizational structure.

Conclusion #

Community is a wide field. Finding the right mix of things to do to keep yourself motivated and to add value — both for the company and your community — is up to each one of us.

PS: If you’re looking for a speaker for your next conference, meetup, or lunch & learn, don’t hesitate to contact me.