Work in progress
This is still a work in progress! I will be adding to this as I learn/understand more.
Hello friends! If you're reading this you're either in Developer Relations (hereafter DevRel) or are have heard the term and are curious about what we even do. Basically every conversation that begins with a "so what do you do in tech?" over the years has included a bit of a hem and haw as I've tried to navigate the tricky waters of what even the DevRel boat is, where it is headed, and how we even get anywhere (are we even in a boat?).
To be completely honest, this vagueness has always troubled me as a technical person: it is preciseness, after all, that has yielded some of my greatest successes over the years. As I have worked with others in this space I have learned a great deal about what it is that I actually do, how I go about the work, and why it is important from a business perspective.
The purpose of this handbook is to elucidate the finer points of DevRel by nailing down precisely what it is we do, how we go about the work, who is involved, and how the work is structured both in terms of people and timing.
While I may spew thoughts in an authoritative way, it is important to recognize that these are my thoughts. They may (or may not) represent the thoughts of my current or previous employers and is a work of my own doing.
I plan on updating this treatise frequently as my thinking evolves, your feedback is taken into account, and the space adapts and changes. Selfishly, I am also excited to learn more about why and how I think the way I do: I'm excited to learn along the way as well.
This writeup is intended for those who either have a DevRel organization or are getting ready to create one. Knowing you need such a practice is simple: do you actively create technology that supports or should interest developers? Are you trying to find the best way to engage that audience with directed content? Do you need the active participation of that group to make sure the technology you make actually solves important problems? Is there a developer community that you wish to create or, in the case such a one exists, to nurture and grow? Are you wondering how to structure a DevRel group or what kind of business rhythm should be followed to maximize success? These are the very questions I've had over the years and hope to answer here. If you are asking yourself any of the same questions or are struggling with how to ramp up a DevRel practice I am hoping the concepts presented will add to the clarity you are seeking.
I have worked in DevRel for over a decade. First as a Technical Evangelist, then as a Program Manager, and currently as a Developer Advocate. I currently lead the AI/ML efforts for Developer Relations at Microsoft. My background, however, is in Computer Science with an emphasis in Machine Learning. I also spent some time as an educator both in High School and College settings.
My true passion is an interesting amalgamation of technology and teaching. This intersection is precisely what drew me to DevRel: it is a practice that draws on both areas! I have also done my fair share of travel and gotten to know developers from a wide array of cultures and disciplines. Our desire (I include myself as a developer) to solve problems with technology and provide value to our customers, however, is a universal trait which pervades the community. I share in that passion and desire!
This is organized with the following sections:
Overview - preliminary discussion about purpose, a brief overview, and defining principles that the tone for the rest of the material
Three strategic DevRel priorities (what we do and how we do it):
- Create Content
- Refine Technology
- Grow Community
DevRel Structure - includes discussions about people and how they can be organized in terms of grouping as well as rhythm of business.
I have found that this is the easiest way to explain what we do in DevRel.
You have options! This can be reviewed both in sequence or in the order of importance to you. One of the greatest products of the thinking I will lay out is that I am now always able to answer the question "What do you do?" concisely and almost exactly the same way in a few short sentences. This clarity has greatly increased my ability to provide impact. It has also helped my colleagues and I to feel a sense or purpose, given our priorities, and enhanced our ability to draw specific lines around things that we do (and do not do). This clarity has greatly improved how we work across a multiplicity of teams with varied, and often competing, interests.
The first, and most important, question to answer is the why. What business purpose does DevRel serve?