...or a developer relations who?
There are many urban legends about folks working in developer relations, and some of the legends do correlate with reality more than I, a person who dedicated my whole professional experience to the craft, would like it to be.
For the fun of it, here's an exercise. Try to assemble 10 developer relations people from different companies and compare their duties. I do it every devrel meetup I host (the next #devrel Stockholm meetup is on November 28).
You've guessed it right. These people would do different things and often would have different opinions of what developer relations is ;-) Isn't it fun?
Developer evangelist or an advocate, developer success manager, customer support engineer, technical account manager, field engineer — all these job titles hide programmers, who enjoy enabling others more than writing code inside a peaceful environment of their soundproof headphones. All of them also have diverse duties, while being under a single developer relations umbrella.
How to self-check if you work in developer relations?
Does your company make a product primarily used by programmers? APIs, middlewares, game engines and all kind of developer tools find market adoption much easier if supported by a developer relations program. Sometimes these programs grow out of sales, marketing or engineering.
Yet before they do, here's a checklist:
1 - You’re helping the users of your developer-focused product to use it.
2 - You’re herding a community of programmers in any sense of this almost funny pseudo-sarcastic expression.
3 - You're writing any kind of technical documentation that is to be read by programmers.
But here's the trick. Are you enjoying it? Do you like empowering other programmers enough to spend less time becoming a better programmer yourself? That's a plot twist I'll blog on later =)
For now, here's a tentative number 4. If you’re a software developer who enjoys talking about tech on the internet or even (gasp!) live, publicly… chances are there’s a developer advocate or a technical evangelist hidden under your skin!
So according to some dude on the internet you sort of work in developer relations. Now what?
Now welcome to the club. Now life has just become more complex, as additionally to learning how to be a better programmer you may also want to learn how to be better with people, how to interact with the business, marketing and support. And how to not burnout, what is unfortunately too common in the devrel field.
My very humble opinion is that now you also may want to hang out with fellow Developer Advocates. Technical Evangelists. Customer Success Engineers. Developer Community Managers. Technical Writers. Developer Experience Managers. Sales and Support Engineers. Technical Product Owners.
Why do people from totally different industries may want to hang out together?
The answer is plain and easy: to learn from each other in the multitude of dimensions:
- folks from bigger corps are often very good at putting numbers to their travel and event work;
- API providers often can share a lot about the open-source practices and community building;
- game dev people contribute their experience of facilitating game jams (it’s hackathons for the non-game dev crowd);
- everyone even after 10 years in devrel still talks about being a good speaker and making nicer slides;
We talk career prospects, references, cool events and meetups… We discuss tools that make our lives better. We ask each other for the feedback on our content drafts. We… moan… Yes. Because everybody needs a safe space to moan instead of doing in on Facebook.
Is there a devrel event in your area?
I run non-profit devrel meetups in Stockholm and Vilnius. Then there are nice meetups in London, Paris and Munich. But probably if you ask in the comments, we'll crowdsource an event or at least a pub meetup in your area.
There's also a helpful online Slack community for devrel people. It involves a screening process to join (that I have no control of or affiliation). Getting there helped me to feel better about what I do and what I want to do. It is a decent space to ask questions, get feedback and share back some love.
Top comments (5)
Hey, nice article! About:
There is another case where product success may depend on developers. Slack, for example, is not meant to be used primarily by developers. But the apps and integrations that make Slack more valuable are implemented by them, that's why Slack has a Developer Relations program.
good catch! Also remember Facebook and Spotify. Both have devrel programs.
Here's another good catch ;-) Sometimes bigger companies repack their enterprise software to being friendlier to smaller dev studios and push it to the market via a devrel program.
So yeah, collect 10 devrel people and see how they cannot agree on what they're doing =] Jokes aside, this is one of the most popular topics on devrel meetups.
Yeah, it's a totally different field. We're used to having the "right ways" of writing software.
Python has the "pythonic" and the Zen of Python, for instance.
There's no such thing for DevRel. At least not yet... I hope there won't be. It's more human relations than logic. More heart than reason. We need this freedom. Sounds too poetic maybe, but it's real.
yeah ;-) But then we put together a data scientist, a backend dev, a sys admin. All 3 may use Python, but... you've guessed it.
At my previous job we tried to put together a Lua community, since our product used Lua for scripting. Well... it was a total failure since there was so little in common for how and what Lua is used.
So I mean, it may be fun and useful to sometimes change the angle of how one sees own industry, as there may be a bigger world behind it. Not always useful though to one's immediate interest :P
I agree. This freedom can be both a blessing and curse.
The key seems to be using and promoting standards when it gives clarity and consistency, not rigidity. And promoting freedom when it promotes constructive creativity, not clutter and confusion.
It's hard to find the balance though. And sometimes there's too much passion behind decisions, even faticism, which interferes negatively on logic and reason.