Article original : How to Amplify your DevRel Partnerships Inside and Outside your Company
Par David Nugent
À eux trois, les cofondateurs de Orbit ont des décennies d'expérience en ingénierie et en relations avec les développeurs, construisant des produits dans des entreprises telles qu'Accenture, Algolia, Apple et Keen.io. Après avoir lancé Orbit, ils ont passé la dernière année à discuter avec des personnes dans le domaine DevRel sur la preuve de la valeur de DevRel.
Janvier est un moment courant pour les dirigeants de demander quels types d'investissements ils devraient faire dans les relations avec les développeurs, y compris les embauches à faire et le cas d'affaires.
Après l'adhésion d'Orbit à Heavybit le mois dernier, je me suis entretenu avec Josh, Patrick et Dustin pour parler de leur approche de DevRel, des partenariats et promotions à l'externalisation et aux métriques.
Table des matières
- Quelles sont les plus grandes erreurs que commettent les entreprises en matière de DevRel ?
- Quelles parties de DevRel les entreprises devraient-elles externaliser ?
- Comment tirer parti des partenariats ?
- Comment DevRel peut-il s'associer au développement commercial ?
- Comment équilibrer création et promotion ?
- Qui dans DevRel aimeriez-vous mettre en avant ?
Q : Quelles sont les plus grandes erreurs que commettent les entreprises en matière de DevRel ?
Une grande erreur est d'essayer d'embaucher un défenseur des développeurs avant que l'entreprise n'ait appris à faire au moins un peu de DevRel par elle-même. Dans le monde du conseil, des entreprises venaient vers nous et disaient "nous sommes prêts à embaucher, nous avons juste besoin d'aide pour rédiger une description de poste et trouver des candidats." À ce stade, parfois ces entreprises n'avaient pas donné de conférence ou créé de contenu destiné aux développeurs.
En revanche, dans certaines entreprises, chaque ingénieur fait un aspect de DevRel dès le début de l'entreprise, comme donner des conférences et contribuer à des projets. Si une entreprise essaie d'embaucher un rôle spécifique à DevRel mais n'a pas d'expérience dans ce domaine, il sera difficile pour elle de réussir.
Les entreprises et les équipes doivent définir leurs attentes internes pour DevRel. Il est courant de lire une description de poste pour DevRel qui n'est pas focalisée -- elle pourrait couvrir des dizaines d'activités clés ! Si une entreprise a fait du DevRel elle-même, elle produit généralement une description de poste plus ciblée. Par exemple, voient-ils ce rôle sur la route donner des conférences, ou être un défenseur interne ? Nous voulons aider les entreprises à éviter de rédiger des descriptions de poste qui sont "soyez tout à la fois".
Q : Quelles parties de DevRel les entreprises devraient-elles garder en interne, par opposition à l'externalisation ?
Cela dépend des parties du processus DevRel pour lesquelles vous avez besoin d'aide.
D'une part, votre personne DevRel qui a les points de contact avec la communauté -- cette personne devrait vivre et respirer à l'intérieur de votre organisation et incarner la culture de l'organisation. Si une entreprise a contracté avec une firme externe, vous n'aurez peut-être pas la même expérience en leur parlant, par opposition à parler avec des employés intégrés dans la culture de l'entreprise.
Si votre défenseur reflète vos valeurs, cela conduit à une meilleure expérience développeur. C'est un risque lorsque vous faites une embauche contractuelle, surtout du côté de la communauté. J'ai vu des contractuels faire des médias sociaux pour une communauté de développeurs d'une entreprise et tout se passe mal -- c'est incroyable pourquoi les entreprises font cela avec peu de formation et de supervision.
Cependant, si vous travaillez uniquement sur du contenu, des tutoriels, etc., cela peut être un excellent endroit pour obtenir de l'aide extérieure, puisque d'autres personnes dans l'organisation examineront le contenu pour s'assurer qu'il est en ligne avec le positionnement et les valeurs de l'entreprise.
Nous avons consulté pendant l'année dernière, donc nous avons un certain biais ici, mais l'utilisation de sociétés extérieures pour générer du contenu stratégique tiers peut vous donner beaucoup de levier. Elles peuvent s'appuyer sur vos équipes internes pour amplifier le contenu et apporter les messages sur le marché. Nous avons fait cela à plusieurs reprises avec différentes entreprises -- cela fait sentir aux défenseurs des développeurs à l'intérieur de l'entreprise comme des super-héros parce qu'ils ont beaucoup de contenu qu'ils peuvent partager avec la communauté.
Q : Comment pouvons-nous, dans les relations avec les développeurs, tirer parti des partenariats internes pour augmenter notre portée et notre efficacité ?
Nous pensons que les partenariats peuvent être l'une des parties les plus impactantes d'une stratégie DevRel réussie. Un seul défenseur ou une équipe DevRel sert de multiplicateur de force dans toute l'entreprise. Les impacts internes d'une équipe qui fonctionne bien sont énormes lorsqu'ils sont multipliés dans toute l'entreprise.
Nous pouvons donner des tonnes d'exemples, mais pour nous concentrer sur quelques-uns : en marketing, DevRel peut aider à garder la voix de la marque fidèle à la personnalité des développeurs. En retour, le marketing aide DevRel à être plus axé sur les données, créant de la valeur dans les deux directions.
Dans les grandes entreprises, il y a une opportunité d'apporter la voix des développeurs dans les conversations internes. Vous pouvez imaginer apporter des histoires du terrain à l'intérieur des murs du bâtiment et donner à l'entreprise un aperçu de la manière dont les développeurs interagissent avec votre produit.
Historiquement, il y a eu un certain décalage entre des équipes comme les ventes et le marketing et des équipes communautaires comme DevRel. Souvent, cela est basé sur un décalage dans les entonnoirs.
DevRel peut évangéliser des modèles alternatifs de mesure de l'impact de la communauté au lieu du modèle standard de pousser les gens dans un entonnoir et de mesurer les événements d'achat. Le modèle Orbit vous permet de réorganiser la façon dont les entreprises pensent à la communauté, pas seulement un entonnoir marketing standard, mais vous permettant de créer des métriques autour de vos efforts communautaires.
Nous voyons également DevRel et les Ventes travailler bien ensemble -- historiquement, ce n'est pas toujours le cas ! Nous avons vu qu'ils peuvent être très collaboratifs et complémentaires lorsqu'il y a une communication claire.
Dans les grandes organisations, c'est génial de voir des développeurs individuels participer à la communauté -- si les développeurs d'une entreprise contribuent à votre projet, c'est un fort signal que l'entreprise peut être intéressée par une relation commerciale.
D'un point de vue commercial, vous ne voulez probablement pas qu'un SDR envoie un e-mail à ces développeurs, mais le SDR aimerait avoir des commentaires sur l'activité de ce développeur qu'il pourrait mentionner lorsqu'il appelle le responsable du développeur. Bien sûr, cela nécessite des données et des outils en back-end pour faire remonter ces informations, et c'est quelque chose que nous voyons de nombreuses entreprises adopter en 2020.
Nous avons même écrit une série complète pour Heavybit couvrant différentes tactiques pour la collaboration interne.
Q : Et le développement commercial -- où se trouvent les opportunités pour les équipes de relations avec les développeurs de s'associer là-bas ?
Les partenariats avec des agences viennent rapidement à l'esprit. Pour les entreprises avec une plateforme axée sur les développeurs, une partie du modèle BizDev est de s'associer avec des agences qui peuvent intégrer la plateforme dans des produits pour les clients. Algolia avait des relations avec des agences mettant en œuvre toutes les différentes plateformes de commerce électronique et CMS.
Créer des partenariats formels avec ces entreprises peut être utile pour BizDev mais peut également aider votre programme DevRel en encourageant les développeurs de l'agence à être impliqués dans l'écosystème technologique.
DevRel peut également s'associer avec des entreprises et des projets complémentaires. Cela peut garder les choses fraîches et s'assurer que vous ne parlez pas trop de vous-même et de vos produits -- vous apportez quelques voix fraîches dans la conversation.
Q : Où tracez-vous la ligne sur la création de nouveaux actifs, tels que du contenu et des conférences, et la promotion de ces actifs ? 100 % de votre budget DevRel devrait-il aller à la création, 100 % à la publicité, ou quelque part entre les deux ?
En regardant DevRel dans son ensemble, généralement nous pensons que plus de réutilisation serait intelligent. Écrire une nouvelle présentation chaque fois que vous donnez une conférence est très coûteux en termes d'efforts et d'énergie mentale.
De nombreux défenseurs des développeurs hésitent à réutiliser du matériel, mais ils ne devraient pas -- il y a des millions de développeurs qui n'ont pas vu votre présentation auparavant. Si les comédiens de stand-up peuvent réutiliser les mêmes blagues pendant des années, vous ne devriez pas avoir à vous soucier de donner la même conférence deux fois dans la même ville.
Un truc que j'ai : donnez des conférences aux ingénieurs à l'intérieur de l'entreprise, puis laissez les ingénieurs donner cette conférence ailleurs. Rendez vos actifs et présentations de sorte que d'autres puissent réutiliser le deck et le script. C'est une belle façon d'obtenir l'engagement dans l'effort DevRel de la part des autres dans l'organisation -- trois mois plus tard, quelqu'un parle sur scène, peut-être pour la première fois.
Souvent, il y a des ingénieurs à l'intérieur de votre entreprise qui veulent commencer à donner des conférences, et en tant que défenseurs des développeurs qui font cela plusieurs fois par semaine, nous pouvons faciliter ces ingénieurs et également couvrir plus de territoire. (Il y a beaucoup d'événements auxquels je veux parler, mais je ne peux pas être à deux endroits en même temps.)
Q : Y a-t-il quelqu'un dans DevRel qui fait un travail amazing, que vous aimeriez mettre en avant ?
- Doron Sherman, VP DevRel chez Cloudinary a un excellent programme DevRel
- Stefan Judis chez Twilio pour être axé sur les données, il a une approche et un tableau de bord pour son contenu qui est assez impressionnant
- Tim Berglund et Ale Murray, équipe Confluent
Merci à Josh Dzielak, Patrick Woods et Dustin Larimer pour avoir discuté avec moi de leur expérience DevRel.
Prochaines étapes :
- Suivez Orbit sur Twitter
- Consultez (littéralement, vous pouvez le consulter) le dépôt GitHub du modèle Orbit
- Rattrapez-vous avec le blog DevRel d'Orbit.