What is DevRel at InfluxData

By Anais Dotis-Georgiou / Developer
May 21, 2024

The role of a Developer Advocate or Developer Relations (DevRel) can be both pivotal and perplexing. What do DevRels do as individual contributors? How does the DevRel team function as a whole?

Like at many other companies, the contours of a DevRel position blur the lines between technology advocacy, community engagement, marketing, and product evangelism, making it one of the least understood yet critical roles. This ambiguity not only highlights the uniqueness of the position but also poses a significant challenge when hiring new talent.

As we delve into what it means to be a DevRel at InfluxData, I aim to demystify the role and shed light on its integral function within the organization. I also will take a moment to share some of the lessons I’ve learned during my time in this position.

What does a DevRel do?

When someone asks what a DevRel does, I usually give a convoluted answer like, “A DevRel is someone who represents the company to the community and vice versa.” I like this answer because, although it’s admittedly vague, the role of a DevRel is vast. Every company has a different opinion about the role of Developer Advocates. Here are some common types/models:

• The Tech Influencer: Some companies have only one DevRel that acts as the “face” of the company. This is a marketing-heavy DevRel. You can think of them as a “Tech Influencer.” They focus on their social media following and produce short videos for those channels. They usually don’t go into technical detail but focus on branding, messaging, and design. I don’t consider this to be true developer advocacy; it is more of a marketing role. For me, ‌DevRels are best leveraged further down the funnel by building technical solutions and content that help users solve complex problems so marketing teams can focus on top-of-the-funnel metrics like views and subscribers.

• Front-End/Back-End Developer Advocacy: Other (typically larger) teams split DevRel work into “Front-End Developer Advocacy” and “Back-End Developer Advocacy.” In this model, some DevRels create technical content, demos, and documentation. Others are responsible for sharing that content publicly via webinars, conferences, etc.

• Internal Product Consultants: Some DevRels believe they should lead product planning and serve as internal consultants across the organization to help incorporate user feedback and align the product with the user’s needs. These DevRels also act as part-time solution architects and are often more closely tied to sales and customer success efforts. Their job isn’t to sell the product but rather to act as an educator for potential customers during sales calls and leverage that knowledge to help steer product development.

• The Developer Advocate Engineer: These developer advocates are extremely “Back-End.” They spend most of their time answering community questions, looking at GitHub issues, and contributing minor bug fixes or feature requests as needed. They are typically a senior full-stack developer that can make small contributions to any part of an open source project as needed. They might also contribute to upstream projects or other open source tools to increase interoperability.

• Education DevRel: Large DevRel teams might have members who focus on outreach with universities and undergrad or graduate students.

• Meetup/Event and Partner DevRels: These DevRels spend their time organizing meetups for their company. This includes promoting events, finding sponsors and presenters, organizing activities and giveaways, etc. They might also organize hackathons and other inclusive coding events like office hours. They also spend time developing partnerships and looking for collaboration opportunities with other organizations.

At InfluxData, our mighty team of two most closely follows the “Front-End/Back-End Developer Advocacy” model, although we do a bit of everything. In my opinion, we do a good job of representing the company to the community, but we don’t have many opportunities to represent the community back to the company (more on that later).

Meet the team

Zoe Steinkamp is a Senior Developer Advocate at InfluxData. She is more of a “Front-End Developer Advocate,” and has been at Influx for five years. She started as a front-end developer and moved into DevRel about four years ago. Zoe is passionate about giving technical presentations and building relationships with the community. Her home language is JavaScript, but like all Developer Advocates, she spends time coding in multiple languages.

I, Anais Dotis Georgiou, am the Lead Developer Advocate and have been with InfluxData for six years. My passion is for all things math, data analysis, and data science. My home language is Python. I focus on creating technical code examples, blog posts, virtual webinars, and InfluxDB University Courses.

DevRels at InfluxData have also spent their time contributing to product and documentation, creating partnerships, organizing meetups, as ad-hoc solution architects, and involved in customer success efforts. But let’s take a look at how we spend our time today.

How InfluxData DevRels spend their time

We typically spend our time on the following:

• Creating technical demos, POCs, and code examples
• Presenting at in-person and virtual conferences
• Answering community questions
• Writing technical blog posts or tutorials
• Creating InfluxDB University courses

