The trouble with DevRel
I managed developer advocacy for Amazon’s Elastic Kubernetes Service (EKS). Several months ago, I was told that my team was being dissolved. While I was given multiple reasons for this change, I believe it happened because of ongoing confusion about our role and responsibilities, the lack of good metrics, and the growing awareness and adoption of Kubernetes.
At AWS, there is a central Developer Relations (DevRel) team. This team is aligned with marketing and advocates on behalf of different services in the AWS portfolio. They create content (videos, blogs, etc), speak at events, and run the AWS Heros and AWS Community Builders programs. My team was a service aligned developer advocacy team, in that we were aligned with a specific service. There are several teams like this at Amazon, e.g. Lambda and ECS (“serverless” containers) have their own advocacy teams. The initial impetus for creating these service aligned advocacy teams was to have better alignment with Product and Engineering and to not be solely reliant on the DevRel team for advocacy. Perhaps the biggest difference between DevRel and service aligned teams like mine was my team got involved with feature ideation, prioritization, and launches.
My team really had 4 responsibilities. The first of these was to serve as advocates for the service. For us, this meant creating content (documentation, workshops, best practices, conference talks, tutorials, videos, blogs, etc) to educate folks about the service and its distinguishing characteristics, i.e. the things that differentiate it from other services of its kind.
Our second and arguably most important responsibility was to advocate on behalf of customers by providing feedback to Product and Engineering. We did this by actively participating in communities/events where our users tended to congregate. We took this feedback, along with our own experiences as practitioners, to argue for the creation of new features or to re-prioritize certain features. As members of the EKS service team, we also got early access to features in developments and would often provide feedback prior to launch. Although we were never given the power to pull the proverbial Andon Cord, we would recommend changes if we felt the UX would hinder or slow adoption.
Thirdly, we participated in upstream open source communities like Kubernetes to a) keep abreast of upcoming changes to the project b) when applicable, represent AWS and its customer’s interests and c) to contribute. By contributing to these communities we helped sustain them while also fostering goodwill towards AWS.
Lastly, we would develop solutions to address weaknesses in the service that couldn’t be addressed by engineering in the short-term. The AWS Service Operator for Kubernetes, the precursor to the Amazon Controllers for Kubernetes, and the k8s notary admission controller are good examples of this type of work.
When the EKS advocacy team was formed, EKS was still in its infancy. Its management capabilities and its integration with other AWS services was minimal, e.g. we had a CNI that allowed you to assign IP addresses from your VPC to Pods and the aws-iam-authenticator, originally written by Heptio, allowed you to login and administer clusters with an IAM principle. There was ample opportunity to collect and provide feedback, and have an tangible impact. Another thing that worked in our favor then was relatively few people knew about Kubernetes. In those days, we spent a lot of time educating AWS employees and customers about the benefits of Kubernetes and the cloud native ecosystem. Nowadays, Kubernetes is the de facto choice for running containerized applications. It doesn’t suffer from an awareness problem or an adoption problem. The AWS field has become so well versed in Kubernetes it has been creating content that was once the realm of the advocacy team. When this happened it became relatively easy to see us as unnecessary overhead. Beyond that, the the release cadence for features slowed considerably during my tenure, diminishing the need for new and novel content.
This long preamble finally brings me to my first issue with DevRel. The roles and responsibilities of DevRel will overlap with other roles and such overlap will invariably cause tension. At AWS, content creation was never exclusively done by DevRel, but DevRel content was (and arguably still is) of better quality than content created by other teams because of DevRel’s ties to the product team and their familiarity with the product’s internals. Nevertheless, when lots of content is being created it’s easy to overlook the importance of having high quality content. Adding to this is the ongoing tension between DevRel and Product. Feature ideation and prioritization is typically seen as Product’s responsibility. Many organizations assign metrics to Product Managers around feature releases. If not managed properly, Product could see DevRel’s involvement with feature ideation and prioritization as encroaching on their territory. If this occurs, they may be reluctant to consider ideas presented by DevRel or dismiss them outright, particularly if the source of feedback originates from the long tail of the market.
The next issue I have with DevRel is the lack of good metrics and the ability to relate those metrics to things that the business cares about like profit and reducing customer churn. When I managed the advocacy team for EKS, we spent a lot of money on a service that scraped information from different systems and online communities. It allowed us to measure trending customer sentiment, the popularity of our content (number of likes, retweets, etc), trending conversations, the overall size of the community, the identification of key influencers, and how responsive we were to questions/issues posted by members of our community. As useful as those metrics were for measuring the effectiveness of my team, it was difficult to correlate these metrics to actual business metrics. It took a “leap of faith” to associate “likes” with product/feature adoption or positive customer sentiment to lower customer churn. Absent metrics that correlate to business metrics, you really need a champion who believes in the power of DevRel.
The last issue I have, and it has less to do with DevRel than EKS, is ubiquity. EKS is an extremely popular service. It doesn’t suffer from an awareness problem or an adoption problem. If you’re going to run containerized applications on AWS, you’re probably going to use EKS, warts and all.
When awareness and adoption are no longer issues, the role of DevRel needs to change. It becomes less about creating content than it does interacting with and growing the community, fostering goodwill, nurturing customers, and providing feedback. Sadly, this is hard to justify when budgets get reduced and headcount is flat. DevRel then becomes an easy target for elimination.
I wish for my sake and the sake of my team that I had magic wand that could remedy all these problems, but I don’t. Do I think the DevRel function should be standardized across the industry in a way that is complimentary to other roles? Yes. Do I think DevRel needs a set of metrics that are tied to business metrics and that are generally accepted by business leaders? Yes.
While challenges persist, I remain a firm believer in the potential of DevRel. I look forward to contributing my skills and experiences to overcoming these challenges in future roles.
