DevRel's Death as Zero Interest Rate Phenomenon

DevRel's Death as Zero Interest Rate Phenomenon

·

6 min read

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!