Many companies hire Developer Relations (DevRel) positions, but often they do so simply because they are needed, without a clear purpose. This often leads to failure. In fact, from 2018 to 2023, recruiting for the DevRel position was active in Korea, and many companies showed willingness, but recently it has decreased noticeably. (If you look at the search volume trend, each company’s blog post upload trend, etc.)
In fact, the first appearance of the DevRel profession itself was very impressive. Google and Amazon actively used this, and in a way, this virtuous cycle of attracting excellent human resources by making the company attractive to developers through various technology events and content, and then attracting more human resources, is what many people think of as DevRel. It was a job that involved a variety of fields, including marketing, recruitment, branding, and development. Conversely, the problem was that not all of them were experts.
The problem is timing!
Recently, Bear Douglas , who leads the DevRel teams at Facebook, Twitter, and Slack, and recently started a DevRel outsourcing company, wrote a post on Twitter about when to hire DevRels and what tasks they should perform. To summarize briefly,
1.
DevRel's business impact is measurable, but building a measurement system can be costly
2.
DevRels should be hired when the scale of existing tasks (technical writing, developer support, etc.) becomes unmanageable.
3.
DevRels must be under a leader within the organization who understands their purpose → often belong to the marketing department when the company's core product is developer tools, or to the product or engineering department when dealing with ecosystem APIs or non-core products.
DevRels fill a variety of roles depending on what the company needs. If engineers feel limited in documentation, they hire technical writers, and if founders find it difficult to attend hackathons and meetups, they hire developer support staff. Common mistakes when hiring DevRels include thinking that DevRels are just one job or focusing on people instead of changing strategy.
A good DevRel team member should have complementary capabilities and a good fit between their career goals and the needs of the organization. For example, if the job is product-oriented, it would be better to hire product-oriented talent rather than developer support, and if outreach is important, it would be better to hire talent who are passionate about creating and spreading educational content.
In the case of technical writing, reading their work and asking them questions about their writing process helps with verification. In addition to new content, there are many tasks that this position can take on, such as improving document structure, establishing a documentation system, improving UX, and creating style guides. However, most of the time, they only select technical documents and content and put it off as not necessary. (I have seen many cases of outsourcing.)
In fact, I have seen many DevRel people around me who even edit videos. A complete all-rounder....
If that's the case, there's no reason to hire them...
A typical example of this is what happens when you don't know why DevRel exists. It is best to belong to an organization that understands and supports DevRel well. Marketing has big budgets, BD has clear goals, and engineering has an advantage in hiring and salaries. But more than anything, the support and understanding of the leader is important.
Developer influencers gain influence by providing broad education in a specific field or creating cool things with their products. It is better to hire talent who can demonstrate the potential of your product rather than existing followers.
Measuring DevRel performance is difficult, but not impossible. Measurement is easy using individual project-level success indicators. Examples include attracting top talent, developers’ voluntary participation in projects, and purchase conversion through online and offline events.
Ultimately, to demonstrate the value of DevRel, it's important that each team member takes on tasks that are essential to the company's success. Documentation, sample code, customer/partner management, etc. are essential for launching a new product. If DevRel becomes indispensable, its status within the organization will automatically increase.
In conclusion
DevRel is a very difficult job. If there is no trust and support from the top manager or leader, the operation itself will not be possible in the first place, and if the members are not convinced of the reason for doing this, the operation itself will often become difficult. This is especially true because due to the nature of DevRel, there is very little work that can be done alone. Even if you try to request documents, presentations, lectures, etc. from members, if they don't feel the need for it, DevRel can't do much. Then, of course, DevRel performance will drop.
Personally, DevRel is the overall PM, and the key is for the CEO, CTO, etc. to show faith in DevRel activities, provide consistent support, and encourage active participation from members, so in some ways, DevRel is hired when there is no clear certainty that “our organization needs a DevRel.” So, I think it would be good for everyone to avoid difficult experiences. It's something that everyone wants to do well, but if it's a hassle, the person doing it won't want to do it either.
Four feet
On the one hand, I think we need to think about why DevRel rose and then disappeared. I'm sure someone felt it was "unnecessary" and decided to downsize by reducing the budget or mixing it up through reorganization... Why did they make that decision? Recently, as I see Toss and some other companies in Korea trying to revive DevRel, I hope they think twice before the wave comes again and create a richer and more interesting DevRel ecosystem.
