The decision-makers, dreamers, hackers and creators known as developers are the key players who are driving demand for the latest and greatest tools. Now they have become the customers that companies are turning to as a way to extend their products and businesses.

Today, the group that works in close liaison with developers is known as “developer relations.” These teams give a voice to developers, offer technical support, and listen to them to determine what future products and tools they need in order to be successful. With the right strategy and structure, developer relations teams can reap business benefits, while still maintaining a strong, excited developer community.

Apple’s Guy Kawasaki, famously known for marketing the Macintosh computer line in 1984, was one of the first people to realize that in order to build a strong community of developers, you need to blend an engineer’s role with technical marketing. Since developers want technical information (sales jargon aside), it’s up to developer relations to empower and build relationships with developers to help them learn, grow, and accomplish their goals.

(Related: Microsoft offers help for cloud hardware)

A simple way to understand what the role of developer relations is came from Google advocate and software engineer Reto Meier in a Medium post. He wrote: “Developer relations are the canonical source of truth, both for third-party developers looking for documentation, best practices, and training, and for internal engineering teams who need to understand the thoughts and experiences of third-party developers, and to get candid technical feedback on their developer offerings.”

Developer relations is much more than that, according to VisionMobile CEO and founder Andreas Constantinou. It’s a more modern name for what used to be called developer programs, and it can cover everything from tooling to SDKs, documentation to sample code, meetups to hackathons, and more, he said.

Developer relations also includes technical support, tutorials, evangelist programs, newsletters, blogs, social media, developer advocacy, and incubator programs. It’s everything that companies do to support and market to developers, where developers are the main customers, said Constantinou.

To evangelize or not evangelize
Developer relations is a superset that contains developer evangelism, which is similar to developer relations in that the goal is to communicate information honestly and technically, aiming to bridge the gap between developers and the company.

Although they have similar initiatives, developer relations and developer evangelism are not one in the same. In fact, developer relations teams tend to stray away from calling themselves evangelists because it sometimes comes with a negative connotation, said Burke Holland, director of developer relations at Progress. He said it seems more evasive, like, “I’m going to knock on your door and talk about things you don’t want to talk about.”

At Progress, Holland said the developer relations team handles it as a liaison between the developer community and the company that is making the product, so in a way they are the “voice of the customer inside of the company when they otherwise would not have a voice.”

Lisa Wong, head of developer relations for Wowza Media Systems, said some teams use “developer relations” and “developer evangelism” synonymously. At Wowza Media, she said the company focuses on building the relationships and community for the developer, which includes an aspect of evangelizing.

“We are also working toward building that trust with the developers that are familiar with the technology, and they trust the technology,” said Wong. “We are here to help them from a technical point of view as well as how they can use [the technology].”

It’s important to note that developer relations does not depend on whether or not the individuals are called “advocates” or “evangelists,” it’s making sure developer relations consists of technical people. Often developer relations teams are made up of engineers, because when it comes to making tools for developers, you need to know about the industry as a whole, not just the product, said Holland.

“You really have to be an engineer in order to do that effectively,” he said, adding that developer relations is also tasked with getting feedback to the company’s product teams. Besides having the technical know-how, developer relations needs to determine what developers think of a product and what missing key features they are looking for. Since product teams don’t have the time to go out into the world and directly communicate with developers, it’s up to developer relations to vouch for the developers themselves.

“Developer relations is the one that goes back and fights for that [feature], lobbies for that internally, and says, ‘Hey team, the industry is moving in this direction, and we need to move in that direction as well,’ ” said Holland.

Since engineering teams spend all of their time heads-down coding, developer relations needs to be out there in the field at conferences, meetups and hackathons, with their “finger on the pulse,” said Holland. Then, they come back with the ability to make strategic decisions based on where the future of the developer is headed.

The ROI of developer relations
Despite all of the effort and money put into developer tools and developer relations, there is still no standard for measuring the return on developer investment, said Constantinou. Every company uses different metrics and ways to measure the success of their developer relations initiatives, but a lot of these measurements are meaningless, he said.

Some organizations measure success by the number of developers touched, but this is an old method that really doesn’t give developer relations any insight into how well their program is doing, according to Constantinou. Another way platforms have their success measured is with net promoter scores (NPS), where the company polls its active developers once a year to determine the probability of them recommending the tools and solutions they use to others. Getting users to score developer programs based on an NPS has its ups and downs, he said, but these are frivolous and short-term metrics that do not effectively measure a developer program.

Another way to get return on developer investment is to see how many developers are downloading a company’s SDK, or how many developers are building apps with the SDK. Constantinou said in the case of messaging platforms, the platform would look at how many users are building messaging bots and how many companies are installing them. Then, developer relations would need to measure how many companies are actually using those messaging bots.

Other developer relations teams look at the amount of apps using their APIs. For open-source projects, developer relations programs can measure their success in terms of how quickly the project was adopted within the open-source community.

It’s also difficult to measure the success of developer relations because it’s not a department that can be given a quota like sales, said Holland. The second developer relations is assigned a quota, that company will have just eliminated the entire point of the program, which is to build relationships with developers, he said.

Progress, which has a content-driven developer relations program, looks at how many developers are coming to read their technical blog content and then determines how many of those developers go on to check out their products. They call this “traffic to trial,” and it’s their primary measurement method because they want developers to test out their tools.

Wowza Media’s Wong said her developer relations team has different metrics, which include checking the company’s developer blog’s content and how well it was received. Depending on the piece, the metric could be based on referrals, traffic, or time spent on the page. She said Wowza Media also looks at its own developer forums along with third-party forums like Stack Overflow, where it can see how many questions were answered by its team versus community members.

Developer relations teams can start here for measuring success, but there still isn’t a consistent way to measure how the investments in hackathons, tutorials, how-tos and evangelism programs are paying off for developers, said Constantinou.

To address this problem, developer relations teams can create their own tools or standards, which is what VisionMobile did when it released its developer program benchmarking research in 2015. Using its methodology allowed the company to determine things like what developers look for in a developer program and how a developer program can become a developer community.

While companies wait for one standard way to measure developer relations, they can focus their time and energy on talking about the real problems developers face, and how they can start to solve them. Holland suggested “getting down into the hole” with developers, offering help and figuring out a solution to their biggest frustrations.

“We are emphatic, we can commiserate with the problem; the struggle is real,” he said. “We try to help, and if that involves our product, great. If it doesn’t, also great. The most important thing is that the developer in the end is successful in realizing their dream and what they are trying to build or go after.”