Getting better at Developer Relations
Much to my own surprise, a number of people have been asking me lately how they should approach working in Developer Relations. After listening to the excellent Twitter Spaces Panel the other day, I was inspired to write down some of my thoughts on how people can refine the craft of working with their Developer Community. I hope this advice is as valuable for someone considering moving into DevRel as it is for a seasoned practitioner.
It’s important to say though, this is less me prescribing the perfect formula of being a Developer Advocate / Community Manager / pick your DevRel title, and more about what works for me, because I am far from perfect at this and have actively been trying to improve what I do. In fact, the mere writing of this is part of my process, which leads me to my first suggestion.
Create more content
What this looks like for you depends on the medium you feel most comfortable with. Some people like to write blog posts or books, others want to stream on twitch or pre-record a presentation. And some people want to churn out sample code. Whatever works. What’s important is building a better creative muscle.
Think of it like getting healthy through running. It doesn’t matter how long you run, it’s about lacing up, getting out there and forming a habit. In this case, the habit is content creation.
For me, the easiest thing tends to be written pieces. Every time I have an idea for some content, I immediately take out my phone and write it down. I’ll revisit and refine it until I have the bones of something to work with, then I’ll publish.
So write a bit, don’t worry about word count or over refining it. Just write something and share it. Next time you can write a bit more. And the time after that, and the time after that, and so on.
Soon you’ll find yourself writing/recording so much that you’re needing to edit it down, and isn’t that a great position to be in?
Be curious
I believe that in order to succeed in Developer Relations, you might not need a formal software education, but you do need to have a thirst for learning. You should be trying out new technologies regularly, even if they’re not 100% related to the platform you work with.
It can sometimes be difficult to find the time to do this. The things on your to-do list are like a gas, they’ll expand to fill the amount of time you give them. So don’t give them all of your time. Consciously make time for learning.
This doesn’t always mean doing it in your spare time. Work life balance is vital, especially once we get back to a world of traveling for events. This is professional development, and if your organization doesn’t give you time to learn, then honestly, if you can, you should start looking for one that will.
Be generous
As much as you can afford to, be generous with your time and your knowledge. People are genuinely curious and a big part of DevRel is sharing what you know.
Sometimes it’ll be about what it is that you do, sometimes it’ll be someone asking for advice about how to succeed on your platform. Sometimes people will just want to pitch you an idea for feedback. Whatever it is, make the time. Grab that coffee, give that talk, hop on that zoom.
If you make time for the various communities that you work with, then they’re more likely return that generosity when you come calling.
Be developer zero
You should constantly be putting yourself in the shoes of your community by building against the platform you work on. Before a new feature sees the light of day on your platform, your team should have built against it.
This isn’t a formal QA process. QA is an incredibly specific field with many excellent practitioners, and DevRel shouldn’t be one of them. This is about getting a feel for the feature and the APIs it exposes. Do the patterns feel right? Does the contract make sense? Is it all intuitive? These are the questions you’re trying to answer.
Perhaps most importantly for your community, you’ll be better placed to help them see the benefits of a feature if you’ve used it yourself and understand its quirks. Plus you can open source the code when you’re done and you’ve seeded the library of sample code for that feature.
Work closely with Product Managers
When I talk about being Developer Zero and the kinds of questions you should be asking when trying a new feature, what I’m really trying to give you is a list of things you should be talking to the relevant Product Manager about. Your relationship with Product Managers will be key to how effectively you can advocate for the views of the developers you serve, so cultivate them.
Ultimately, the relationship you have with your PMs will depend on your organization, but I think ideally you want to get to a place whereby PMs are actively seeking out your feedback as early as possible in the design stage of a feature. Be their trusted partner. Don’t ring their bell for every single piece of feedback. Watch for patterns in the community and surface them.
Practice Empathy
My final piece of advice is this - Be empathic with those in your community. Assume their best intent. They want to learn - after all, they raise bugs and suggest features because they share your passion for the platform you have the privilege of working on.
What seems incredibly obvious to you may well have been blocking them for hours/days/weeks.
Besides - some of the best insights I’ve learned about the products I work on have always come from the community. They offer a perspective that an insider won’t always have.
Just remember, while you may have answered the same question a million times, this is their first time asking you, and if they’re asking you, then it’s important to them. Respect that and respect them, it’s the least they deserve.
I’ll be upfront and say that I’m probably not the best at living up to these traits. And I’m not sure that anyone is 100% at all of them. Ultimately the best we can ever do is strive to improve, and that’s what I’m trying to do. I hope you feel like you’re improving too.