Translations: Japanese

One of my favorite jokes about DevRel is that the First Commandment of DevRel seems to be, upon getting the job, you must then immediately turn around and create a self congratulatory blogpost/podcast/Twitter Space about "How To Get Into DevRel". Surely everyone wants to be in DevRel, yes? By 2030 no engineers will be left, tech will just be all devrels devrelling their $19 ebooks and $10 Substacks and $4.99 Super Follows to each other and we shall have achieved Universal Basic Devrel.

DevRel has Limits

On a more serious note, I was awakened to the limits of DevRel by an anecdote from a previous manager, who was told we couldn't have more headcount because "hey, you're already 10% of the company! Do more with what you have!"

Which is a very good point - there's probably an optimal proportion of devrel team sizing, similar to the now-accepted wisdom that there should be between 5-8 engineers to every engineering manager, with parallel product management, product marketing, and product design (and, if you're really fancy, product analytics) people attached in various ratios.

CommonRoom's DevRel Comp Report noted the surprisingly wide distribution of devrel team sizes:

But my ex-manager's manager's point stands; at some point, DevRel needs to stop growing.

Sidenote: In fact, you probably want DevRel headcount to scale sublinearly to both the number of your engineers at the company and to the number of customers, if you want any hope of improving profit margins in future.

Contrast this with the other empirical observation that DevRel marginal productivity declines dramatically as teams grow; the first person does a lot, the 10th person tends to do more of the same of what the first 9 did, by the time the 50th person comes along you barely know what they did all year. In other words, DevRel average productivity (however measured... that's a topic for another day) tends to decline with increasing team size, at the exact moment when you need it to go up (to scale headcount sublinearly).

So. How do you scale DevRel?

Note: this is a rhetorical question that has a longer answer than can fit in this essay; for other scaling dimensions, please see my discussion on InfraEng on going from singleton programs to language/geo/vertical split programs.

Ownership vs Enablement

One of my favorite examples to trot out is that GitHub, Snowflake and Stripe had no DevRel for their first few years of existence. They did fine, didn't they? Sure, for every one of those examples, you can find a Twilio or a Plaid where the founders strongly attribute their success to establishing a good devrel/evangelism program. But for the places without, DevRel basically was everyone else's job. Stripe was famous for the Collison Installation where Patrick and John would show up at prospective customers' offices and do the integration work for them, removing all objections and getting hands on feedback. TPW and Chris Wanstrath spoke at a bunch of Ruby meetups to get GitHub going in the early days. And so on.

To scale DevRel, DevRel should turn from an Ownership role (the buck stops here, we do everything related to DevRel) to an Enablement role (we enable everyone else to do DevRel!). I started writing about this dichotomy last year).

This seems like a shirking of responsibility until you consider other "enablement" roles, like HR. Consider that HR departments don’t actually do the hiring for individual teams. Instead, most companies have individual line managers become hiring managers, who basically have the final say. Instead of owning hiring, HR departments enable hiring managers to do hiring as part of their jobs, by building infrastructure for as much of the job as possible - buying ATS software, determining benefits, sourcing candidates, organizing onboarding, and so on.

So - to scale DevRel, we need to identify "devrel infrastructure" and provide it as a "service" to the rest of the company, and potentially our champions in the community.

Unbundling The Full Stack DevRel

The classic "it's just me" First DevRel Hire (our previous thoughts here) tends to be "full stack" - writing, speaking, workshopping, coding, interviewing, editing, planning, they do it all. This tends to be the setup for teams up to about 8 or more people - each devrel tends to be a mostly autonomous lone wolf, with perhaps natural affinities to certain user personas/communities, and natural strengths to certain kinds of content channels or deliverables within the company, but usually taking their projects from ideation to production to publication to syndication all the way from start to finish. The expectation is that if you are a good DevRel, you will have a polymathic command of all skills from editing YouTube videos to organizing the company conference to writing jokey social media memes for Fellow Kids.

But of course, no media or professional education organization operates like this, and as companies realize that they're really building a media-company-within-a-company, specialized roles start to emerge.

The simplest way I've found to think about this is by analogy to the division of labor found in the bank trading floors of my past: Front Office, Middle Office, Back Office (readers of my book will find this familiar).

• Front Office: Responsible for trade ideas and making money
• Middle Office: Responsible for assessing risk and ensuring compliance
• Back Office: Responsible for accounting and other paperwork

The usual power dynamics is that Front Office tends to be more glamorous and better paid, and status decreases the further back you go, but when things go wrong - when a mistake has been made or a limit violated, then the power inverts, and the Back/Middle Office can really hold the Front Office accountable for their mistakes.

You could adapt this 3 tier architecture for the DevRel responsibilities:

• Front Office: The Dev Advocates generating content ideas and being the public face of the company
• Middle Office: The Editors checking for tone of voice, editing video, resolving partnership/terminology/business strategy concerns, deciding content mix, calendar, and layout, providing brand assets
• Back Office: The Operations Specialists who help with post scheduling, video transcribing, interview scheduling, contractor payments etc.

The details may differ based on your chosen medium or usecase, but once you've split out the "full stack" of DevRel like that, you can really see that the "Front Office" can be expanded to more than just the people with "Dev Advocate" in their job title. If you build up the right DevRel Infrastructure, you make it easy to provide "DevRel as a Service" to the rest of the company, and even enthusiastic volunteers in your community.

Elements of DevRel Infrastructure

This is an incomplete list, but here are some DevRel Infra items that I have maintained in the past:

• Directory of example slide deck presentations
  • with metadata around when each was presented and what the purpose of the presentation was
  • made available for fellow employees to "grab n go", but also for users to "convince their boss" or present your company at their meetup
  • goal is to make it easy for others to make you look good
• Focus Lists: Reusable lists of external touchpoints we want to hit
  • List of upcoming conferences we want to appear at: together with offering office hours and speaker prep for helping engineers to speak there
  • List of industry newsletters, podcasts to appear on:
    • Be an authentic subscriber/reader/listener of them, build a relationship not just with the host but get a feel for what works for this audience.
    • Take a swing at reaching out to them when you have something good, with a goal of getting featured at least once a year.
    • You can do very well publishing this list if you're sure you've got a good one.
    • has strong overlap with the below, but focused on channels and specific content output, rather than people and long term relationship
  • List of Industry Influencers and their relationship status with the company
    • As much as nobody likes to admit it, every industry has influencers, and the relationship with them should be carefully/proactively managed
    • Useful for monitoring what people are talking about, but also useful for outreach for key product launches and inviting to events
    • Note that this is an extremely sensitive document and arguably should not be circulated in full beyond devrel/company leadership as sins of omission/commission could be costly
• The #ecosystem-news Slack Channel
  • This has been a staple at my last 3 companies - devrel is surprisingly more often attuned to what is happening in the rest of the industry where product/engineering/design may have more tunnel vision. Devrel performs a very useful function by backchanneling news and feedback from the market, even if the company's roadmap should not be dictated by reactively responding to competitors
• Video/Slide templates, assets, and editing
  • As mentioned above, figure this out and document the process to make it easy for the rest of the company to produce rich media content that is consistent with the company brand and looks high quality even by someone who doesn't spend all day futzing around in Figma

What else makes sense to add to this "infrastructure" list?