• nerd_splash
  • Posts
  • The post I almost didn't publish (and why I'm glad I did)

The post I almost didn't publish (and why I'm glad I did)

When being too honest means shooting ourselves in the foot

Nerds,

I salute you from Miami, where streets are buzzing with artists, hipsters, and collectors all coming for Art Basel.

Some of my Basel favorites so far

Big brain fart

This week, I went viral on Twitter with a hot take I’d been keeping to myself for a while.

Background

For the non-crypto folks, Developer Relations (DevRel) is like marketing but for engineers. It’s creating technical tutorials, writing documentation, designing developer experiences, providing community with support, gathering feedback, organizing hackathons, etc.

Traditionally, this role has been niche to either very large companies (FAANG mostly) or those whose main product is targeted towards devs - i.e. APIs, servers, libraries, etc.

Crypto, however, tells a different story.

DevRel Jules running a technical workshop

Crypto DevRel

With 1 DevRel per ~60 engineers, we have a larger DevRel concentration than most industries.

This happens because:

  • The open source nature of smart contracts brews an underlying assumption: more developers, means more use cases, which in turn means more protocol adoption and more revenue capture potential.

  • Historically, there’s been a direct correlation between developer activity and financial speculation (ICO boom, DeFi summer, ZK and L2s, etc).

The flawed underlying assumption leading the DevRel Trap

The DevRel Trap

I’ve been working in crypto DevRel for the last half a decade and absolutely love the job. But if I’m being intellectually honest - I think DevRel has been hindering crypto’s mainstream adoption.

Why?

  • We’re too small an industry for each project to be fighting over the same engineers. There’s only ~25,000 active blockchain developers vs ~14M JavaScript engineers, for example.

  • Hiring DevRels early means the project’s narrative becomes increasingly technical too early on, driving non-technical users away.

  • We’re building developer communities before we reach product-market fit ourselves, which means the audience is not there by the time we attract the engineers to our community.

  • Because the demand for our product hasn’t yet been validated, the devs we attract end up building products no one uses - not attracting the use cases or adoption we originally hired DevRels for.

The Response

As a DevRel myself, you can see why this was hard to post.

I’d been holding onto this piece for almost a month before gaining up the courage to publish it. I felt like I was shooting myself on the foot.

However, a few lessons have come from this:

  • Intellectual honesty is always appreciated, even when people may disagree.

  • People respect it when we share from our experiences. We’re all craving the personal view point - it’s why influencers do so well.

  • I’ve been receiving job offers, invites to panels, and screenshots from conversation sparked internally at companies. When we’re most afraid to post, is probably when it matters most.

  • I went through several drafts, before reaching this final piece. Friends, colleagues, and AI are all key to making a piece crisp. However, what matters most is to just publish.

As I dive into what’s next for me career-wise, I keep thinking about my lessons as DevRel - a role that taught me so much about product, growth, engineering, and project management.

As BTC hits 100k this week, I hope crypto is ready for what’s coming. I believe in the technology’s potentially, but it’s up to us to provide value beyond financial speculation.

As always, thank you for reading. Love connecting over juicy ideas.

If any of these resonate (or even if you disagree), reply to this email and would love to chat!

See you in cyberspace,

Jules 🤸🏻

Reply

or to participate.