- Alyss Noland
Alyss Noland is Director, Product Marketing at GitHub, where she’s focused on open source community investment and helping engineering teams find success through development metrics and developer-focused research. She’s been working in tech since 2012 in various roles from Sales Engineering and Developer Advocacy to Product Marketing with companies such as GitHub, Box, Atlassian, and BigCommerce, and brings that experience as an advisor to the Heavybit portfolio.
In this post, she highlights her top “getting started” DevRel posts from her curated list of over 100 resources for early-stage teams, and why she thinks they’re important to setting you on the right path.
Several years ago, developer relations was a field of little renown and dominated by organizations like Google and Sun Microsystems. The explosion of developer tools and the investment in developer experience now spans the gamut of B2B, B2C, and B2D.
I’m often asked, “where do I start?” meaning anything from strategy and hiring to getting started as an individual contributor within developer relations. My curated bookmarks for developer relations have become an invaluable resource, covering different core areas like developer experience, documentation, metrics, and more.
What is developer advocacy
Most of us have heard of developer advocacy in 2022 but what it is, what it should be remains ephemeral. More importantly, it is for your business to define based on your needs within the community and larger market. Angie Jones wrote for the ReadMe Project on developer relations as a career path and answers to common questions she’s fielded as a Senior Director of DevRel at Applitools. I love Angie’s particular insight on this hypothetical content scenario:
The marketing team may inform me [as a developer advocate] that a new feature of the product is being released. They will build their own marketing campaign around promoting that feature. As a developer advocate, I will play with that feature, provide feedback to R&D on any improvements that should be made for the community, and will possibly produce content about the feature.
This is where the difference lies. I will only produce content if I believe it truly adds value for my community. And if I do produce content, it is void of gimmicky marketing buzzwords and instead comes from the voice of an engineer, essentially focusing on a real technical problem and demonstrating how the new feature addresses it.
This approach is applicable as a marketer and as a developer advocate. Focusing on the activities that are most useful to our audience is a critical prioritization skill in a growing business.
What challenges are common in developer relations
Developer relations is, inevitably, an umbrella term. Your audience may be SREs more than developers or you need a platform flywheel where an ecosystem is a single puzzle piece in your larger strategy. To help you navigate the unknown, Mary Thengvall, author of The Business Value of Developer Relations, shared her thoughts on the top 5 challenges faced in developer relations that can inform your organization’s approach. Her point on traditional metrics for a non-traditional team:
[M]any companies have difficulty defining where the best place is for a DevRel team within the organization. Part of this struggle comes from the fact that DevRel is a non-traditional team made up of developers, marketers, and product folks, many of whom have non-traditional backgrounds (I have a background in journalism, for instance).
Given the various backgrounds and unique tasks that DevRel is given, it can be difficult to fit these square pegs into round holes.
This particular aspect of developer relations is often repeated; it arises in how we hire, how we coach and mentor others in the space, and how we measure success. Successfully approaching this problem is critical in laying a foundation for your developer relations function.
How has developer relations changed over the pandemic
As the pandemic hit in March 2020, the outlook for what developer relations would become was uncertain. Evangelism and advocacy had had significant in-person participation, speaker engagements, running meetups, sponsoring events, et al. The message was clear: evolve (and show results) or die. Lorna Mitchell, head of devrel at Aiven, shared her thoughts and experience for digital developer relations past and future. In rethinking the paradigm around developer relations, Lorna’s lens of inclusivity resonates:
The much more inclusive nature of digital working makes a difference for DevRel as a group of people as well as for the communities we serve. Without the travel component that is "normal" in these types of roles, many more excellent humans could contribute to our efforts to reach and support more developer communities. We wouldn't have to change roles if life brings us reasons to travel less or work more flexibly.
As developer relations continue to mature as a field, we’ll need to continue these thoughtful evolutions and exploration of opportunities.
How is success measured for developer relations
When it comes to the world of OKRs and KPIs, it’s easy for developer relations to become a potluck where every department brings their own dish. How success should be measured and what sets your developer relations program up for success is alignment to long term business goals and placing them in a department with similar objectives.
Awareness may align closer with developer evangelism over advocacy. Revenue alignment will depend on sales driven, which could evolve into sales engineering, or self-serve focused on top of the funnel and requiring the support of product and marketing. Finally, developer experience and nurturing an existing community will address the bottom of the funnel and may not become an apparent need until your company has achieved some degree of product-market fit.
One of the earliest, more structured approaches I encountered to measuring the impact of developer audience work was Rob Spectre’s 2016 DevRelCon talk (and written outline) on Measuring Developer Evangelism. It’s informed by Twilio’s approach to developer outreach and education but I specifically love his framing around “where to start”:
First, do an honest assessment on where you're at with a model for data orientation maturity.
- The Force: Dirty secret - most people aren't measuring anything. If you're here, don't feel bad. You are in the majority and this is the easiest stage of the pyramid to escape.
- Data: Teams in this category have access to unfiltered, unsegmented raw tables of metrics. These are usually kept in manual spreadsheets, produce sums and averages, are prone to human error, and are updated infrequently. Folks at this level of maturity usually reference data once per quarter.
- Information: Teams in this category can get trend lines against simple filters for dimensions of the data they care about. They are usually the default settings in stock analytics platforms, can sort or order by one columns, and can take a while to compile. Crews at this level of maturity usually reference data monthly.
- Knowledge: Folks in knowledge segment their audiences to get lagging indicators of success for discrete job functions - they know whether or not a particular activity worked. The knowledge at this level is usually available only to leaders and gets looked at weekly.
- Wisdom: Very few organizations make it to the pinnacle of data orientation. These teams have well defined leading indicators of success and can reliably predict outcomes for particular outputs. Wisdom is distributed across the entire team in reliable, easy-to-read dashboards everyone on the team can see.
The metrics you might want to measure and the metrics that are possible to measure are often at odds with one another and so the best alternative, a proxy metric, must be identified. These proxies have to be frequently re-evaluated as the company continues maturing along with the data and tools available.