5 ms·

DevRel should be a process not a project

25 points by jackbridger 4y ago

kqr 4y ago
<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.
- tremon 4y ago
  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.
swyx 4y ago
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.
- jackbridger 4y ago
  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.
  - zihotki 4y ago
    Vision and effort, I'd say. Feature factories are much simpler and easier than value factories.
amne 4y ago
I'll be the one: what is devrel and when did it popup?
- kqr 4y ago
  It's customer relations when your users are developers.
- jackbridger 4y ago
  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.
  - trynewideas 4y ago
    > 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.
    - jackbridger 4y ago
      > 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)
ddevault 4y ago
I hate the fact that "developer relations" is so cargo culted that someone calls it DevRel unironically now.
- imiric 4y ago
  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!
- swyx 4y ago
  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.
miohtama 4y ago
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.
- swyx 4y ago
  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
mooreds 4y ago
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.
- jackbridger 4y ago
  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.

25 points by jackbridger 4y ago

kqr 4y ago

<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.

tremon 4y ago
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.

swyx 4y ago

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.

jackbridger 4y ago
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.
- zihotki 4y ago
  Vision and effort, I'd say. Feature factories are much simpler and easier than value factories.

amne 4y ago

I'll be the one: what is devrel and when did it popup?

kqr 4y ago
It's customer relations when your users are developers.
jackbridger 4y ago
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.
- trynewideas 4y ago
  > 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.
  - jackbridger 4y ago
    > 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)

ddevault 4y ago

I hate the fact that "developer relations" is so cargo culted that someone calls it DevRel unironically now.

imiric 4y ago
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!
swyx 4y ago
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.

miohtama 4y ago

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.

swyx 4y ago
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

mooreds 4y ago

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.

jackbridger 4y ago
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.