Developer Relations Relies on Authenticity and Trust
Economic downturns bring speculation about the death of developer relations and questions about developer relations (DevRel) business value.
One question that always remains in my group chats with fellow advocates during downturns is, “Should I get back into engineering/technical writing/teaching/product marketing?” Even when our teams aren’t impacted, it’s scary to see other companies lay off entire DevRel teams.
After 15 years in this industry, I’ve noticed companies usually cycle back to having a DevRel function. With the right structure and resources, DevRel teams fill the gaps left by traditional functions and bring unique value to their organizations. The key is empowering them to communicate authentically with developers so they can both advocate for the product and actively help improve it with real-world, unvarnished developer feedback.
Start With Trust
The number one thing DevReal teams need to succeed is developers’ trust.
Some DevRel team members come into a company having already established their own unique voices and built trust, while others do so through the company’s platform. Advocates like Jason Lengstorf, James Quick, Adrian Hajdin, and Tejas Kumar have successfully created their own platforms where they can remain authentic and partner with several companies.
Developer trust is a foundation for DevRel teams to be solution-focused advocates — which doesn’t always involve pushing the product. When DevRel is done well, it’s hard to recognize. You can’t tell whether someone is advocating for a specific product feature or authentically sharing a solution to a common problem developers face.
Companies should offer DevRel teams guidance on how to talk about the product and company publicly, but they shouldn’t overengineer what they say on their personal platforms. Let advocates focus on the impact a new product feature has on them as developers. Developers have great BS detectors and will sniff out inauthenticity right away. Once their trust is gone, it’s hard to get back.
Define Their Audience
DevRel teams also need a clear, specific understanding of their target audience to communicate authentically with developers and support specific business goals.
The audience might vary by season, event, or content format, but “developers” is always too broad. Leaders and DevRel teams should work together to identify which role level, language/framework, focus area, and product experience they want to reach. A search string we might use at Sentry is “senior+frontend developers in the React ecosystem who have never used a monitoring or observability tool before.”
It also helps to define what we want this audience to understand and what we want to do next. How will that impact our business and product? This helps DevRel teams frame conversations in a helpful way for a given group, with the ultimate goal of removing barriers to entry for the product.
GitHub is an excellent example of a company that has hired authentic, trusted developers like Kedasha Kerr and Cassidy Williams to engage with its community through events, social media, and authored content. Leadership has empowered its advocates to be authentic while staying aligned with the company’s goals.
Vercel also stands out: Lee Robinson is embedded in the developer community and brings such valuable product feedback back to engineering teams that he evolved from advocate to head of DevRel to VP of Product in just a few years.
Make Them Builders
Most DevRel teams include developers, but “develop software” isn’t always in the job description. I firmly believe this is non-negotiable: to communicate authentically with our target audiences, we need to remain their peers.
This is impossible to fake. When DevRel teams write code, we stay engaged in the community, keep in touch with developers’ challenges, and maintain our engineering skills. When we troubleshoot by leveraging DevTools, social platforms (Discord, Stack Overflow, Twitter), and AI, people in the community see us dealing with the same problems they are.
There’s no one-size-fits-all for how much time a DevRel team should spend building software. My team spends roughly 30% of our time writing code, but we don’t monitor this or set KPIs around it. Its purpose is to help us meet the rest of our KPIs, and its value shows up in everything we do.
Here’s an example: Sentry released a new User Feedback widget this year. With a couple of lines of code, users can add it to a web app and get user feedback that includes a Session Replay and other contextually relevant information. In collaboration with other marketing activities, my team included the widget in our workshops and demo apps. But when the engineering team added a feature allowing users to include a screenshot with the feedback, we were frustrated that we couldn’t modify the screenshot’s size and location.
A member of our team aligned with the team that built the widget and then opened a PR to make this improvement. This improved users’ experience on apps with the User Feedback widget and that of developers building those apps, ensuring only relevant information is included in the feedback.
Prioritize Transparency
One of the biggest values a DevRel team can bring a company is sharing candid developer feedback — including when a product misses the mark — so engineering teams can keep improving it.
Whether DevRel feels empowered to share that feedback depends significantly on a company’s broader feedback culture, especially within engineering teams. In other words, are transparent processes established for giving, receiving, and acting on feedback?
Engineering and DevRel leaders can partner to figure out what format, cadence, and channels best convey developer feedback. Again, there’s no one size fits all. Free-flowing Slack communication between DevRel and engineering teams may work well in one company, while formal quarterly presentations would be best for another.
At Sentry, we communicate openly with the engineering teams in Slack and GitHub. (Every developer has open communication on GitHub since we’re a Fair Source company.) When I was building a demo for our User Feedback feature and noticed that moving from the User Feedback to the full view of the attached Session Replay resulted in an unhelpful filtered view of the breadcrumbs, I gave the team that feedback in Slack and a fix was out within the hour. This openness and DevRel’s authenticity allow us to focus on the developer experience.
DevRel teams’ success depends on their trust and authentic communication with external developers and internal engineering teams. Leaders can maximize DevRel’s value by helping teams build and foster these.
