4 Discovered Axioms of #DevRel

The idea of DevRel, or developer relations, and the position of developer advocates in the industry have become more defined in the last decade than they ever have been. In getting to this era, several key points have arisen that are now practically axioms. Some people don't agree with all of these (and I'd infer that they're probably just wrong). The vast majority in the industry, and specifically those working in DevRel, would defend these statements more often than not — or even march up on the hill to fight for them!

1. 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 also wrote a great post on this exact issue, asking where DevRel should exist.
2. DevRel & developer advocates need to be self-disciplined. 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, in production, and giving 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.
3. Developer advocates serve a two-way street of communication — one to developers and users, and one back to the internal engineers, product, and leadership working on building products and services. Advocates collect, or as I sometimes call it, perform reconnoiter or reconnaissance, 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, and will get the most bang for the buck. I've also never met a developer who doesn't want to know that the direction they're developing in is the right direction. This kind of direct data is an invaluable information base for development teams.
4. Developer advocates do not always work directly with customers, but we do indeed communicate with them on a regular basis. This is as it should be. Helping to organize discussions, conversations, and future directions 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 it!).

Got any more axioms you see in the industry around DevRel work? I'd be happy to put together a larger list. This is just the beginning, as I take the first steps into understanding how advocacy can increase its value for the company, the customer, and personal efforts.