DevRel should be a process not a project
podcast.bitreach.ioI'll be the one: what is devrel and when did it popup?
I'll have a go! DevRel is developer relations. The job involves communicating with and supporting developers. DevRel happens at companies whose customers and/or users include developers (think Twilio, GitHub, Stripe). It's an umbrella term and means different things to different companies. But some examples of things they do are: giving technical talks, writing documentation & tutorials, organising developer events, recording video tutorials. It might also include things like improving the onboarding experience. The role exists because developers working on the codebase are busy and tend not to want to spend a lot of time doing external facing work and marketing teams usually don't have the technical knowledge required. It's been around since the 1980s in some form but has been growing steadily in the last 10 years or so.
> giving technical talks, writing documentation & tutorials, organising developer events, recording video tutorials
Aside from giving talks and maybe event organization, the rest of those functions (docs, tutorials) already have roles.
The more naked truth is here:
> marketing teams usually don't have the technical knowledge required
DevRel is marketing that targets developers. They do all the things marketers do: drive adoption, control perception, pressure product teams in customer orgs, and drive product-market fit.
Just like marketers try to build champions in C-suites and pursestring-holders for sales to use to land and expand, devrel builds champions on dev teams in orgs where devs have more control or influence over budgets.
> the rest of those functions (docs, tutorials) already have roles.
Which roles have you seen docs & tutorials typically fall under?
> DevRel is marketing that targets developers.
I think this is sometimes true but DevRel often make significant contributions in areas that fall outside of marketing too (especially product)
> Which roles have you seen docs & tutorials typically fall under?
Technical writers write docs for existing users, and in larger (200-300 employee) orgs also training/education writers create tutorials and develop curricula for new and onboarding users, and content marketing writers write tutorials to demonstrate features.
These roles free up devrel to focus on community outreach/engagement, marketing content, and direct leadgen.
> DevRel often make significant contributions in areas that fall outside of marketing too (especially product)
Hopefully, so does everyone in an org capable of doing so, including the roles I mentioned above.
I don't mean to sound down on devrel, but to claim the role's focus and primary mission isn't developer-targeted marketing is rather disingenuous. It's a marketing role, usually reporting to a marketing manager, producing marketing content, with the goal of generating leads that sales can turn into revenue. That the work looks more like running or attending hackathons or giving technical talks at developer-focused events doesn't change the goals or measured outcomes.
Interesting point, I should have made the distinction on company size. Most of my knowledge comes from speaking to early stage DevRel.
I hope I'm not being disingenuous. I'm not disputing that the bottom line always comes down to growth metrics similar to marketing. My goal is to build my own DevTool so my motive is to figure out how all this stuff works.
I'll give you an example. I spoke with Brandon West who was the first DevRel at SendGrid and he said "If you're considering a DevRel job thinking about what size of company you want to join & whether you want to be on marketing, engineering, product side - because DevRel can work on all of those departments. If you want to have your hands on product, then a startup will work better than something with big efficient machinery and you're there to be the spokesperson" https://podcast.bitreach.io/episodes/the-early-stages-of-dev... from 3m5s. Throughout the whole episode the feeling I get is that everything was messy and Brandon was doing everything that needed to be done. He's like a hybrid of engineer and marketer.
You made a good point though and Brandon supports your point too - it seems to be a lot more delineated and specialised beyond the startup stage.
> That the work looks more like running or attending hackathons or giving technical talks at developer-focused events doesn't change the goals or measured outcomes.
Great point! You're right the measured goals are similar in marketing and DevRel. I guess that's the question. Is the activity of the role or the objective the defining characteristic of the role?
P.s. there are big debates in DevRel about objectives - check out swyx's great piece on it https://www.swyx.io/measuring-devrel
Thanks for sharing your thoughts, very interesting!
>It might also include things like improving the onboarding experience.
lol, maybe accidentally brutally honesty and ordering in that list of roles. Maybe I was the idiot for ever thinking the huge, lavishly lavishly paid DevRel team at Azure would result in the platform being less of a nightmare for users.
haha! I don't work in DevRel or at Azure but I can relate. I'd be curious to know who has ultimate responsibility for Developer Experience at Azure.
I used to know his name, but i doubt he stayed either. The problem with Azure and DevRel is because of teams being driven bottom-up.
Oh and they repeatedly drive away the few ppl who care enough to have a comprehensive view of the OSS/real world and internal systems. Gaslighting and behind-your-back conversations is what you can expect even if youre a mild-mannered shy quiet boy that just happens to have a fucking clue about where GCP and AWS still mop the floor.
Marketing, but done people who are (or were) technically competent and are embarrassed to tell other people they work in marketing.
It's customer relations when your users are developers.
<Every important cross-cutting concern> should be part of the culture, not a project.
Quality, security, devops, performance, observability, you name it. If you have a separate team for it, I know you're not serious about it.
You can still have a separate team for it, to monitor and/or guide the processes in the other teams. But that team should not have sole responsibility for execution, because you end up rationing the concern you claim to care about.
i winced at the part where jason basically talks about john cutler-style feature factories shipping some new beta every few months without follow thru and how it makes you fall behind on messaging despite being first to market compared to competitors. too true. and not fixable at the devrel level; its a product and eng leadership issue but a VP should be able to give that feedback and make change happen.
Well put. Our brains value novelty but that novelty has a messaging cost. As you said, it takes vision at the highest levels to pick a message and stick to it.
Vision and effort, I'd say. Feature factories are much simpler and easier than value factories.
This was great, and about a lot more than devrel. I enjoyed his comments about messaging and how you should stick with a message for at least 6 months, preferably more.
Thanks so much, really glad you enjoyed it. Yeah sticking with a message was my big takeaway too. Such a challenge when there are shiny new messages always popping up.
Is there any company out there that would treat development relationships as a project? If you are a SaaS company targeting developers surely your own developrs know what DevRel is about.
you dont even have to be a saas company targeting developers. Spotify has (well.. had.. idk how they have fared) devrel too for their apis. and i've heard of non-tech bigcos who hire INTERNAL devrel just to get their 1000's of developers educated/updated on their internal platforms
I hate the fact that "developer relations" is so cargo culted that someone calls it DevRel unironically now.
You probably haven't been exposed to it as much, but the term DevRel is as ubiquitous as DevOps, and any other buzzword from the last 10 years.
P.S.: Love all your OSS work!
do you feel the same about DevOps? or any other Dev* movement? is it somehow less legitimate because it's more touchy-feeley-people-y (its ok if it does, just have to be honest about it)?
people call themselves whatever they feel best describes their work, and work specializations develop over time in response to market demand.