The developer relations pendulum swings again
It’s day 11 of Blogvent, where I blog every day in December! I admit I don’t know where I want to go with this post, so I’m just going to write until I hit publish.
It feels like every 3ish years or so, there’s people saying that developer relations (or developer advocacy, or whatever you want to call it) is either essential, or expensive, or powerful, or useless. Dev rel is dying, and dev rel is thriving. So many opinions.
Now, it’s time for MY opinion!
When should I hire my first dev rel person?
Depends on your customer, depends on what you think a dev rel person can do, and depends on how much you’re going to be willing to trust that person.
If your core customers are not developers (like you have an API or something but it’s not something you’re actively using to gain more of your customers), you probably don’t need that person.
If you need someone to work on your docs, you may need a technical writer.
If you need someone to build demos for clients, you may need a solutions architect.
If you need someone to maintain a community for product retention, you may need a community manager.
If you need someone to make witty, viral content, you may need a marketer or technical content creator.
Dev rel does overlap with these things (and sometimes is these things and more), but it should be clearly defined (with success metrics!) before you throw a person into the deep end doing all of the above.
Who should I hire?
Honestly, some of the best dev advocates I’ve seen are engineers who just happen to really enjoy writing (or speaking or whatever medium they use to communicate with others), and understand the developer experience really well. Finding someone who can articulate a technical concept in a way that is understandable and clear is the key, and if I’m being honest… makes for the most fun job interviewing processes, too.
Should I hire an influencer?
Maybe. But that semi-famous person isn’t going to make your product successful if it’s not a good product. They might help you get eyes on the product initially, but it’s temporary unless you/they have a strategy to keep customers around.
If you don’t mind me wearing my smugness hat for a minute: I have warned so many companies about this. I feel like I say “I told you so” to so many startups I’ve advised over the years. Founders and leaders and VCs often love having someone on the payroll with a lot of followers because it means their product might also get a lot of followers. That doesn’t happen. I had a founder of a (now fairly large Series C) company actually DM me once saying that they wished they had listened to me on this point, saying that they had hired someone “YouTube famous” who worked so hard on their personal brand that they never really did anything for the company besides occasionally mentioning they worked there, and they had to start hiring again from the beginning.
Now, not all influencers are the same, blah blah. A lot of them are really excellent and have a following for a reason. But you shouldn’t hire them for the following.
(Hiring them for part time contract work though or for big launches to post on socials… that does seem to work pretty well for individual marketing campaigns if it’s in the budget and strategy!)
How should I structure a dev rel organization?
This is another “it depends” but I think that we did it really well when I first joined Netlify. Sarah Drasner blogged about it at the time, but as a bit of a TL;DR, we split up the org into 3 main pillars:
- Technical writing: documentation, writing tutorials, and blog posts.
- Integrations: building tools, it’s 100% engineering but building tools that make it easier for external developers to use our platform.
- Advocacy: 50% engineering, 50% marketing. We built the demos, wrote tutorials, made content, had engineering team rotations, and served as the bridge between integrations and docs.
This worked super well for us. I’m at GitHub now, and it’s a larger org that covers a much broader spectrum. There, “Developer Relations” is the overall umbrella that advocacy, open source programs, education, and more are under, and there’s even more specificity in those categories. The company very much relies on dev rel to exist, honestly, which is cool (and hectic, but still cool).
I think once again, depending on what your strategy is, that will help you determine what your organization needs in terms of structure.
In terms of where dev rel is on the org chart… I personally think that it should be its own pillar, separate from marketing and engineering and customer success, but again, it’ll depend on your strategy.
Elephant in the room: should I go into dev rel? Layoffs are happening a lot and the vibes are weird.
Ugh layoffs are happening a lot and it sucks. But, I think if you want to go into dev rel, now is the time. The companies that are hiring for developer advocates and have a good strategy for them now, of all times, are the ones that probably have a sustainable organization going. Generally. It depends, again.
When sentiment is not great about developer relations, it’s usually the result of it not being done well.
“Not being done well” can look like a lot of things. It could be that it’s not measured in a way that proves to a business it’s worthwhile. Or, it’s the result of folks trying to just sell their products at conferences rather than providing something valuable to the tech community. Or, it’s folks yearning to be famous while working for a company that’s yearning to be famous. You get it.
Developer relations isn’t dying. I think it’s going through a period right now of evolving (just like it did in the pandemic when everything went remote, and in the years before that). If you can roll with the changes in the world, and have a good strategy, you’ll be sitting pretty.
See you tomorrow!