If you're considering starting a DevRel program at your company, the first question to ask yourself is: do you need a developer advocate or DevRel organization? And if so, where should it reside within your company? Let’s tackle these questions step by step.

Do you need a DevRel organization?

The answer depends on your specific needs and your customer acquisition funnel. If you have a robust sales team that's effectively closing deals and acquiring new customers without much trouble, you might not need a DevRel organization—at least not right away. Similarly, if your marketing team is generating plenty of new pipelines, a DevRel team might not be necessary either.

The primary reason to establish a DevRel organization is to represent the interests of developers—particularly if you're running a DevTools company or a DevTools-focused division within a larger enterprise. Developers are often the first to try out your product, so their feedback and satisfaction are crucial.

DevRel serves two main purposes:

1. Listening to developers: Developer advocates need to understand developers' needs, represent them, and provide valuable feedback to your product team. They should become users of your product themselves to gain firsthand experience.
2. Communicating with developers: DevRel should also communicate your product's benefits to both existing users and potential customers, educating them about the problem space and how your solution fits in.

Think of developer advocates as an API between your company and the developer community. This API needs to work both ways—carrying output from your company to developers, and bringing input from developers back to your organization.

Where should DevRel sit within your organization?

Once you've decided where your DevRel team should reside, the next question is determining its placement within your company. The ideal situation, in my opinion, is for DevRel to be either an independent organization or part of the product department. Why? Because at the end of the day, everything hinges on having a solid product. If developers like your product and continue to use it, your chances of success increase significantly.

A strong product that developers enjoy can even influence the sales cycle. If developers within a potential customer's organization are happy with your product, the decision-makers are more likely to purchase it. This also affects your market positioning; a product that developers trust will enhance your reputation and reduce the need for extensive marketing spend.

That said, there is also a case to be made for housing DevRel under marketing or engineering:

• Marketing: If your product already has good retention and market positioning, and if you're focused on marketing activities, placing DevRel under marketing might make sense.
• Engineering: If your DevRel team will act partly as engineers or focus heavily on documentation, integrating them with the engineering department could be beneficial.

Ultimately, though, DevRel’s most effective place is likely under product or as an independent organization.

Hiring a developer advocate

When you start to look for your first DevRel hire, you’ll want to find someone who’s already done this type of work and is motivated to continue doing it.

Developer advocates often come from a traditional developer background, but in their spare time, they often get into content creation, community management, or open-source project management. Their reputation should be easy to assess by looking at their public profiles, such as their follower count, blog, YouTube channel, and overall sentiment from the developer community.

During the hiring process, look for someone with:

• Good reputation: How do developers view this person? Do they have integrity and strong relationships within the community?