DevRel is an antipattern
We’re going to poke a hornet’s nest. We say all of this with love and respect, especially because developer relations is filled with some of the smartest, most hard working people in our field. They have unique, cross-functional abilities and customer insight that every dev tools business needs.
And they are consistently, structurally hamstrung in doing their best work.
If we ship our org charts, what are we shipping when ‘DevRel’ is a discrete team, instead of a shared organizational imperative? We might be shipping products where feedback is thrown over a wall. We might be shipping products where challenging workflows are papered over by documentation, instead of reworked until they sing. We might ship something less than our best work, confident that there’s a team dedicated to putting a good face on it with external developers.
As you build your organization, beware the siren song of ‘DevRel.’ Instead, get specific, think about what you actually need to accomplish, what to call it, and which teams are best suited to address it. For example, if you’re under 50-100 people, documentation is really the role of product, isn’t it? Someone writing your docs should be empowered to howl at the person responsible for a clunky workflow, collaborating with them directly until both the product and its documentation make sense together.
Similarly, the folks building example projects, managing open source contributions, and otherwise engaging publicly with your code are really doing engineering work, aren’t they? Wouldn’t it be more powerful to ensure that the people closest to your external developers are attending the same meetings where API design decisions are made?
Maybe you’re asking ‘but who is supposed to go to conferences? Who is supposed to organize them?’ And that’s a great point. Eventually you’re going to reach a set of work and skills that don’t mesh easily with your earliest functions. Education and training. Events and promotions. Still, stay specific. Events sounds like developer marketing, right? Education might have the strongest claim to being an independent team, serving both sales enablement, for orgs with a sales function, and developer marketing. If so, say that.
In larger organizations, DevRel is too often a signal that core functions are drifting away from direct engagement with customers and external developers. As you build your devtools startup, think about how you can forestall that condition.
In the beginning, good relations with developers are everyone’s responsibility.
