the pitfalls of devrel

author: zxstim

context

so after launching multiple devrel initiatives, grant programs, dev campaigns, and so on for the past year, i have been thinking more and more on some of the nuances of devrel strategies.

the essence of devrel

i think at the core, devrel can be split into two major activities:

1. developer marketing - this is about distribution, reach, and awareness. it's about getting the word out there and getting people to try your product.
2. developer experience - this is about creating products/platforms that are easy for developers to adopt and want to use. it's about making the developer journey as smooth as possible.

i think most devrel initiatives focus too much on the former and neglect the latter. essentially, we are spending a lot more time and resources on reaching developers (hackathons, hacker house, conferences, workshops, videos, social campaigns, etc.) than creating things that are useful to developers (sdk, api, documentation, examples, guides, tutorials, open source solutions, etc.). Or very often, the things that are created are all thought of by the core team's interests, rather than what the developer community needs or wants. there are no feedback loops, no real conversations with the developers, no actions taken based on the feedbacks.

the common pitfalls

i think there are two major pitfalls that teams often fall into.

too rushed for results

this is the most common pitfall. teams often feel that they are not doing enough or not doing it right if they are not seeing results immediately. then, to fix this, they are rushing to throw more money and people into the problem, hoping that it will work.

it can be "oh we don't have a lot of DApps, let's do a hackathon, pay them a bunch of money to build something on our platform" without really thinking if there are better ways to incentivize developers to build on their platform.

it can be "oh we are not getting a lot of traffic on our docs, let's hire a marketing agency to spread the word" without really thinking why, or could it be that your docs are useless, not helpful, not informative, or not well-written?

when teams become impatient and rush into things, they are vulnerable to being conned by grifters, sweet talkers, and so on. these scums will tell you whatever you want to hear, whatever makes you more comfortable, whatever makes you more confident to open your wallet and spend big bucks on their services.

and just to be clear, i am not saying everything must be free. i am saying that you need to be spending wisely, give the money to people who really contribute, not middlemen.

lack of community involvement

i see this as a cousin of the first pitfall. teams are so focused on their desired results that they forget to involve the community in the process. if you want the community to engage with you, you need to engage with them. it's a two-way street, the law of equivalent exchange.

often times, teams establish an echo chamber of their own, with people who think and agree with anything, never challenge the first idea, never venture out of the comfort zone, or just don't bother to actually put in the sweat equity. building a community is hard, it takes time, it takes effort, it takes resources. but it's all worth it when you see the community grow and thrive. there was this point from Monad @intern that i really like: "do things that don't scale". i think this is the core of commmunity building. you need to spend the time listening to each member, having a conversation with them, give them values that they can resonate with, solve their problems, one by one even. the thing is, you need to be consistent, you need to be persistent, you need to be patient. all these things compound over time and eventually you will see the fruits of your labor.

thinking devrel is just marketing to developers

very very wrong take. this is why many devrel teams are not technical enough. often times, upper management will hire a bunch of marketers to do devrel (especially in crypto). Or worse, trusting marketing agencies. i see all the time agencies pitching to do "developer relations" for teams, but the executors are not technical person. i have seen coding challenges made by a devrel agency but submissions are via google drive (not github/gitlab, literally uploading the whole folder to a google drive and submit the link; it's this agency called VMO Group in Vietnam, massive grift, don't use them ever). oh man, or a hackathon with 25+ teams that are all internal software teams of the "agency" (this is an IT outsourcing company larping as a devrel agency).

as mentioned above, devrel is developer marketing plus developer experience. sure, you need to build distribution, but developer is different from your average consumer. developers only listen to other developers (we are highly allergic to marketing bs). imagine having someone who has never built a DApp before to tell you on best practices. it just doesn't work. you better have the technical muscle to back it up.

hmm...

there are more but i will cap it at 3. and by the way, i am not the best devrel out there, nor i am claiming to be one. just sharing some thoughts.

learning from the best

i think we need to look beyond our crypto space to find inspiration for building a strong and thriving developer community. Lee Robinson from Vercel is seriously crushing it in this regard. i had a developer getting stuck with long compile time with nextjs, and he just dm'ed Lee asking for help. Lee didn't know the guy, but he took the time to reply, attempted to debug the issue on the spot, sent some reference materials. imagine doing this for every single DM, all day every day. this is what it takes to build Next.js into the defacto React framework (that basically most of the crypto ecosystem is using).

so...

Electric Capital's Developer Report is showing a downward trend in the number of active full time developers in the crypto space. and we are spending more money than ever on devrel. i think we need to take a step back and think about what we are doing.

hey, if you need some ideas, tag me or just check out buildstation. i think i will share some more on my lessons learned in the next article.