Here’s a rough estimate of how Zoe and I spent our first quarter of this year so far…

Technical demos, POCs, and code examples

The DevRel team at InfluxData created InfluxCommunity, a GitHub organization with several repos showcasing how to use InfluxDB with a variety of other open source tools. It’s also where all of the client libraries for InfluxDB v3 are maintained.

We contribute the demos and code examples independently, as a team, and with other community members or engineers at InfluxData. The purpose of these tutorials is to help users get started with a specific technology stack or use case. Our aim is always to make getting started as easy as possible. We achieve this by making sure our demos are dockerized, leverage open source tools or free versions, and are well-documented (with either a README.md or an accompanying blog post).

Some of our most popular repositories (ranked by GitHub stars outside of the Client Libraries) are:

• InfluxDBv2_Telegraf_Docker: An example of how to run InfluxDB v2 and Telegraf in containers.
• Plant_buddy: A demonstration project using the InfluxDB platform as the backend for a Flask web service.
• Notebooks: A collection of Jupyter Notebook tutorials on anomaly detection, forecasting, and InfluxDB.
• Telegraf-Community-Configs: A repository that promotes the creation, sharing, and reuse of configs among the Telegraf community. Anybody can submit new configurations or improvements to existing configurations and use them in their own architectures.
• Quix-anomaly-detection-example: This project provides an example of how to use Quix and InfluxDB 3.0 to build a machine-anomaly-detection data pipeline.

We also have code examples of how to leverage InfluxDB with the following technologies:

• Data engineering and streaming: Kafka, Minikube, Quix, Mage.
• Visualization: Grafana, Superset, Tableau
• IoT: HiveMQ, OpenTelemetry, MQTT, OPC UA, RabbitMQ
• Data analytics and data science: Pandas, Spark, Polars, and a variety of Python libraries for anomaly detection and forecasting

This year, Zoe and I contributed:

• Quick-start tutorials for consuming MQTT data and leveraging Kafka
• A Flight Demo on how to prepare, ingest, and visualize Air Traffic data with Python, InfluxDB, and Grafana
• A tutorial on preparing and converting time series data into a vector for ingestion by a vector database to perform similarity searches and anomaly detection

InfluxDB is used across a multitude of industries and use cases. Curiosity is required for any DevRel, especially those at InfluxData because we are constantly learning new technology stacks.

In-person conferences and virtual events

Part of Developer Relations is technical evangelism. This means sharing these technical demos at in-person conferences and virtual events. This also means submitting CFPs, applying to meetups, and performing booth duty at conferences. One of the highlights of this part of the job is meeting people face-to-face—from users, customers, and partners to our own Influxers. So far this year, Zoe attended seven conferences around the world, but in her three years as a devrel at Influx, she has been to 34 cities and 14 countries in various capacities.

Zoe and I also presented 15 webinars this year on various topics spanning “InfluxDB Basics” to “Harnessing the Power of Time Series Databases and OpenTelemetry.” We presented at InfluxData Webinars, virtual conferences, and webinars like Conf 42 and DBTA. Thanks to the marketing team for helping us find conferences to apply to and sponsoring webinars!

Answering community questions

A critical part of the role at InfluxData includes answering questions. At InfluxData, we primarily monitor our Slack and community forums (although we also respond to people posting questions on Reddit and Twitter). Community questions are an excellent way for DevRels to:

• Understand the types of hurdles users are encountering and the advantages and limitations of our product. Naturally, you’ll also become an expert on InfluxDB and Telegraf.
• Learn how to use other tech. You’ll get questions in every language and every space—from C# to JavaScript, from Arduino questions to a CISCO networking question to an algorithm selection question for specific forecasting problems. You’ll end up becoming an expert on a variety of other tools as well, like Grafana or Pandas.
• Get inspiration for technical demos or written content. When we see users asking similar questions repeatedly, we know it’s time to produce content on that topic.
• Build relationships with community members. We get to connect different community members working on similar projects. We also find opportunities for community members to share their projects with the larger community via webinars or community-contributed blog posts.

We have answered over 600 questions on the forums and Slack this year, and our involvement in our community has led to partnerships and content collaboration from companies like:

