Skip to main content

Command Palette

Search for a command to run...

DevRel's Death as Zero Interest Rate Phenomenon

Updated
6 min read
DevRel's Death as Zero Interest Rate Phenomenon
S

Writer & Curator, DX.Tips

Discussions on Hacker News and Twitter and Changelog and Twitter (especially Emily Freeman. We did a 1hr podcast conversation on the Changelog as well and something is coming on Software Defined Talk. Did you know we have a Twitter and Newsletter?)


In the last 6 months more and more people have been saying the quiet part out loud: "Is Devrel dead?".

To prove Betteridge's Law true:

  • SF Devrel hiring demand is more intense than I can remember in my career (not exaggerating, if you are a competent devrel who can move to SF I can get you 3 interviews tomorrow),

  • devrel continues to play an important role in developer awareness and education at small and big (MSFT, AWS, OpenAI, Anthropic) companies

  • I think the question is the wrong one to ask because the "Jobs To Be Done" of DevRel are timeless needs (literally everybody agrees on this, it's pointless to elaborate).

I prefer to think of the Devrel excesses of 2020-2022 (example) as a "Zero Interest Rate Phenomenon", and that we are now seeing a relative right-sizing of expectations, one that perhaps has a lot more room to go.

Let us review the evidence:

  • The 2023 industry CommonRoom survey reported 26% of respondents experiencing layoffs (perhaps absorbed by the 30% of respondents whose teams have grown) - with 7.5% fewer respondents on an admittedly small sample size. Compensation is down mostly due to a freefall in the junior ranks.

  • DevRelCon is getting crickets (still doing important work for the industry and publishing high quality video and creating meaningful connections, but attention has objectively declined)

  • To the extent that DevRel serves to aggregate and maybe induce demand from other developers, if the overall developer/SaaS market is down, then devrel demand will go down through no fault of its own. We have some evidence of this. Although arguably devtools should have some countercyclical demand because the desire to build (in the "build vs buy" equation) goes down, in practice the overall demand deflation overrides the build-to-buy demand shift.

  • DevRel is now a bad word. Conferences with too-high developer advocate load will be shamed out of existence

To top this all off, "winning" devtools that succeeded in the last 3 years with ~no/minimal devrel staff like Tailwind CSS (which did have and laid off Simon), PlanetScale (which did have and laid off Aaron), and LangChain (whose Lance Martin doesn't have the title but does the job), on top of pre-ZIRP examples we already knew as devrel counter-case-studies (Stripe, Snowflake). (Sidenote: difficult to draw conclusions from this because all 3 have celebrity CEOs who have the "it" factor many other founders do not; so it makes more sense for "non-celebrity" CEOs to hire devrel to complement their weaknesses than to overfit the selection bias here. For example, Supabase hired and prioritized devrel early, despite having memelord founders. Have to judge which role model your situation is closest to).

Though macro factors definitely caused the huge +200%/-30% swings in the last 4 years, we should not exonerate ourselves from the bad behavior during ZIRP that contributed to a crisis of confidence in devrel.

ZIRP DevRel Smells

Trying to write down what we saw in ZIRP, for future readers to learn from, as gently as possible to anonymize specific stories (incl my own):

  • Early Stage ZIRP DevRel

    • Lack of intensity: Being fine with ~2 blogposts a month (if that) as net visible output (should be closer to 4 at least, and only reduce quantity if high confidence of bigger quality/impact)

    • Lack of depth: Recruiting Content (eg "day in the life at {company}", less so "here's some hard technical stuff we shipped") counting as valid output. More reasonable: nonstop 101s and Hello World's - dealing with Eternal September is part of the job for devrel, but staying there is a trap and a sign of coasting

    • Twitter-only devrel (Twitter is echo chamber, the least-sticky third of the top of funnel, etc)

    • Free-tier devrel (aka only promoting free tier, has no idea what the paid offerings are, has no idea pain points of paying customers. this is much more reasonable if company is COSS core as a strategy and you are promoting the OSS as an industry standard for adoption)

    • Meta-devrel > devrel: teaching others how to get into, run, or execute devrel as their biggest and best known activity (eg holding twitter spaces about it lmao)

    • Devrel management (if exists) purely managing (aka being pure people manager-therapist-"unblocker" rather than player-coach-leader)

    • Letting employees work on personal platform (book, youtube, twitch stream) on company time because they briefly mention company

    • ~no OKRs or OKRs change every quarter so nobody remembers what they are

    • Rest of company has no idea what devrel is working on, just sees them traveling and tweeting a lot, does not intrinsically approach devrel for product feedback and launch help without management reminding them

    • DevRel has not aligned pitch with CEO, has not fully read docs, hasn't talked to biggest company champion customers, or other signs of insufficiently "doing the work", before going out and being a representative of the company

    • Driven by individual devrel personality rather than overall company/product messaging/features

    • Hiring devrel with no prior SWE experience (I agree not a hard requirement, but this % definitely shot up higher than warranted during ZIRP)

    • Traveling to >6 conferences a year (if traveling, each conference costs ~1.5weeks of productivity. this is why being in SF helps. also it tends to be the case that there are really only <5 conferences a year to sufficiently ensure mindshare in an industry)

  • Late Stage ZIRP Devrel

    • Performative overaccountability: Trying to instrument and measure every little youtube view and github star as though it matters

    • Unvalidated Process: Establishing content calendar despite lack of evidence that it helps create more compelling content

    • Company conference/Launch week without Product/Eng buy-in: without extremely committed Product/Eng support, a devrel-led company conference/launch week will flop because there is only so much alpha/substance a devrel org can produce on its own

    • Pivot to Dev Marketing/GTM: Sudden discovery that Webinars are Surprisingly Effective Actually for serious buyers

    • Sudden discovery that there are more developers on LinkedIn than Twitter

    • Consecutive ~1yr tenures (both on the employee and employer side)

    • "Good" devrel shipping and dipping

    • will fill in more as I think of them, I am timeboxing this piece

DevRel Post ZIRP

I don't want to end this piece just on a negative note. As mentioned, there is still a lot of demand for the "Jobs to Be Done" of DevRel even if early 2020's DevRel is now over:

  1. it is a difficult job to do well and most people doing the other jobs don't have ALL those skills

  1. there is a heavy mental/emotional toll to any public facing job coming from 2-way cognitive dissonance

  1. engineers need enablement

  1. the "all-in-one" devrel at one size does not scale to the next size

Accordingly there is a lot of thinking about the needed evolution of DevRel to stay relevant, from LeeRob, SamJulien, or myself.

All I know is that ZIRP DevRel is dead, and it's thankfully finally okay to say it out loud, and perhaps we all have something to learn from our collective industry excesses.

Note: Following this piece we've started publishing more "where should DevRel go post ZIRP" type takes from others. Starting with Omar from HuggingFace!

G

블로그뉴스 blog news Starting a news blog can be a great way to share information and connect with readers.

T

There are so many yeps, uh huh, that's accurate, oh yeah, for sure, as I was reading this.

I have almost completely stepped away from creating DevRel content like I used to. Today's content is all about making friends and going to events—about 2% of what DevRel should be doing. Companies looking to hire a dev advocate and no strategic leader have also contributed to this. As your blog post outlines, DevRel is not an easy role to do when done well, and companies seem to think it's a one-person role.

It's a strategic adventure, not a role. I'm working with a client as a fractional dev GTM leader. We're working on sales processes and pitches, pricing, product roadmap, API improvements, support deflection and enhancement, and eventually, dev campaigns. I'm not writing blog posts and hanging with my peers; that time may come to do some of that, but it will be the smallest sliver of my impactful work. And it will follow all the strategic prep work that needs to go into serving developers as an audience.

You can contract someone to write you blog posts and attend events to make friends. Give them the scope of work, and consider it done.

DevRel is about ensuring the company and product are prepared for a dev GTM motion and that all the right resources, platforms, and needs are met for them to do so.

How do we save DevRel from this demise?!

11
L

DevRel is about ensuring the company and product are prepared for a dev GTM motion and that all the right resources, platforms, and needs are met for them to do so.

Never thought about DevRel like so. Thanks for the insightful comment

L

Very informative read ✨

1