Le binôme PM/ Tech Lead, thérapie de couple

‍

Qu’est-ce qu’un bon binôme?

‍

Autour de la table, tout le monde hoche la tête : un bon binôme PM / Tech lead c'est un c’est:

• Un binôme qui arrive à communiquer et se mettre au niveau de son interlocuteur
• Un binôme qui avance dans la même direction
• Un binôme qui a confiance l’un dans l’autre

Car un binôme PM/Tech lead c’est souvent deux personnes venant de milieux différents et devant échanger sur des sujets parfois très techniques. Il est important de savoir se mettre au même niveau que son interlocuteur. La vulgarisation est loin d’être un exercice évident tant d’un point de vue tech que business/métier. Pourtant communiquer implique aussi de se faire comprendre. Stéphanie, Head of Product chez Kolsquare, nous explique qu’elle n’hésite pas à demander carrément un dessin en cas d’incertitude. Diane, founder de Women in Product et Lead PM freelance ajoute qu’elle a déjà passé des après-midi assise à côté de son tech lead pour comprendre des sujets.

‍

Un bon binôme c’est aussi un binôme qui avance dans la même direction.

Côté PM, il faut donner une bonne visibilité business au Tech lead dès le départ. Tout d’abord parce qu’on ne peut pas espérer de la motivation et le partage d’un objectif commun en s’engageant unilatéralement. D’autre part, parce que faire intervenir la tech trop tardivement et les mettre en bout de chaîne est une grave erreur. Le Tech lead a une perspective technique des problématiques notamment à plus long terme qu’il faut prendre en compte dès le début du développement. Exemple : «Cette feature sera développée dans d’autres pays ? Ok car dans ce cas, je ne vais pas développer de la même façon.»

Très souvent dans les entreprises, on donne des objectifs business au Produit et des objectifs fonctionnels à la Tech. C’est dangereux car les objectifs étant décorrélés, on peut créer un fossé entre les deux équipes et des directions différentes alors même que l’objectif commun reste celui du produit.

‍

Avoir une bonne communication et des objectifs communs c’est un bon début pour avoir un bon binôme mais sans confiance il sera difficile d’avancer. Chacun a son rôle et son scope de son côté : le quoi et le pourquoi incombe au Product Manager tandis que le tech lead sera plutôt positionné sur le comment et le quand. Sans confiance, on tombera inévitablement dans un climat de méfiance : «Pourquoi cette US prend 3 jours ? Cela fait beaucoup 3 jours.» ou encore le fameux «Ah, tu m’avais pas dit». On collabore ensemble pour comprendre ce qui est possible, ce qui ne l’est pas, pour anticiper ce qui sera difficile et faire les bons choix. Sans confiance mutuelle, il sera compliqué de réaliser ces tâches communes ensemble.

« For better or for worse » Et comment fait-on quand ça se passe mal ?

           Comme dans tous les couples il y a des hauts mais il peut aussi y avoir des bas. Autour de la table, les exemples fusent. Alors si vous êtes dans une situation délicate, ne vous sentez pas seuls, cela peut arriver aux meilleurs. On peut tomber sur une personne avec un caractère un peu spécial. Ou tout simplement une personne avec laquelle au niveau personnalité, ça ne collera jamais. Ou encore se retrouver dans la situation où la dette technique est devenue tellement importante que les estimations de temps dev prennent des envergures astronomiques. On pense aussi au classique retard de livraison, si redouté à annoncer aux stakeholders.

Alors comment éviter ces situations ? Il n’y a malheureusement pas de solutions miracles sans faille cependant voici quelques tips qu’on a retenu pour limiter la casse :‍

Le savoir-être 

• Se présenter personnellement en début de collaboration. Présenter sa façon de travailler, son caractère, ses particularités pour désamorcer des situations conflictuelles dès le départ. Ex : «je suis quelqu’un d’assez franc, il ne faut pas le prendre mal». Ou encore «j’envoie des emails tard le soir car j’ai mes enfants et c’est le moment idéal pour me concentrer». 
• Créer un guide de conversation avec les règles de ce qu’on peut et ne peut pas dire. Par exemple remplacer le «Tu ne m’avais pas dit.» par un «Je n’avais pas compris». A minima le guide permet de sensibiliser sur la nécessité de faire attention lorsqu'on communique négativement et déclenche de bons sujets de conversation qu’il est sain d’aborder quand la situation est détendue.

‍

Le savoir-faire et ses points d’attention particuliers

• Résorber la dette technique au fil de l’eau. Pour éviter de se retrouver avec des estimations interminables de dettes techniques il vaut mieux la travailler au fil de l’eau et donc garder du temps dans les sprints à consacrer à cette dette. Au fur et à mesure qu’on développe des story, on résorbe la dette.
• Anticiper qu’une estimation ne sera jamais vraie. Estimer est un métier à part entière, notamment en assurance nous indique Daniel, Senior Staff Engineer chez Spring.  Il nous recommande le livre « How to Measure Anything: Finding the Value of Intangibles in Business » de Douglas Hubbard afin de se rendre compte de la complexité des estimations. Finalement, l’estimation c’est des probabilités, pour être 100% exact il faudrait carrément faire des courbes et des graphiques, ce qu’on ne fera évidemment jamais à chaque user story. Attention donc avec les estimations des développeurs car, en théorie, il ne faudrait pas donner une estimation précise mais une fourchette. Par exemple, quand un développeur estime «un jour» il devrait plutôt dire «je pense que je ne pourrais pas le faire plus vite qu’en un jour et si ça pète je pourrais le faire en trois jours». Il est recommandé de discuter avec son tech lead et encourager la discussion sur les points d’incertitude, le tech lead aura généralement l’intuition des tâches plus risquées. Mais surtout pour minimiser les risques il faut prendre un peu de marge dans les timings et commencer par les features les plus importantes pour les stakeholders. Par exemple, l’authentification n’est souvent pas la fonctionnalité la plus judicieuse à développer en premier, elle ne sera pas décisive pour le produit.
• Parler régulièrement entre vous. Product Manager comme Tech lead sont régulièrement confrontés à des montagnes d’information, une bonne pratique est de mettre en place un point récurrent hebdomadaire ou mensuel pour s’assurer d’être aligné et toujours dans la même direction. 

Conclusion

En conclusion, un bon binôme PM/Tech lead est donc un binôme qui communique, partage des objectifs communs et surtout se fait confiance afin de travailler en parallèle sur leur scope respectif et collaborer efficacement sur des missions communes. Ils anticipent ensemble les difficultés comme la dette technique et l’estimation. C’est un équilibre délicat à trouver impliquant d’apprendre à se connaître et donc sans la mesure du possible avoir une relation qui peut se construire dans le temps. Investir dans cette relation devrait faire partie des priorités du Product manager comme du Tech Lead. 

‍

Merci à Amandine, Daniel, Xuan, Margot et Stéphanie pour leurs témoignages et leur partage d’expérience et un grand merci à Diane Mergui, pour l’organisation de ce meetup Women in Product!

‍

Vous avez des difficultés avec votre organisation Produit? 

Façonner son organisation produit, définir les rôles et périmètre de chacun peut être challengeant. Chez Digilityx nous avons l’habitude d’accompagner et former des équipes produits. Si vous vous reconnaissez dans cette description alors échangeons sur le sujet autour d’un café☕

‍

Discutons de votre organisation produit

‍