Developer culture is built on healthy cynicism.
Marketing communication is about building narratives that, at times, have little to do with the product’s attributes.
It’s the difference between the black and white reality of a passing test-suite and selling otherwise undifferentiated shampoos based on lifestyle aspiration, price or scent.
No surprise, then, that clashes can occur between marketers and developers.
This isn’t to take away from marketers or marketing: some of our industry’s most creative and talented people build and sow marketing narratives. It does highlight a disconnect, though: developers don’t want stories, they want to know if your product solves their problem.
That’s why developer relations has largely been a developer to developer thing. Developers grok developers.
So, what makes developers special? If marketing works for selling to other parts of an organisation then why can’t it work for developers?
It’s not that marketing is never appropriate for products aimed at developers. For example, marketing can help to get our software the level of awareness where developers are willing to think about how it compares to other options.
When we get to technical detail, though, marketing can become too fuzzy or one-sided. Software is differentiated by things we can test — up-time, lag, and so on — and that require experience to understand.
If you claim your distributed database won’t lose data, you’re inviting someone to run Jepsen against it and prove in precisely which circumstances it does lose data. The problem isn’t, perhaps, that the database lost data in some corner-case scenario but that the claim was demonstrably untrue.
There are technical and product marketers who focus on precisely that type of detail. Nonetheless, their output tends to be in the form of white papers, benchmarketing, blog posts and conference talks usually covering the product’s advantages in the abstract.
Unlike marketing, developer relations should be an honest conversation between peers. In developer relations, the goal isn’t to sell but to build community and solve problems.
Sure, it just happens that those problems can be solved with the product you represent but almost all advocates/evangelists will go out of their way to be an honest advisor. After all, a developer advocate’s greatest asset is her/his credibility.
Recently, marketing departments have taken an interest in marketing to developers, giving rise to business to developer marketing.
The term “business to developer marketing” frames developers as just another segment to target. If your business depends on attracting and interesting developers, you can’t make that mistake.
That developer culture of cynicism, and the technical expertise necessary to understand and communicate the problems you’re solving, demands an approach that’s removed from traditional marketing.
Developer relations builds on what developers have been doing pretty much forever: sharing an authentic passion for tech that excites them. Ultimately, it is developer to developer, not marketer to developer.
If you’re thinking in terms of business to developer marketing then you’ve got the power dynamic the wrong way round. Yours is one of thousands of tools looking to attract the attention of developers and so its down to you to meet those developers on their terms.
Developer relations means playing the long-game. You need to build awareness, community, education and none of it will mean a thing if your product’s not up to scratch.
That’s not to say marketers can’t make the shift to developer relations but to do a good job it takes more than cargo-culting meet-ups, hackathons and forums. Developer relations is about living in developer culture, empathising with developers and understanding the tech.
So, let’s move quickly past B2D marketing and get back to developer relations.
Liz Couto previews her DevRelCon London talk on content marketing for developer audiences.
How can usability testing improve developer experiences?
SendGrid’s Matt Bernier shares his five tips for collaboration between dev rel and product teams.