What is developer relations and why does it exist?
I’ve moved! Check out this article on my new site here.
For those of us that work in developer relations, we have likely experienced a situation like the following.
“Let’s start with a round of introductions. Sean, why don’t you go first?”, says the organizer of the meeting.
“Sure thing.
Hey there, my name is Sean Falconer and I work in developer relations.”
Room full of blank stares.
Even in my day job, it’s common to interact with colleagues that are unfamiliar with developer relations and externally, even more so.
Explaining your role and function comes with the territory of working in this space, but why is that? Why are people unaware of developer relations or confused about the responsibilities of those that work within the function?
I believe there are a variety reasons and in this post, we will take a deep dive into what people within developer relations actually do, why it’s tricky to define, describe what developer relations is, and why it even exists?
What do you do in developer relations?
Before we jump into defining developer relations, I think it helps a lot to set a frame of reference by first understanding what are the kinds of things people in developer relations actually do.
The variety of tasks and responsibilities can vary a lot from company to company and individual to individual, so this is by no means an exhaustive list. The day in the life of someone working in developer relations could include any and all of these tasks (and probably other things):
- Write a demo application for a new API feature
- Write a blog post explaining the new API feature and why someone might want to use it
- Update documentation for the new feature
- Speak at a conference, event, or host a hackathon
- Meet with the internal engineering team to review upcoming features and provide feedback
- Meet with product to provide feedback about the roadmap, help prioritize feature development, and share what pain points exist for 3rd party developers
- In collaboration with the business development team, attend a meeting with a high-priority 3rd party company to help them understand how to integrate with your platform
- Review support tickets with the support team to understand common developer issues and build a plan for addressing the issues at scale
- Review and tweak a marketing social media post that is targeting a developer audience
As you can see, developer relations is highly cross-functional, dynamic, and includes a wide breadth of skills and responsibilities. According to Bear Douglas, Director of Developer Relations at Slack, developer relations is “an interdisciplinary role that sits in a border space between product, engineering, and marketing”.
In my experience, besides product management, developer relations is one of the only roles where you might be part of every kind of meeting; engineering meetings, go-to-market meetings, product prioritization meetings, partner meetings, marketing meetings, and overall program strategy.
The reason for such heavy cross functional involvement is because if developers are your user, then the developer experience is going to be important to all functions within the company. Developer relations teams own the developer narrative of a product, or as Reto Meier wrote, they are “responsible for your platform’s developer experience”.
The SendGrid team talks about this in terms of the 3Cs for Developer Relations: community, coding, and content.
Community is how you build personal connections with 3rd party developers and how you grow awareness of your platform. Coding is the creation of resources to be used by 3rd party developers. If you want to build trust with a developer community, you need to code. Your code forms the foundation for demonstrations of your platform, reference material, easy to copy snippets, inspiration, and shortcuts to success. Finally, content is both reference materials like documentation and guides, as well as videos and blogs. This is how you reach and educate your community.
Now that we know a little bit about what these crazy people do, let’s look at why it’s tricky to define developer relations.
Why is it difficult to define developer relations?
I believe there are several reasons why definitions of developer relations vary and why many people, even in the technology industry, are unaware about what developer relations is.
As you can see from the prior section, there is a large breadth of tasks and responsibilities within developer relations, and even within the same company, what you see from one person working in this field might be quite different from another. You can have people in developer relations that spend most of their time coding, while others spend most of their time making videos, and others presenting at conferences. My team is small, so we do a little bit of everything.
This makes it hard to define in a one succinct sentence.
Furthermore, developer relations as a function may be in different parts of an org structure depending on the company. You’ll sometimes find it in engineering, or product, or marketing, and depending on where the function is located, the focus may vary.
Because of all this variability, the skillset can vary widely. In my experience at Google, developer relations is an engineering function and as such, most of us working in this area have software engineering backgrounds, but that’s not universally the case with all companies.
In terms of awareness, developer relations is still a relatively new function for companies to have and it’s really only applicable for companies with developer-facing products. As a result, most people working in the technology industry may never work at a company that has a need of a developer relations team. And since it’s somewhat niche, people outside of the technology industry certainly would not be aware of the discipline and what it entails.
What is developer relations?
According to Derric Gilling, founder of moesif, “[t]he art of developer relations is to actually build authentic relationships within your community without selling or marketing to them.”
In Mary Thengvall’s excellent book The Business Value of Developer Relations, she states that the purpose of developer relations is to “build relationships with and enable our technical communities”.
The mantra she promotes is:
To the community, I represent the company.
To the company, I represent the community.
I must have both of their interests in mind at all times.
I think this is one of the best descriptions of what developer relations is all about and I often use a version of this to describe my team’s role.
Despite the mix of skills, backgrounds, and responsibilities, I believe the one common thread across all developer relations programs is that developer relations is a people business. It’s about community and relationship building.
Effective developer relations means that you have built trust both externally and internally. Trust comes from building true and authentic relationships. This takes empathy, understanding, and the required technical skills to earn respect from other engineers.
Why does developer relations exist?
The simple answer is it always exists.
If you have a product where the users of that product are developers then you are already doing developer relations whether you have a dedicated team called developer relations or not. It’s the same as customer support or product or UX design. Even if you haven’t hired specific people to fill those roles, someone at your company is answering support calls or tickets, someone is making decisions around product requirements and roadmaps, and someone is putting pixels together to create a user interface.
So if you don’t have a dedicated team but you have a developer-facing product, someone in your engineering or product team is likely writing documentation, putting together code samples, and connecting with developers to solve issues on top of their normal set of responsibilities.
It’s important to understand that the first experience with any developer product is a combination of documentation, samples, and the process to get started. Nailing this experience and giving developers the tools they need to be successful is extremely important to platform adoption.
Twilio is a company that really focused on developers to great effect. As described by the BVP Group, Twilio successfully used “contests, promotions and social marketing targeting the web development community to generate viral buzz and word-of-mouth referrals”.
In a space where developers were traditionally an afterthought and the historical approach for growth was direct sales, Twilio transformed an industry by focusing on developers as their go-to-market strategy, “an end customer that turned out to be more valuable than people initially thought”.
To do developer relations really well, it needs to be part of your company’s identity, a core function with a direct feedback loop to product and engineering as shown below (sourced from The Core Competencies of Developer Relations).
The faster you can spin this flywheel of feedback for product improvements, the faster you can iterate and improve the developer experience. Prioritizing developers not only leads to greater platform satisfaction but also adoption.
Final thoughts
At its’ heart, developer relations is a people business, it’s about building real relationships with both internal and external engineers. If your product has an API or SDK, your company is likely already doing developer relations whether you call it that or not.
As a product and community scale, issues with the developer experience become amplified and it starts to become necessary to invest in having a dedicated team focused on making sure the developer experience is amazing and be a force multiplier to help grow adoption and awareness of the product.
The developer experience cannot be an afterthought, the bar set by the top API companies in the world is too high. It doesn’t matter how great your product is, if developers cannot understand how to integrate or use it, they’ll find another way. It’s easier to try a new API than figure out how to unblock yourself if you get stuck during the try it out phase.
Finally, if you work in developer relations, hopefully the topics covered here resonated with you. If you do not work in this space and somehow stumbled into this blog post, hopefully you‘ll now nod enthusiastically when someone introduces themselves in a meeting and their role is in developer relations.
