- Developer Relations ou Developer Advocacy
→ un rôle qui existe principalement dans les entreprises dont le marché cible est composé de développeurs
→ il consiste à mener des activités comme créer une communauté, produire du contenu ou améliorer l’expérience développeur du produit afin de faire connaître un produit ou une technologie auprès des développeurs
Les 3 types de DevRel
- Community Builder : un DevRel centré sur la communauté
- rôle consistant à créer une communauté de développeurs
- faire en sorte que les développeurs en retirent quelque chose en organisant des événements, en faisant du live streaming, en animant Slack/Discord et en échangeant des retours
- Developer Educator : un DevRel centré sur le contenu
- faire connaître le produit à travers des articles ou des présentations
- blogs, vidéos, ateliers, podcasts, tweets, etc.
- à court terme, gérer des promotions, ou à long terme, prendre en compte même le SEO
- DX Engineer : un DevRel centré sur le produit
- responsable de l’expérience développeur du produit (améliorer la manière dont les développeurs perçoivent le produit)
- échanger directement avec les développeurs et améliorer la documentation ainsi que les guides en fonction de leurs retours
- travailler aussi sur des exemples de code, des templates et des intégrations
Trouver un emploi en DevRel
- c’est un domaine très en vogue
- de nombreuses startups recherchent de bons profils DevRel
- principales compétences pour postuler en DevRel
- capacités en programmation : il faut savoir coder pour pouvoir comprendre et partager le point de vue des développeurs
- capacité à construire une communauté : avoir de l’expérience dans la création et l’animation de communautés est un atout, à l’université, dans l’open source ou dans des communautés en ligne par exemple
- capacité à créer du contenu : savoir faire des présentations, tourner des vidéos YouTube, tweeter et écrire des articles de blog
Conseils pour le DevRel
- How to engage developers
- Show, don’t tell. : ne pas seulement expliquer, mais montrer (permettre d’essayer rapidement le produit)
- Features not benefits : montrer les fonctionnalités de manière intuitive et comparer avec d’autres produits.
- Be genuinely helpful : investir dans des ressources de haute qualité (documentation API, site d’aide bien maintenu, vidéos explicatives, exemples de cas d’usage, etc.). Et faire en sorte qu’il soit facile de vous contacter quand une aide supplémentaire est nécessaire
- Be Direct : bien connaître les développeurs et imaginer écrire directement à chaque personne. Cela permet de produire un contenu réellement utile plutôt qu’un discours commercial
- Think beyond the 9-to-5. : beaucoup de développeurs mènent des side projects sur des sujets variés, au travail comme en dehors
- Repurpose Content : réutiliser au maximum un même contenu. Construire un pipeline du type tweet → blog → vidéo → présentation en conférence
- Have a "breakable toy" : avoir une vraie application sur laquelle tester une nouvelle technologie et montrer des métriques après les changements. Elle doit être petite, mais réelle. Par exemple un simple tracker d’exercice, un planificateur de repas ou un outil de prise de notes. C’est encore mieux si vous avez quelques vrais utilisateurs, vous et quelques amis
- autres ressources liées au DevRel
2 commentaires
Je pense la même chose. À mesure que la culture du développement logiciel évolue, il est naturel que les types de métiers se diversifient et se spécialisent davantage. À l’avenir, au lieu de se contenter de séparer les rôles entre développement et management en se focalisant uniquement sur la création du produit, j’aimerais voir apparaître divers rôles nécessaires pour faire évoluer le produit et en assurer la promotion. C’est très positif qu’on ajoute désormais le DX à une distinction qui se limitait auparavant à DevRel/Advocate. Je ne sais pas si le fait que de nombreux membres de l’équipe DevRel de Chrome aient rejoint Spotify côté DX peut être considéré comme un bon exemple. Personnellement, cela m’intéresse beaucoup, mais les postes sont vraiment rares...
Les personnes au centre de cet article viennent pour la plupart de l’équipe DevRel de Vercel, donc c’est assez intéressant de voir un DevRel défini par une jeune startup (?) plutôt que par une organisation DevRel établie de longue date.
À l’étranger, c’est extrêmement en vogue… mais en Corée… hum… snif snif
Mais je pense que c’est un rôle absolument nécessaire.