Would you die on this hill of DevRel axioms?
As DevRel (developer relations) has become more refined over the last decade, these five key points have become truths in our business.
Developer advocates and developer relations should not exist under any marketing hierarchy.
Microsoft killed off this organizational structure. Google never let it happen. AWS also insured this isn’t how DevRel operates.
DevRel is either its own branch feeding directly into the executive team under the CTO, or it is a breakout of the engineering group — usually under a VP of engineering or related structural organization.
Having developer advocates under marketing tends to bring out bad habits.
For example, they may be forced to give talks at trade shows that are just the company spiel, or cover topics that don’t align to anything — like talks on X feature that nobody uses, implemented in a way that is broken.
The end product of having developer advocates and developer relations work and report up to a marketing leadership hierarchy devalues their work and can diminish the credibility that advocates have to fight for so diligently in the first place. For further ideas around this axiom, Francine Hardaway wrote a great post on this exact issue, asking where DevRel should exist.
They need to build, show, and be technically inclined as much as any software engineer, coder, or hacker is expected to be. I’m not talking about “make nonsense deadlines and work to death” like some development teams get stuck with, but we advocates do need to build solutions that parallel or innovate on the designs in place, and in production, that give us value today. Developer relations, at its core, is meant to show the value in what X solution can do. It needs to provide examples and to take what exists in the industry and build on it.
Developer advocates need to be immersed in educating.
Often a developer relations team works closely with curriculum development. Curriculum development, the creative and regimented process of teaching product knowledge and its related ecosystem, is extremely important.
Unless you’re selling an easy button, almost every practical product or service on the planet needs at least some educational material rolled into it. We all start with no knowledge on a topic at some point, and this team’s goal is to bring a new learner from zero knowledge to well versed in the best way possible.
Developer advocates provide a two-way street of communication.
Advocates collect and bring that data back to the various teams within a company to determine actions to take. I personally love this part of the job, since I like to make sure that the development teams have the information they need to build products and services that are really needed. I’ve also never met a developer who doesn’t want to know that they’re developing in the right direction. This kind of information is invaluable for development teams and for the teams creating curriculum and documentation.
Developer advocates do not always work directly with customers, but we do communicate with them on a regular basis.
And this is as it should be.
Helping to organize discussions, conversations, and the future direction of research for product and service teams is very important. We can act as a researcher for companies that may not have enough time to put somebody on a project, and we can provide general information deducting what is or isn’t the right path to travel.
As developer advocates, we have the freedom to frequently take the path of risky research. We provide an extremely valuable service to the companies we work for, the customers we communicate with, and the industry as a whole by doing this research and making it publicly available, i.e. by blogging, for instance.
Are there other axioms you see in the industry around DevRel work? I’d be happy to put together a larger list. This is just the beginning, a part of my desire to understand how advocacy can increase its value for the company, the customer, and personal efforts.