I think, therefore I YAML

On the purpose of Developer Relations

What even is Developer Relations? Compared to roles like Software Engineering, or even Product Management, DevRel may seem a bit abstract: rather than concrete deliverables like product features, we DevRel types traffic in themes, trends, and notions. We’re often opinionated but rarely prescriptive. Sometimes it starts to get a bit… philosophical.

Indeed, this is a useful way to describe much of what we do. Philosophy can be thought of as the act of generating hypotheses—What is our world? Why is our world? Could it be <insert crazy idea here>?—for Science to evaluate. Philosophy can do this in a way that Science can’t, because while Science offers a magnificent technique for testing hypotheses, it isn’t really in the business of creating hypotheses (cf. Newton). Philosophy expansively generates possible realities; Science systematically proves (or, more accurately, disproves) them. Note that this is a distinction between activities, not between people: everyone is a Philosopher, and everyone is a Scientist. And an Artist, and an Engineer, and a Dreamer, and a Skeptic, and so on.

Within tech, DevRel provides that philosophical source material: DevRel generates hypotheses for Product teams to test. (Or UX Research teams, or Developer Marketing teams, etc.) We listen to users, collectively iterate on ideas, and speculate. Through this process, DevRel can offer glimmers of ideas that might be true: patterns or practices that may not yet be widespread, but which might prove valuable to lots of people. But is it data? In fact, it is: an anecdote is a data set with an N of one. That’s a lot more than zero! Anecdotes help focus our attention from “what the heck should we build?” to “here’s some thoughts.” DevRel’s loose, abstract approach can be very efficient at generating hypotheses, to feed the experimental machinery, which uses more structured, deliberate methods.

Experiments? Yes. The process of building and releasing products is an inherently experimental one: We don’t know if users are going to like it. But we have a hunch! Some hunches are better than others, and the best ones are grounded in observation. DevRellers are uniquely positioned, out among the user community, to pick up early signals and build good hunches. And of course, just like every Scientist is a Philosopher, every Engineer is a DevReller, when they attune their perception toward users and communities.

DevRel generates hypotheses for Product teams to test

This is only a partial answer to the question of “Why DevRel?”—DevRel nurtures many other channels through which ideas can flow. The one I’ve described is inbound. Another is the outbound dissemination of ideas: speaking at a conference or producing a tutorial video. Yet another is the act of connecting those with expertise to those who need it—Emily Freeman aptly describes this as being a “human router.” All are conduits for information and ideas, all interconnected.

Where will technology take us next? Nobody knows for sure. So we’ll keep grasping at the murky shadows on the wall of our cave, seeking possible paths toward the light of great products and happy users.