Max Katz has led Developer Relations teams at Okta, IBM, and Appery. He shares his advice on developer relations KPIs, collaborating with other departments internally, building a community, and how earlier stage companies should allocate their resources.

From a strategic perspective, what are the best KPIs or metrics by which to judge a Developer Relations team? How much of the role is attracting new developers and how much of it is engaging current developers?

I don’t know if there is such a thing as the best KPI. I believe every company will have a different KPI they measure and for them it will be their best. I believe it’s important to measure something whether it’s clicks on a blog, active developers, or applications deployed.

If you are a startup that just launched, your KPI and what you measure is probably going to be different than what IBM measures. 

Now, people also say there are vanity metrics (which perhaps are not good to measure) but if you want to measure them, that’s fine, as long as you understand what you measure and it helps achieve your overall company goals. 

I published a blog post where I suggest a 3-part framework on measuring success in Developer Relations: Measuring success in Developer Relations, a 3-part framework. I published another blog post on this topic: How to measure Developer Relations – DevRel meetup recap. This was an in-person meetup (when we could still do that) where Amir Shevat talked about measuring success.

What are the best ways to structure a Developer Relations team in terms of individual domains for different roles and which executive/department a Developer Relations team should be reporting to?

I’d say hire folks who love creating and publishing educational content and enjoy helping other people. If you believe you will be running a significant number of (online) events, you might also want to hire a Programs person. You should also look into hiring folks who are comfortable being on (live) video. 

As for which department, I don’t think it’s that important as long as the Developer Relations organization has clear goals which are also tied to overall company goals. And there is a strong buy-in and sponsorship from other parts of a company. I talk about it more in the questions below. 

My opinion, it should be its own department (not reporting into Product, Marketing or Engineering). 

Do you have any advice for people in Developer Relations who want to more effectively work with engineering, product, or revenue teams like marketing?

Sit down with leaders from Product, Marketing, Sales, Engineering, Support and any other organization and ask them how a Developer Relations practice will help them achieve (some) of their goals. Once they see how it will help them, I believe you will have a stronger and more effective collaboration. 

Are there any common misconceptions from leadership or people in other roles about Developer Relations and its purpose?

I think the biggest one is probably what value does Developer Relations bring to our company. I believe it’s important for the Developer Relations leader to show the value of this practice to the company. 

What are one of the biggest challenges people in Developer Relations face and any advice on how to tackle it?

I think it still comes down to what value does Developer Relations bring to the company. My advice is this. First, ensure that the Developer Relations team has very clear goals. It’s important that every Developer Advocate knows that what they are doing will get them closer to the goal. Now, that goal (or goals) need to align with the broader company goals. 

Second, ensure that the Developer Relations practice brings value and helps other company organizations. This will ensure buy-in and closer collaboration. In general, Marketing, Product, Sales and other organizations always work together. I believe Developer Relations shouldn't be any different. 

More tactically, if you work for a company that does not already have a built in open source community, what are the best channels these days to reach developers and to build a community? 

An existing community could be in a number of places. Dev.to is a popular developer community. Another one is Hashnode. You can also check Stack Overflow. You might also find people talking about your product in a Slack channel. 

It’s not necessarily “bad” that a built-in community might not exist. It’s absolutely fine to start, build and scale a new community. It’s important you talk with Product, Marketing, Sales and determine how a community will help them achieve their goals. I believe it’s important there is a buy-in from these organizations as you will also need their help to build the community. For example, if you decide to launch a blog, you would want to work closely with the Product team on producing content on new features for example. 

Do you have any advice for earlier stage companies with only one or two people on the Developer Relations team? What should they focus on at this stage?

My advice is to focus on things that scale such as educational content (tutorials, blogs posts, how-to’s and tips), videos and online events. Such content can be consumed by developers any time, from anywhere. 

This perhaps is not specific to early stage companies. It’s important that the Developer Relations team has very specific goals they are trying to achieve. This goal also has to be tied to overall company goals. The one or two people on the team need to know that whatever they are doing - gets them closer to that goal. 

One more thing I will say. It will also help if the Developer Relations function provides value to other company organizations such as Product, Sales, Support and Marketing. For example, ask the Product how the Developer Relations practice can help them achieve their goals. This will ensure there is a buy-in from all company organizations. 

Are there any different strategies or tactics you would advise for a Developer Relations team that is focused on third party developers (who are building on top of or to that team's product) versus a Developer Relations team that is focused on customer developers (who are using that team's product)?

The overall strategy should be very similar. How do we help these developers? How do we make them successful? As for tactics, you might have some differences on the type of content you create, companies you partner with and the type of events you host. 

How important is it that someone in Developer Relations be an engineer? How much of an expert do they need to be in the product and tools they are trying to engage?

I believe it helps if you have an engineering background, especially for more technical products or tools but it’s not required. I’m a believer that the more you know about a product or a tool, the easier it will be to educate people on how it works and how it can help them solve problems. 

Also, many companies are building low-code and no-code tools. As these tools target technical folks (but not necessarily engineers), advocacy people don’t need to have an engineering background. 

Beyond good documentation and being responsive to issues, what are some of the ways companies can best ensure their customer or partner developers have an exceptional experience?

Whether it’s documentation, support, educational materials, or online events - I believe everyone at the company needs to always think: how do we make our customers, partners, and developers successful?