How Can DevRel Enable Engineering?
One common misconception I have noticed in my last 11 months as a DevRel professional is that too many people believe that DevRel and Engineering teams do not collaborate.
Personally, this misconception often frustrates me because, given the nature of my work, I regularly have to collaborate with our Engineering team. However, I have realized over time that this misconception arises because the tip of the DevRel iceberg that's visible to most people doesn't expose this collaboration very often.
Therefore, I will share (using my experiences) how DevRel teams contribute to the engineering work behind a product.
Can DevRel And Engineering Even Overlap? 🤔
In the last issue of this newsletter, I discussed whether people should choose a career in DevRel or not, which also covered what skills and experiences the DevRel space needs practitioners to have.
Two of the 3 Cs of DevRel, code and content (technical writing in particular), are skills that directly correlate with Engineering. At the end of the day, both the Engineering and DevRel teams are there to ensure the success of the product. Engineers build the product, and DevRel practitioners enable others to use and build with it. If the two teams don't function together, you're either building a product that isn't accessible by your developer community or one that isn't good to develop with (exceptions exist, however, they aren't very likely). In order for your product to succeed, your DevRel and Engineering teams must function as inter-dependent units and collaborate with each other.
Where Does DevRel Assist Engineering Work? 🤝
A few places where DevRel and Engineering responsibilities can overlap are:
The "Developer" in "Developer Relations' is not for naught!
DevRel teams may not be dedicated software engineers, but that does not mean they don't code. DevRel teams can often be found building new integrations to expand their product's ecosystem. I created the Auth0 OAuth2 adapter and Vonage phone authentication adapter integrations which are a part of the Appwrite core product. DevRel teams also actively build newer sample applications to decrease the friction in getting started with their product. They may also help develop and upgrade tooling within the organization to improve workflows and enhance productivity.
If the product's not easy to understand, it's not easy to use!
Reading documentation is one of the best ways for any developer to learn how to integrate a product/service into their solutions. If the documentation is incomplete or unclear, it will only increase the friction for the developer, which may push them away from using the product altogether. When Appwrite released new Cloud Functions runtimes for Java, Kotlin, .NET, and C++, I added samples for them in our Functions guide so that it would be easier for folks to get started with building the same. A significant part of DevRel responsibilities is technical content, which translates to documentation writing, too, because DevRel practitioners, being so community-facing, can often better understand their audience's pain points.
Software Testing and Feedback
If we can't eat our own dog food, how can we ship it out?
An essential part of being in DevRel is closely knowing the product we advocate for. DevRel teams often work on building sample applications and solutions, which takes them closer to their audience's perspective of the product's developer experience. During the previous Appwrite version release, I helped with QA for the Appwrite CLI to help discover and fix any issues before it was finally released to the public. Due to this reason, DevRel teams often act as User 0 for their product, getting hands-on experience building with the product before anyone else. This not only allows them to experience their audience's perspective, but also discover any bugs and issues before release and share that feedback with the Engineering team beforehand.
If you're facing trouble building, we're here to help you out!
More often than not, DevRel practitioners are active at the front line of the community. This is a tremendous responsibility as DevRel practitioners must not just be great communicators but have some technical proficiency to help the community members whenever necessary. I actively help solve Appwrite-related queries on various social media, such as Twitter, Reddit, etc., and on our Discord server. An easy entryway and support system can make all the difference for someone looking to adopt new technology, and DevRel practitioners make that happen.
Moving Forward 🤝
DevRel and Engineering teams are essential for the development and growth of any developer-focused product. Being developer friendly and serving the needs of a developer, while complementary, are separate responsibilities. If both teams work together, they can create an ecosystem that can easily achieve both these responsibilities!
Personally, having spent almost a year as a DevRel professional, I have genuinely grown to love my job and the impact it enables me to make on my colleagues, peers, and beyond. I hope that at least some of you will get a chance to experience the magic a DevRel role lets you create for budding developers around you in the near future.