Exploring DevRel (Developer Relations)

tl;dr I get a lot of questions about “What is developer relations” and how to make a career in this domain, so thought of sharing whatever I know based on 3+ years as a Program Manager in the DevRel org @ Google.

What is Developer Relations?

The definition and scope of this domain is very strongly debated, but more or less everyone can agree that this role stands somewhere in between users (developers) and producers (technology/platform makers) for developer or platform products and services.

We stand mid-way between the developers and the engineering teams which makes the tech/platforms available to the developers. The distance between each side differs from company to company. And in bigger companies like Google, you can see multiple roles (like: Developer Advocates, Program Managers etc.), usually these roles change on adjusting 3 parameters — technical proficiency, proximity/ability to make/influence product roadmap, growth of advocacy.

Roles in DevRel org are organised based on what we ship for the developers, and certainly we don;t ship the core product. For example: For let’s say Firebase: Firebase engineering builds the product, not Firebase DevRel, but Firebase DevRel is responsible for:

1. Events to boost awareness (Roles: Marketing Managers)
2. Programs to increase adoption like certification, communities, ecosystems (Roles: Program Managers)
3. Technical documentation and support to improve adoption and retention (Roles: Developer Platform Engineers, Technical Writers, Developer Advocates)

Let’s start from the most technical ones:

Developer Advocates:

If you are proficient in a tech, then you are usually called “Developer Advocate”. Significant amount of your time is spent learning the nuts and bolts of the tech (present and future version) as well as sharing this knowledge in various forms: speaking at events (large scale gathering), meetups (small scale gathering), producing sample code/documentation in some cases. Usually the folks who get into this role and excel at this have the following qualities:

• Experience and love for that technology — People in this role usually come from being power users for many years, otherwise they wouldn’t be exposed to a lot of edge cases to show technical fortitude as well as evolution of the tech to show empathy for both the users and creators.
• Love for speaking and interacting with developers — This takes anywhere close to 20–50% of the time for any DA. And this activity becomes the sole point of refining your craft as a speaker/subject matter expert and gives opportunity to convince people of use cases and abilities.
• Part PM, part Sales — Usually the role softly toggles between getting feedback about the product from power users at the same time convincing/advocating about use cases and functionalities people haven’t explored. It shouldn’t be called sales — but developers usually have less time to explore new stuff, so DAs try different methods to make sure knowledge about new functionalities are known.

Developer Program Engineers:

These folks are responsible for writing sample codes and create libraries and engage with external developers through places like Github, Stack overflow etc. In many B2B or partner facing teams, they will also probably work with partners on their integration and with customers on their adoption.

For Cloud organisations, they might move out of DevRel and sit closer to sales org though.

Technical Writers:

Everything that you see in documentation of your favourite product or service is thanks to these amazing set of folks. They make documentation simple, readable and effective.

Program Managers:

The definition of program manager in the modern world varies widely, and it’s one of those roles where people might be doing completely different things in the same organisation in different teams. I like to think “Program Managers” as problem solvers, when the problem is related to establishing the right practices, structures and philosophies in place to make sure result (product/event/activity) is delivered with optimal time and resources. “Scale”, “Documentation” and “Stakeholder management” are the most used words in the world of a program manager. So, what does a program manager in the world of “Developer Relations” do?

• Establish/nurture practices/programs where we can engage external developers — it can result in stand alone events or communities or channels to up-skill developers at a client organisation.
• Establish processes to receive feedback and influence product and engineering stakeholders partnering with PA. This can also include understanding the requirements internally and validating those from outer ecosystems.
• Establish/nurture ecosystems for longer term impact. While engineers, PMs, DAs might move on to the next feature and the next api, program managers continue to make sure that the ecosystem’s interests/needs for the base products are met.

Program managers might or might not be tied to a single product and might or might not have technical fortitude. When the program manager is tied to a single product, it’s nice to have good familiarity with that tech, because it makes the conversations with both internal and external parties easier. Most of the time — program managers in DevRel world come from technical background and experience which makes their interaction with developers a worthwhile experience for both sides. But by and large, they are not subject matter experts and depend on developer advocates and engineering teams to provide that expertise.

Marketing Managers:

Marketing in the DevRel world usually gets established when the organisation is looking for “developer experience” not only from documentation, quality of platform and technical perspective, but also from how the product is perceived at scale and whether experience can play a role in bringing favorable cricumstances how people can know more about the products.

Think about conferences like I/O, F8, Dev Summits etc and the experience zones, demos and sandboxes etc. Usually this happens when a platform company has hit growth phase and the product is already proven in the market with a decent fan following.

Most of their responsibility revolves around the following:

• Execute scaled events — The events have the singular objective of providing a strong message to developer community about the upcoming features as well as giving
• Execute marketing campaigns — marketing campaigns to make sure people come to the documentation pages, and end up at places with clear action item to try the product or request for a quote or buy.
• Maintain the “soul” of the product — Over time, each product builds its identity, and it becomes paramount to make sure the brand’s recall remains strong amongst the users, So marketing managers nurture and improves the brand identity and recall.

Community Managers:

Every DevRel org has a community element, the platforms might differ, but end up in a healthy mix of online and offline platforms. Online ones include facebook groups, stackoverflow and offline ones are meetups, conferences etc. At the end of the day, developers opt to be at both places — you will see them at meetups and conferneces and also consuming content/participating discussions in facebook/telegram/whatsapp groups.

Their responsibilities hover around the following 3 aspects:

1. Giving direction to these groups or communities to operate well: In some cases, they lead these communities directly and in many cases, they work with external communities and play the role of mentor/adviser and support.
2. Be the voice of the communities internally: Communities are the place where the first adoption of the tech/platforms occur, they are the early adopters and they play a significant role in whether the product will be appealing to the mass developers or not, so making their voices heard for product feedback is critical
3. Keep the communities alive when no one is looking: Every group goes through hyper active phase followed by relative stagnation. Community managers attempt to make sure communities don’t die even when their leaders transition or the discussions become too infrequent.

Apart from these, there are a few more roles which are infrequent and end up in either product or DevRel teams based on their organisations structure:

1. Technical Writers — Folks who write documentation for the platform and technology and their impact is really long lasting.
2. Video Producers/Crew — Every platform needs videos on “how-to” explaining the tech, and good video crew makes a lot of difference in making sure the content is easily comprehended by the developers.
3. Developer Engineers — This title is very rare, but they are the folks who end up writing sample code, sample app etc to aid the documentation.
4. Customer Engineers — Mostly they are in sales org, but they might be in DevRel if the product is fairly new, their job is to make sure that the customers are successful using the products in their business.
5. Strategy Org — They are the ones who look at a long term view of the overall devrel strategy, keep an eye for competition and also make sure the overall organisation is running well.

I would end with a disclaimer that all mentioned here is personal observation, and of course there would be a lot of other roles which I am unaware of.

And now, since you have some understanding of what DevRel means and roles inside, you can read some more from other DevRel professionals to expand your idea of DevRel. Here are a few I liked:

• What does a developer evangelist/advocate do? by Christian Heilmann
• What Is Developer Relations? by Justin Carren