Building a Developer Relations Team: Interview with Lorna Mitchell

Lorna Mitchell runs a Developer Relations team at Aiven, a company that manages open source database infrastructure for their clients. She shares her insights on launching a DevRel team, documentation, reporting structure, and how and where to best engage developers.

If a company is hiring someone in DevRel, what would you recommend they look for?

A great place to start is to hire someone with a skillset that’s as close to your target audience as possible. Hire a backend developer if you are in databases, for example. It should be someone who would want to use your product or service as a customer themselves. Often we think of people working in DevRel as interchangeable speakers or writers, but we have specialist skills as diverse as the communities we serve. Being able to use use the product as the customers would allows me to see the experience through their eyes

Developer Relations is about enabling developers to be successful. That can be jarring to companies who are used to traditional marketing and sales tactics! DevRel is about empathy and a genuine desire to help others achieve their goals.

Any advice for organizations who are launching a DevRel team?

When we founded the DevRel team at Aiven, we engaged in a mix of evangelism and education. We created developer content and examples, gave talks, and focused on finding out what resonates with the developers who use our platform.

Another big part of the DevRel mission is to improve the developer experience. We added more documentation and examples for each of our products to help people to get things done with the Aiven platform.

If you’re the first person on the DevRel team, you might be under pressure to do more traditional sales, or find that you get dragged into doing actual engineering work sometimes. You have to really be intentional about what you’re doing and keep those goals in mind.

Where does your team report to and what structure do you recommend?

I currently report to Marketing, which is a common reporting structure in smaller companies. Aiven is a Series C company with around two hundred employees. 

Luckily, Marketing here really “gets” DevRel so it works well. It is also common for DevRel to report to Product or Engineering, and that can work well too depending on the company.

From my perspective, one benefit of reporting to Marketing is that it is very data driven, and that influences me in a good way. My background is Engineering, so working in Marketing means that I learn a lot from my immediate peers.

As an engineer, I was not familiar with the revenue funnel. I have learned why it can be useful to add some query parameters for tracking, for example. These are data insights which I didn’t know that I needed, and these help me to see how developers are responding to our resources.

At Aiven, I have the support of Marketing to inform our developer audience, not to try to convert them. If you want to try the product, I would love to show it to you. But I am not rewarded or not on whether people buy the product. My role is about writing content, producing tutorials, and having developers engage with us in a positive way.

We have open source databases so that gives me a lot of freedom to enable developers whether they use Aiven or not. The information is widely transferable even if they don’t use our services. 

Related Content: Partnership Leaders Share Advice on Building Out a Tech Partner Program

How do you interact with other internal departments? 

DevRel is very hands-on and we collaborate with many other departments. We collaborate closely with Marketing, especially on content and events. We work with Communications to handle social media accounts and other developer channels. We have the Open Source Program Office where we work on the Aiven GitHub projects and collaborate on upstream contributions. We support technical colleagues from across the organisation in creating content, such as giving a conference talk or writing a blog post. We also lend a hand with the support tickets and create documentation for new product features.

Do you recommend focusing on the channels you own or other channels that developers hang out on?

My usual approach is to meet our community where they are. We have a blog, and our developer portal, but we also spend time on the platforms where the developers are. That means answering questions on Stack Overflow, and having conversations on Twitter and Reddit, and interacting with people at online events.

How to get traction on these other channels?

For us, it helps that the Aiven platform offers the most popular open source tools in the industry - news about them hits the front page of Hacker News every day, for example.

If you use something proprietary it is more difficult. Try to create more content, and provide a lot of examples. You have more of a burden of education. With a proprietary tool, your first hire in Developer Relations is going to look a little different and be more focused on education than engagement.

What do you advise in terms of keeping good documentation? 

Without documentation, you don’t have a developer experience. The tooling is very different depending on the contributors to the docs. In my experience, most documentation is written by engineers who created the feature. I recommend hiring technical writers so they can also contribute to the documentation, and support engineers in their writing.

We take a docs-as-code approach as it is a familiar process to engineers because it is a pull request process. Our engineers write reStructuredText, as most of them already write that, and Sphinx generates docs for it. We use a static site generator and share the preview in Netlify. 

Related Content: Mastering API Documentation: 3 Proven Best Practices for Success

Do you recommend any particular KPIs for DevRel? 

I find it hard to generalize for the whole discipline. I recommend reading Mary (Grace) Thengvall on the business value of developer relations. It can be hard to measure. We do a lot of different things but it can be hard to nail down all the effects. 

For different stages of growth and different businesses, it looks different. Once you have a big team, you may be able to track more specific metrics. Ultimately, developer relations involves a lot of enablement, both of developers and of the company.

What is a common challenge for those working in developer relations? 

Explaining what developer relations is! The basic problem is that Developer Relations is a very wide term, with lots of different job roles inside it and those roles differ between organisations. Since there are so many different skillsets needed in the department, then the role attracts a very diverse range of individuals, and once you’re doing the job you quickly learn that every day is different from the next.

How do you best leverage events and conferences? 

I recommend submitting to conferences through calls for papers, and giving technical talks that are appropriate for the audience of each event. Once you’re there (virtually or in person), engage with the whole event rather than just showing up for your own talk. Chat and network with people, ask them what they are working on and which of the sessions they found most useful.

It is good to run your own event if you have an audience who is engaged with you on a regular basis and interested in participating. If your audience is diverse, and, for example, runs from hobbyists to those working for enterprises, this makes a single event quite difficult. Of course if your audience is large enough, you can have different types of events for subsets of your audience.

How do you generate awareness of your events and webinars?

We collaborate with marketing on webinars and, in those cases, marketing does the marketing behind it. We are moving away from ”give us the email and show up at one time” to making useful content available on demand to reach our customers in all time zones.

Do you have any advice for an engineer new to DevRel? 

When you are new to this role, it’s good to reach out to others in the field. Find your tribe on Twitter, or find one of the related newsletters. Especially if you are on your own in your company, which is not unusual, spend effort to find your peer groups. There are DevRel conferences and the DevRel Collective, so access your own DevRel community, we are a very supportive bunch.

‍