Le dev advocacy c’est un grand mot, un peu comme le big data : un terme vague qui englobe une variété importante de pratiques. A cheval entre le marketing, le département produit & l’engineering, le dev advocate est avant tout un influenceur, une interface entre les personnes à l’extérieur de l’entreprise et les devs en interne.
William Roy, formateur chez Human Coders au dev advocacy et à la prise de parole, et Tim, dev advocate chez Algolia, nous éclairent sur le sujet.
Le dev advocacy c’est quoi ?
Tim : Tout d ‘abord toutes les boîtes n’ont pas besoin d’un·e dev advocate. Seules celles qui ont un produit à destination des devs en ont besoin.
Ensuite, pour faire simple, en tant que développeur·se on a un détecteur de bullshit élevé. On est assez peu sensibles aux techniques marketing dites « traditionnelles ». On ne va, par exemple, jamais utiliser une techno sur la base d’un article de blog et on ne se fie pas à la publicité.
Pour choisir la bonne techno à utiliser, ce qui nous intéresse c’est quand un·e ami·e ou un·e collègue nous fait un retour, nous conseille sur la base de sa propre utilisation. Ce fonctionnement de pair à pair influence notre choix de la techno à utiliser. Le dev advocacy a ce rôle de conseiller les autres devs sur le bonne techno.
Un·e dev advocate c’est donc un·e développeur·se exemplaire, qui aide les développeurs·ses sur d’autres aspects que simplement parler de son produit : il·elle est un·e « team player ». Et justement parce qu’il·elle a les mêmes problèmes que les autres, il·elle dit également quand la techno de sa boîte n’est pas adaptée au besoin.
William : Pour monter mon plan de formation, j’ai discuté avec plusieurs dev advocate qui travaillent dans la vallée (Silicon Valley, ndlr), et une chose ressort : En France on cantonne les devs derrière des écrans, alors qu’ils·elles devraient être sur le devant de la scène.
Par exemple quand une entreprise veut parler de son produit elle fait appel à des « marketeux », mais étant donné que ce n’est pas eux qui ont développés le produit ils·elles n’ont pas le côté vivant du code que seuls·es les dev ont. Pour moi être dev advocate c’est tenter de rendre justice à la techno de son entreprise, à son propre travail.
Ça consiste en quoi concrètement d’être dev advocate ?
Tim : Étant donné que c’est un métier hyper jeune, 10 ans tout au plus, chaque boîte fait ça différemment. Dans certaines boîtes ça consiste à écrire la doc, dans d’autres c’est faire le tour du monde pour faire des talks, d’autres encore c’est animer un compte Twitter, écrire des articles de blog, … Parfois tout à la fois.
Mais ce qu’il faut garder en tête c’est qu’il s’agit d’un métier basé sur la création de confiance et crédibilité auprès des devs. Ce métier c’est avant tout créer quelque chose d’humain et de personnel. C’est pour cela qu’il faut faire la balance entre le nombre de personnes qu’il est possible de contacter et la capacité à nouer des liens.
Par exemple faire la rockstar sur scène c’est sympa, mais ça ne donne pas forcément l’occasion d’échanger avec les personnes en face à face. Il n’y a pas besoin d’être mondialement connu quand on réussit dans une communauté plus locale, ou celle du langage que l’on utilise, car les personnes écoutent vraiment ce que tu dis et tu as des relations plus intéressantes.
C’est quoi les bonnes pratiques ?
Tim : Pour moi c’est s’impliquer dans les événements locaux. Par exemple, avant de travailler chez Algolia, je me suis impliqué dans plusieurs événements et meetups à Paris. Quand je suis rentré à Algolia j’y suis rentré avec tout ce réseau, et j’ai donc pu parler à ma communauté de cette solution avec légitimité.
D’ailleurs si Algolia est connu à Paris c’est aussi car nous avons beaucoup participé à des meetups, nous nous sommes connecté avec beaucoup de monde, ça a créé du buzz et les devs des boîtes ont poussés la solution en interne. Quand ce sont eux même qui poussent la techno c’est la meilleure chose possible.
De facto quand on contacte un·e client·e, ils·elles ont déjà entendu parler de nous et ça rend tout beaucoup plus facile. Ça aide aussi niveau recrutement. Par exemple beaucoup de dev ont postulé suite aux meetups car ils·elles ont été exposés à ce que nous faisons en terme de produit mais aussi en terme de culture d’entreprise.
Enfin, quand une équipe est petite, ça ne sert à rien d’avoir un·e dev advocate, ce sont aux fondateurs·rices de le faire, car ce sont eux·elles qui ont les mains dans le code. Ils·elles doivent être les défenseur·se·s de leur produit, c’est à eux·elles de faire l’évangélisation du produit.
William : Les meetups sont très importants oui. C’est pour ça qu’il faut apprendre à présenter correctement son produit au public. Par exemple un·e dev advocate ne doit pas flinguer toute une conf en cherchant à avoir raison. Ce n’est pas le but : le but c’est que le public comprenne le produit, et ait envie de l’utiliser
Dans les talks ou les salons tech, quand il s’agit de populariser une techno pour d’autres devs, le·la dev advocate doit présenter de manière propre, s’adapter à son public, ne pas être trop technique.
Comment on devient dev advocate ?
William : En pratiquant. Par exemple en s’exerçant à gérer son niveau de vocabulaire, d’abstraction, en testant les messages que l’on peut envoyer à un public large qu’il soit en école d’ingénieur ou senior.
Pour ma part, j’enseigne la prise de parole en public pour les devs. Donc j’aborde la pédagogie de la prise de parole, le format des présentations, pour faire en sorte que chacun·e ait une boîte à outils au niveau type de prise de parole.
Je donne des réflexes pour qu’à chaque prise de parole en public, ils·elles aient le bon format et la bonne structure et aient les compétences pour faire la présentation adaptée au bon public. 60% du temps de la formation est dédié à la pratique.
J’apprends aussi à correctement bouger, regarder, respirer, apprendre à avoir tort, et à répondre aux bonnes questions. C’est une vraie stratégie discursive en fait : comment gérer les points de détails, comment casser l’affect autour de sa techno pour mieux la présenter, savoir comment réagir quand on dit qu’on ne croit pas à la techno.
Pour finir mon but est simple : ce n’est pas de faire en sorte qu’à la fin de la formation les étudiant·e·s présentent comme Steve Jobs, mais de faire en sorte que demain, si on leur dit qu’ils·elles doivent présenter leur produit, ils·elles soient capables de le faire et bien, ou qu’ils·elles soient content de le faire.
William Roy forme à la prise de parole en public chez Human Coders. Si vous souhaitez en savoir plus rendez vous à ce lien : https://www.humancoders.com/formations/dev-advocate