Technology adoption doesn't happen with one software engineer coding in solitude. Even though big companies like Meta and Microsoft boast of their humble beginnings in a dorm room or a garage, product adoption requires good marketing. Many software engineers view marketing skeptically, seeing it as a sleazy way to convert potential customers into consumers. They often strive to develop a product so good that it doesn't need marketing. Reality check: Even if your product has the best user experience or solves the world's biggest problems, no one will ever use it if they don't know that it exists. Last year, I wrote an article highlighting authentic marketing strategies — an ethical and non-cringy approach to generate genuine interest in your projects.
Between 2019 and 2021, devtool startups recognized they needed more than elite coding skills for their product to succeed in a competitive market. They needed strategies to boost product awareness, education, and adoption among developer communities to sustain investor funding. Since developers, as consumers, are naturally skeptical, traditional marketing wasn't sufficient.
The solution involved hiring DevRel professionals, employees who can combine a deep understanding of technology and the developer mindset with exceptional communication skills and the creativity needed to engage effectively with tech communities. As a result, this led to a surge in hiring Developer Relations professionals. However, in 2022 and 2023, another shift occurred; a large influx of DevRel professionals left the industry. Some departures followed company layoffs, as businesses didn't see immediate return on their DevRel investments. Simultaneously, disillusioned individuals left voluntarily, often sharing their frustrations with unrealistic company expectations through YouTube and blogs.
DevRel Dissatisfaction
Goodbye DevRel for now by Alexander Reelsen
Snarky sidenote: I often believe companies replaced DevRel departments by adding 2023's favorite buzzword to their marketing slogan: "AI."
When I first became a Developer Advocate, a role within the field Developer Relations, I grew weary of the numerous blog posts asking, "What is DevRel?" These posts were initially helpful as I explored the field, but after I gained experience, defining DevRel felt repetitive. I thought it was so surface level, and I craved deeper discussions around:
Increasing community engagement
Modifying your DevRel strategy for various regions
Building relationships across your company
The art of public speaking
After two years and three months in this profession, I now understand the ongoing need to define DevRel in blog posts. Employers' dissatisfaction with DevRel's effectiveness stems from a lack of understanding what DevRel really is. This misunderstanding adversely affects our performance. Developer Relations is a medium to long-term investment. We are not "swiss army knives" that can lead all your product, marketing, engineering, and support efforts. Most importantly, to achieve true success, Developer Relations requires the involvement of the entire company. In this blog post, I'll discuss why company-wide involvement is essential for DevRel success and how to achieve it.
My Credibility
While I appreciate the respect from those familiar with my work, I occasionally encounter comments questioning my competence and credibility.
Example of skepticism ^
This skepticism might stem from my tendency to underplay my achievements, coupled with societal biases, as I am a young black woman. I welcome constructive debate and thought-provoking questions in the comments, but not dismissive remarks. To address this, I will highlight why my insights are valuable:
Alongside two other people, I took an early stage nonprofit from a vision to something tangible by developing and running 10-week online coding courses for women of color and nonbinary people of color. Over four years, I taught over 60 individuals, many of whom are now software engineers.
I made a huge impact as a Developer Advocate at GitHub by significantly contributing to projects like GitHub Copilot. My impact on GitHub Copilot was so great that when I joined a new company, I found a list of resources for learning how to effectively use GitHub Copilot, and they were written by me.
I am currently a Staff Developer Advocate at a fast-paced startup operating within Block.
I've held previous roles as a Software Engineer at early-stage companies, as hire number 7 and 20 respectively.
My educational background includes both a coding bootcamp and a computer science degree from Boston University.
Before I learned to code, I was a help desk technician and a phlebotomist.
My point is that my varied experiences across different roles and organizational sizes equip me with a holistic perspective. I understand the challenges and nuances of working in DevRel at both large corporations and smaller startups. I also know what it's like to work outside of DevRel.
Defining Developer Relations
Developer Relations, nicknamed DevRel for short, is a field made up of multiple roles including Developer Experience Engineers, Developer Advocates, Community Managers, Technical Writers, Developer Marketers, and moreThe primary objective of a DevRel team is to facilitate communication between technologists and the business. Although many enter the field with altruistic motives, the underlying mission is to expand the customer base in a scalable, one-to-many approach.
I'm a Developer Advocate, so I will focus more on that particular role. When engaging with the company, Developer Advocates represent the developer community. Alternatively, when engaging with the developer community, Developer Advocates represent the company. Developer Advocates raise awareness about the company's products within the developer community and provide the community's feedback to enhance the developer experience within the company.
Creating awareness can take various forms, such as discussing the company's developer tools on podcasts, giving conference talks, and writing blog posts.
Engaging with the developer community involves direct interactions, like one-on-one conversations in forums, audio spaces, or at conferences.
Improving the developer experience often involves relaying feedback to engineering or product teams, maintaining documentation, creating user-friendly sample applications, and developing open source SDKs that complement the company's product.
Ultimately, these strategies foster trust and education of the product. The developer community wants to use the company's developer tooling and understands how to use it well resulting in increased revenue. One of the most rewarding parts of this strategy is that it inspires community members to participate in DevRel activities, too! Often, community members are so engaged by DevRel's approach that they voluntarily start creating content or speaking at conferences. This enthusiasm can create a ripple effect, further boosting adoption within your company's developer community. However, seeing that increase in users and revenue can take a long time, ranging from months to years.
A Common Mistake in Developer Relations Teams
I admit that Developer Relations teams are not perfect, especially not me.
Developer Relations demands a careful balance between external activities and internal activities. Internal work, like community engagement and content creation, builds awareness and amplifies the company's presence. However, some DevRel teams focus too heavily on internal work, and then they struggle to make them product more known. Conversely, teams mainly focused on external efforts might neglect keeping documentation and example apps up to date.
You can have good docs, but no one reads them, or you can have unintuitive APIs, and folks walk away with a bad impression of the product.
I wrote a blog post outlining tasks you can do to make an impact internally and externally.
The Mismatched Expectations of DevRel
On the outside looking in, Developer Relations seems like a glamorous field promising tech celebrity. Behind the social media posts featuring people traveling the world to deliver conference talks and hanging out on social media, many developer advocates are grappling with the challenges of balancing rest, networking, and their core workload. A year into my first DevRel role, I detailed the job's demanding aspects in a blog post.
It can be both exciting and overwhelming to have your day-to-day work look like:
Hopping off of a Twitch stream
Jumping on to a plane
Refining your conference talk on the plane and practicing your code demo
Publishing resources for the most recent release in your hotel room.
Delivering your conference talk the next day
Fielding questions from the audience
Going to dinner with other developers
Heading to your hotel room to answer questions from the community
Managing your social media interactions
Writing a trip report as you travel back home
This hectic schedule can be frustrating, especially when faced with upper management's questions about metrics and the tangible impact of these efforts.
Many argue that DevRel job descriptions, like those for Developer Advocates, are overly broad and lack standardization, reflecting the diverse nature of DevRel across companies. While this viewpoint is valid, I see the flexibility as a positive aspect. Developer Relations encompasses a lot of cross-functional work. We might have to work with Marketing, Product, and Engineering. We might have to produce videos, write blog posts, and write code. I don't think that's unreasonable. Many DevRel professionals, including myself, enjoy the cross functional chaos. The apparent lack of standardization stems from the varying needs of different companies;
Developer Advocates often act as gap fillers, addressing specific weaknesses within the company. For example, some companies might be doing really well on the developer marketing side, so they need DevRel's coding skills to improve the developer experience. Or vice versa, some companies might have enough engineers to create a great product with a smooth developer experience, but they're struggling to engage with the community. Therefore, the level of ambiguity within Developer Relations roles seems fair to me.
Sidenote: Daniel M. Phiri wrote an interesting article on gap filling as a developer and as a developer advocate.
Another side note: Jason Lengstorf also has a great video on identifying gaps to fill in a company as a Developer Advocate.
{% youtube 3X-EUEOg638 %}
The real issue lies in the unrealistic expectations placed on DevRel teams, such as expecting the teams to:
Juggle too many tasks at once rather than focusing on specific objectives at different times, especially in smaller teams. Larger teams have bandwidth to delegate distinct areas like video production, blogging, or SDK maintenance.
Deliver quick results in areas like community growth, reputation building, and technology adoption. Such processes naturally take time. People don't instantly embrace new technologies after hearing about them. They require an engaging onboarding experience, positive interactions with the team, accessible documentation, and fun building processes. Establishing a smooth onboarding process might take several months, and improving documentation could take up to a year.
Operating in isolation without support from other teams. While DevRel supports other teams within the company, reciprocal support isn't always there. For DevRel to truly succeed, other departments must invest time and resources in helping DevRel achieve its objectives.
Creating a DevRel Culture
Making DevRel an all-company endeavor can look like:
Early Engagement in DevRel Activities: Even at an early stage, try performing DevRel activities BEFORE hiring a DevRel team. This firsthand experience builds empathy, respect for the role, and a clearer understanding of the specific gaps that a DevRel team would need to fill. It could also save you some money.
Inclusive Strategy and Product Discussions: Involve DevRel in meetings regarding strategy, product development, and engineering. DevRel should be informed and participate in the process if there are changes to the code or new company initiatives.
Encourage non-DevRel staff to contribute to DevRel initiatives: While DevRel leads content creation and public speaking, other employees should also be involved. For instance, an engineer sharing their perspective on tool development can boost the company's repertoire.
Practice working in public: This is especially important and easy if your company has an open source product. The community needs to know the roadmap and how you're thinking about building the product so that they can make valuable contributions. Working privately and expecting DevRel to publicize internal developments can lead to communication gaps. Open source thrives on mutual learning, often requiring more than code commits.
Keep open lines of communication: Maybe you're not on the DevRel, but you heard some feedback at a conference or when talking with a community member. Share that feedback with the engineering team and the DevRel team. Regular feedback sessions can help bring community insights into company processes.
Transfer knowledge from engineering to DevRel - Engineers know how the product should work because they built it. Transferring knowledge empowers DevRel to create more relatable and engaging content, documentation, and use cases for the community.
Integrate DevRel Principles in the Company Mission: Embedding DevRel and open source principles into the company's mission aligns everyone's efforts with fostering a collaborative and open developer community.
Is this Realistic?
You might read this and wonder if such a comprehensive approach to supporting DevRel is too idealistic, especially given companies' time constraints.
My snarky response: If that's your immediate reaction, then perhaps you're not fully invested in the success of your product.
But let's go with a less snarky take: The most successful companies with admirable DevRel teams have other departments fully backing them up. They invested early in DevRel activities, even before establishing formal DevRel teams.
Take GitHub as an example, a company where I previously worked and which, in my view, excels in DevRel. GitHub was effectively practicing DevRel long before it had a formal team. One of the first blog posts on the GitHub blog was called How to undo (almost) anything. This was written by Joshua Wehner, a software engineer and trainer at GitHub. In 2017, Mike Stowe wrote an article called A Brief History Of Developer Relations Programs: How DevRel Evolved Into Developer Communities.
In the article, Mike highlights GitHub's involvement in the developer community, "the most successful—and underrated—developer relations program belongs to a company known as GitHub, a company that hasn't invested in their program the same way as Twilio or Sendgrid has, but still boasts the largest and most active developer community…focused on grassroots approaches over extensive event strategies. That's not to say that they didn't go to events. GitHub was famous for sending their myriad of creative Lisa/Octocat stickers to conferences around the world. But that wasn't core to their strategy. Their strategy was built around community, highlighting individuals' contributions, and providing a resource developers could rely on to continue growing in their careers."
Mike also recognizes companies like StackOverflow and Twilio for their effective DevRel execution.
Another admirable example is Astro, a JavaScript metaframework. This is a startup founded in 2019 with less than 12 employees. They don't have a DevRel team (from my knowledge), yet they're popular in the JavaScript community because they:
chronicled their progress via blogs BEFORE they hit version 1.0
actively live stream and join other streams
invested in stellar documentation
made engaging and easy to follow sample applications
speak at conferences
made it easy to take existing JavaScript framework knowledge and apply it to the Astro framework. Ex: if you are a Next.js dev or a Svelte dev, it's easy to pick up Astro.
From the outside looking in, each employee at Astro is heavily involved in the developer community. Additionally, there are so many developers and developer advocates with influence that create courses and write blog posts about Astro, which helps to spread awareness.
I understand that small startups and their teams might not have the capacity to invest in DevRel activities if they're not on the DevRel team. I remember working as a Software Engineer just trying to complete my tickets. I would be overwhelmed if I also had to write blog posts. However, things changed when I joined Botany as their seventh hire. My manager cleverly carved out time within the sprint for engineers to write blog posts recapping what we learned throughout the sprint. This was done to help us retain knowledge and become more effective engineers. However, companies can take this idea and repurpose it to support DevRel initiatives. If this strategy is adopted by upper management, and they allocate the necessary resources, then non-DevRel staff can feel empowered to participate in DevRel activities without feeling overburdened.
Developer Relations is not just a team department or an isolated function. It's a philosophy that the entire organization needs to adopt. While it feels gross to say this, the company's developer community is the most valuable asset, so why not invest?
Feel free to leave a comment with deeper insights because although I do have experience, I don't have the same experiences as you all. The comments section is a space for us to learn and grow. I may only get a chance to respond to some, but I will read every comment.
Thanks for reading!