• Drona
• JetBrains
• Quix
• Mage

We’re also incredibly lucky to have a team of copywriters to proofread, make sure that our written content is on-brand, and handle publication and distribution for us.

Technical blog posts

This year, Zoe and I have contributed 12 blog posts, on InfluxData blog and external blogs. They include technical tutorials on topics like:

• Resources for Tasks in InfluxDB v3
• Sync Data From InfluxDB v2 to v3 With the Quix Template
• Time Series, InfluxDB, and Vector Databases

Answering community questions often inspires our written content. Our blog posts usually include code examples, but they tend to be tutorials or explanations. I recommend checking out Nick Groenen’s post about the 4 types of technical documentation to understand the types of technical content that exist and the purpose of each. Shout out to the docs team at Influx for creating excellent reference and explanation documentation.

Creating InfluxDB University courses

Finally, the DevRel team at InfluxData has created eight InfluxDB University courses. InfluxDB University offers free, live, self-paced training to help you gain skills and get started quickly. This year, we created courses on InfluxDB v3 Client Libraries, Tasks in InfluxDB v3, Telegraf, and more. See the full course catalog here. Mad props to the marketing team for helping to edit and package the content we deliver into full courses. We couldn’t do this work without them.

The good, the bad, and the ugly…

The fact is DevRels can be responsible for A LOT. Often, DevRels are stretched too thin, and a part of developer advocacy is neglected. Here are some lessons I’ve learned as a DevRel at InfluxData.

Representing the community to the company

As a team of two, we don’t have the bandwidth to serve as an internal consultant and really help leverage the feedback we get from the community back into the product. In the past, we centered more effort around categorizing every community question into feature requests to promote a data-driven approach to product development using Product Board.

Product Board has easy-to-use integrations with Slack and Community Discourse Forums. However, carefully organizing community questions and creating feature requests alone could be a full-time job. At the time we tried this approach, we also had a small team at InfluxData and found that it wasn’t sustainable to incorporate community feedback with this level of detail. We also currently fall short when it comes to leveraging community feedback into products. This is largely because we don’t have an InfluxDB v3 OSS edition released yet (but that’s currently in progress!)

Meetups, hackathons, and office hours

It’s also challenging to create meetups and organize hackathons. Organizing in-person events is extremely time-consuming and expensive. If you decide to include organizing events as part of your developer advocacy effort, I recommend making sure you have company alignment on the reach or acceptable topics for your meetup. Make sure it’s broad enough so you can continue to attract a variety of engaging speakers.

The meetups I’ve seen perform well center around industry sectors or languages, like a Data Science Meetup, Python Meetup, or Data Meetup. Expect to invite people to present on competitors’ solutions and focus on promoting cross-organizational education and community rather than using it as a vehicle for direct marketing. If you have a small team, I recommend applying to be a speaker at meetups instead. I’ve found much more success with this. Simply reach out to meetup organizers and share a list of relevant talks you can present.

We used to host live office hours on YouTube but had significantly more views after the live session. We observed that developers usually prefer to work asynchronously when solving a problem. If you can’t solve the problem asynchronously, I suggest that you offer to meet with someone virtually. The problem we encountered with office hours is that developers usually post questions immediately when they encounter them in the community rather than waiting for a scheduled time. They also average a faster response time posting a question and getting an answer than waiting for a weekly office hour.

Higher education outreach

I wish we had the bandwidth to focus on this, especially because I’ve talked to many community users using InfluxData as a part of their graduate research. Maybe one day we will.

Conclusion

Right now, the team is focused on leveraging the interoperability that InfluxDB v3 offers and finding purpose-built solutions to replace some of the features that existed in InfluxDB v2. Gone are the days when we tried to make InfluxDB the one-stop shop for your IoT, stream processing, alerting, ETL, and data analytics tooling.

Instead, we want to educate the community on leveraging the right tools to build a custom technology stack for their specific use cases. This means learning how to use various other tools with InfluxDB and creating technical demos with them to solve problems in different spaces.

We will continue to draw inspiration from the community and use those interactions to guide our efforts. We will continue to share work via virtual and in-person presentations. As always, get started with InfluxDB Cloud 3.0 here. If you need help, please contact our community site or Slack channel.