Social Media
Recently, we’ve been hearing more and more announcements about companies launching DevRel teams in Japan.
While it’s encouraging to see companies recognizing the importance of DevRel, we’re also starting to see comments like “Is this really DevRel?” here and there.
The term “DevRel” doesn’t point to something specific, which makes it prone to broad interpretation. This leads to “my version of the ultimate DevRel” or even fundamentalist views like “this isn’t DevRel at all.”
From my position (providing DevRel as a service since 2014 and organizing the DevRel Meetup in Tokyo community to promote DevRel), I’d like to explain the definition of DevRel.
A term similar to DevRel is PR (Public Relations). Public refers to the general public, and Relations means relationships. According to Wikipedia, it’s defined as:
To achieve the goals of individuals and organizations, it is essential to build good relationships with them. Public Relations is about building and maintaining desirable relationships (Relations) with the public by exchanging information and opinions in both directions.
DevRel (Developer Relations) can be seen as the developer version of Public Relations.
The purpose of DevRel is to build good relationships with external developers. The key point here is “both directions” as mentioned above. This means that while disseminating information from your company is important, so is the attitude of listening to developers’ opinions.
After all, would you trust someone who only talks without listening?
Public Relations hasn’t penetrated well in Japan because it’s translated as “Koho” (広報), which means “to widely inform.” This translation focuses only on the dissemination aspect, missing the listening component.
As a result, PR departments tend to focus on how to make people aware through advertising.
The key difference between DevRel and PR (or “Technical PR” as it’s sometimes called) is whether there’s a function to “listen.”
If the purpose of DevRel is to “build good relationships with external developers,” what should a DevRel team do?
This varies greatly. As mentioned earlier, there’s no “do this and you’re doing DevRel!” formula. However, since around 2016, it has been categorized into three main categories:
This is known as the 3Cs of DevRel, introduced by Brandon West of SendGrid (now Datadog). I also covered this in my book DevRel: The 3Cs to Become Engineer-Friendly.
For coding, this includes SDKs, demo apps, tutorials, libraries, and even code snippets.
Content is too broad to cover comprehensively, but it includes blog posts, documentation, videos, audio, and many other non-code deliverables.
Community includes developer communities, events (including conferences and hackathons), social media, Q&A interactions, and more.
There are so many initiatives possible in DevRel that it’s impossible to say “you should do this and this!” The optimal choices depend on your company’s resources and stage.
Some DevRel teams support internal engineers by helping them with speaking engagements or blog writing. Is this DevRel?
Of course, this can be part of DevRel activities (known as Internal DevRel overseas). Many people in DevRel teams are engineers who have moved away from the front lines, so they might become less familiar with the latest technologies in the field. The knowledge accumulated on the front lines is substantial.
Content that resonates with developers comes from engineers working on the front lines speaking at events or writing blog posts. Supporting such activities to build trust with external developers is definitely DevRel activity. There’s no rule that DevRel team members must be the ones speaking or taking the spotlight.
I’m not very familiar with the term “Technical PR,” but I’ve read several introductory articles:
| [What is “Technical PR” Getting Attention Now? Its Initiatives and Points | PR TALK by talentbook](https://product.talent-book.jp/pr-talk/knowhows/technical-pr/) |
In both articles, the focus is still on “PR = dissemination.”
Since DevRel aims to “build relationships with external developers,” while “information dissemination” is important, “listening” through dialogue, feedback, and Q&A with developers is essential. The difference lies in whether there’s this “listening” component and whether the purpose is relationship building rather than just dissemination.
By not strictly defining “This is DevRel!”, unique initiatives have emerged not just in Japan but in various countries. Early DevRel is said to have started with Guy Kawasaki at Apple, focusing on increasing Mac OS software developers (including companies). In this sense, DevRel is a Silicon Valley-born culture.
Therefore, approaching it with the mindset that the American way is standard and everything else is inferior could lead to major failures. When foreign companies enter the Japanese market, they need to understand local developers and provide the resources they need. Japanese documentation and support are common examples - if you insisted on English-only documentation because “the American way is absolute,” you definitely wouldn’t get users.
Japan, China, India, and other countries each have their own cultures. France, the Netherlands, the UK, and others also have different developer cultures and challenges. Success is unlikely without properly understanding these and implementing DevRel tailored to local developer needs.
Japan-specific initiatives include “mokumoku-kai” (silent coding meetups), “manga,” “Tech Book Fest,” and “Gishobaku.” Heroes League has been held in Japan for a long time, and Advent Calendars are most active in Japan.
Of course, India, China, and others each have their own unique cultures and initiatives.
If you’re unsure whether your company’s initiatives are DevRel, judge by whether they “contribute to building relationships and trust with external developers.” If you can say it’s being done to build good relationships, then it’s part of DevRel activities.
Conversely, if it’s only “dissemination,” just building a talent pool, or only leads to promotion, it’s not DevRel. It’s something else, so look for a different name. When it’s called “DevRel-like,” we end up back at “What is DevRel? 🤔”
While we talk about Japan-specific initiatives, DevRel is still most advanced in Europe and America. It started as an initiative in Silicon Valley, and DevRelCon, the global DevRel conference, originated in London.
Recent overseas trends include a focus on community. While raising awareness is important, there’s more emphasis on increasing touchpoints with developer communities and building communities around their products.
Also, the layoffs during the pandemic became a major topic. This has led to more refined roles for DevRel. Budget allocation and expected outcomes have become more stringent.
Additionally, the number of DevRel roles has increased. Beyond senior positions, there are program managers, community managers, content writers, DevRel engineers, and more. In America, job descriptions are role-based, so it seems they name positions based on required tasks.
How to quantify trust and relationships has been a long-standing challenge for DevRel. However, without properly solving this, it could lead to questions like “Why are we doing DevRel?” or “Was DevRel meaningful?” This could result in focusing only on easily measurable initiatives (mainly dissemination).
In marketing terms, this relationship could be expressed as loyalty. Loyalty measurement includes items like:
These are commonly used metrics for measuring customer loyalty. However, these are metrics for “existing users.” For developers, metrics like Q&A question counts and views should also be tracked.
For DevRel, it’s also important to raise awareness among developers who aren’t yet users and get them to register. These metrics are measured through website PVs, social media followers, event participants (continuous participation counts), etc.
While this has been somewhat rambling, the key points are:
I don’t think it matters whether your product is developer-focused. In today’s world of “software eating the world,” “DX,” and “internal development,” companies that developers avoid will likely be eliminated.
Also, considering Japan’s declining population, it’s certain to become a competition for a limited pie. How to make your company and products known and chosen by developers is an important challenge.
And, of course, “trust doesn’t build overnight.” It’s only through steady, step-by-step building that we achieve unshakeable trust. I hope you approach DevRel with this in mind.
MOONGIFT supports your DevRel & developer marketing in the Japanese market. If you’re interested, please contact us.
You will receive news and updates about DevRel via email.