A Framework for Developer Relations v1
Five components of DevRel
Coming up with a simple way to portray a complex system is never easy. Creating a single diagram that describes the components of Developer Relations (DevRel) and how they intersect was perhaps our greatest challenge in writing this book.
We believed it was essential to have a memorable yet straightforward design that would be:
easily understood by those new to the concept of DevRel
effective for those needing to explain DevRel to executive teams and stakeholders
and most importantly, increase the chance of adoption by our profession.
As we mention in our thesis, having a common set of frameworks and definitions is crucial for professionalizing a practice such as DevRel. After 20 years, it is high time we settle on a few.
The framework stemmed from our own experience, including several designs we had used in the past that got tossed out rather quickly. After confirming the core components, there were still several hours of debate and prototype designs. Finally, the aha moment came in the form of a tree, as shown below!
We’d love to hear your reaction to this framework - does it makes sense, does the analogy work, is there something missing?
Components of Developer Relations
The five DevRel components we include in the framework are:
Developer Marketing - includes all the outreach activities as you create awareness, and developers discover and evaluate you.
Developer Experience (DX) – includes both the product and the portal and documentation that accompany it, as a developer learns about and builds with your product, as you aim to activate and engage them.
Developer Success – includes the activities to nurture developers as they scale with you, and includes retention activities as well.
Developer Relations – sits in the heart of the tree, pulling the components together into a coherent program. This is also where the most direct contact tends to occur with developers, be in off-line or on-line, with owned or earned activities and properties.
Community – is the trunk of the tree that must stay healthy for a successful, sustainable program.
Now we know this diagram looks pretty, with all the components of equal sizing. And we also know, that you know, that rarely is DevRel that neat and tidy.
Depending on the type of organization you are in, where developer relations reports to, and the type of product you support, your tree may sway more to one side or another. We’ve seen brave souls that have to activate all of the components by themselves and progressive companies with impressive and large teams all under one developer relations canopy. We did want the diagram to clarify that the components overlap and the activities often do too.
The Developer Relations Framework is meant to be a starting point for you to understand and explain DevRel and to help you organize your own program.
We hope our Developer Relations Framework is something you can get rooted in. :-)
Let us know what you think!