- Le dirigeant engineering d’Apple Michael Lopp souligne que, dans une époque où l’on peut créer des produits rapidement, les opérations centrées sur les personnes et la qualité du jugement deviennent encore plus importantes
- « Qui prend les décisions, et comment ces décisions sont-elles exécutées ? » : c’est là la véritable essence de l’ingénierie
- Plus que la capacité à écrire du code, une organisation centrée sur les personnes et le leadership déterminent la performance d’une équipe
- En s’appuyant sur son expérience dans des environnements variés comme Borland, Netscape, Palantir et Slack, il présente concrètement la structure organisationnelle, la culture de collaboration et les compétences clés du leadership
- Plutôt que sur le leadership technique, il met l’accent sur le fonctionnement de l’organisation, la collaboration entre les personnes et la compréhension de l’humain
- Cette interview ne se limite pas à une discussion technique : elle se concentre sur la conception d’organisations d’ingénierie durables et efficaces, et propose des conseils concrets aux fondateurs et aux responsables techniques sur la relation avec les équipes produit, les compétences centrées sur l’humain et les qualités d’un bon leader
Comment concevoir la structure d’une organisation d’ingénierie
- Même dans des secteurs différents, il identifie comme facteurs communs de réussite la confiance dans l’ingénierie, une croissance rapide et le recrutement de talents intelligents
- Sur cette base, il propose trois conseils pratiques pour concevoir une organisation d’ingénierie performante
Conseil n°1 : encourager le « Wolf Time »
- Répartir le temps des ingénieurs en 71 % de travail concret / 29 % de temps libre de création
- Les 29 % correspondent à un « temps impossible à mesurer et inutile à justifier », un espace où grandissent créativité et spontanéité
- Chez Palantir, la tentative de formalisation a échoué → mieux vaut un encouragement informel et une bonne communication qu’un cadre trop formel
- Exemple : proposer un moment informel de partage d’idées chaque vendredi
> « Si les membres de l’équipe ne savent pas que ce temps est autorisé, ils le feront en cachette entre deux réunions, et rien ne pourra vraiment se développer »
Conseil n°2 : plus les débats sont réguliers, mieux c’est
- Les grands produits naissent de la collaboration entre l’ingénierie, le design et le produit
- Cette collaboration s’accompagne souvent de tensions, mais ce sont précisément ces débats qui font progresser la qualité du produit
- Il faut que les débats au sein de l’équipe soient vivants, qu’ils portent sur des questions comme « est-ce un problème de design, de produit, ou de compréhension de la fonctionnalité ? »
- Les leaders doivent encourager la remise en question des idées non seulement de bas en haut, mais aussi de haut en bas
- Il arrive souvent que les débats entre fondateurs et employés changent la direction de l’entreprise
Conseil n°3 : construire un système opérationnel capable de passer à l’échelle
- Un bon jugement + une bonne capacité d’exécution opérationnelle constituent la base d’un produit scalable
- Le jugement ne se résume pas au résultat : c’est aussi la capacité à expliquer “pourquoi cette décision a été prise”
- La responsabilité (Accountability), c’est avoir “une histoire qu’on peut raconter”
- Pour que le jugement de quelques-uns se diffuse à l’ensemble du système, il faut des processus clairs
- La qualité opérationnelle se voit jusque dans le processus de recrutement (rapidité des réponses, clarté du planning, etc.)
- Ne pas ignorer les processus sous prétexte qu’on est une startup → construire une entreprise, c’est aussi construire ses opérations
Comment renforcer la relation entre l’ingénierie et l’équipe produit
- Les tensions et malentendus entre l’équipe produit et l’équipe engineering sont une vieille histoire, mais
si l’on veut faire évoluer un produit de qualité à grande échelle, il est indispensable de soigner cette relation
- Un mauvais PM pousse les ingénieurs à suivre sans véritable sentiment d’appropriation du produit,
- un bon PM aide les ingénieurs à bien comprendre “pourquoi on construit cela”
- Lopp définit les ingénieurs comme les personnes du « comment » (how), et les PM comme les personnes du « pourquoi » (why)
- L’équipe produit doit porter la voix du client et laisser aux ingénieurs et aux designers le soin de décider comment construire
- L’essentiel est de partager le “pourquoi”
> Demandez directement à un ingénieur, et non à un PM : “Pourquoi construit-on cette fonctionnalité ?”
- Si la réponse est « parce que le PM l’a demandé », cela suscite la colère
- Le vrai problème n’est pas forcément que le jugement de l’équipe produit soit mauvais, mais que les ingénieurs ne comprennent pas le contexte
> « Les ingénieurs sont ceux qui fabriquent le produit de leurs mains. Une organisation où ils travaillent sans comprendre “pourquoi on construit cela” est vouée à l’échec. »
- À la question de savoir pourquoi Slack n’a pas de fonction de blocage, Stewart répond en expliquant clairement la philosophie selon laquelle « il est important que l’information soit visible par tous »
- Une manière de montrer qu’il s’agit d’une question de vision, pas simplement de fonctionnalité
- Un bon product manager doit être capable de replacer chaque fonctionnalité ou idée dans le contexte de la vision globale du produit
- C’est précisément une partie du “why” sur lequel tout le monde doit se concentrer
À quoi ressemble un grand leader ?
- Le véritable leadership en ingénierie va bien au-delà des simples compétences techniques
- « Au fond, le leadership est l’art de gérer les personnes »
-
Trait de leadership n°1 : posséder de la souplesse (Malleability)
- Un leader travaille avec des personnes aux profils variés et doit pouvoir adapter son style en conséquence
- Il l’illustre par sa propre expérience, expliquant qu’il a dirigé ses équipes de façon totalement différente chez Pinterest et chez Slack
- Aux nouveaux managers, il pose toujours la même question : « Qu’avez-vous changé après avoir reçu du feedback ? »
- La composition des équipes aussi doit être repensée non pas selon des critères figés, mais selon les forces et les faiblesses révélées dans le travail réel
- Pour cela, il procède à une réorganisation tous les six mois
-
Trait de leadership n°2 : être excellent en storytelling
- Il exprime une forte aversion pour le micromanagement : « Il n’y a rien de plus agaçant que de dire aux ingénieurs exactement quoi faire »
- À la place, un leader doit fournir la “boîte (Box)” et la “soupe (Soup)”
- La boîte : un espace rempli d’idées et de contexte
- La soupe : une base d’informations dans laquelle chacun peut puiser librement ou faire ses propres combinaisons
- Au lieu de donner des ordres, offrir un récit inspirant permet aux membres de l’équipe de juger par eux-mêmes et de grandir
- Certains diront : « Dites-moi juste ce que je dois faire », mais même eux finissent par l’interpréter à leur manière
> Le rôle du leader est de donner la soupe. La boire ou décider quoi y ajouter relève de leur choix.
-
Trait de leadership n°3 : comprendre les motivations et les objectifs de chacun
- Un leader doit savoir ce qui fait grandir et motive chaque membre de l’équipe
- Exemple : pour un ingénieur dont le moteur est le défi technique, il faut offrir des occasions permanentes de résoudre des problèmes
- Autre exemple : l’assistante chez Palantir affichait clairement une motivation centrée sur la rémunération → cela rendait le pilotage plus simple
- L’essentiel est d’identifier la motivation centrale unique de chaque personne, puis d’y investir continuellement
- Cela exige de la curiosité (curiosity) et une suite ininterrompue de questions « pourquoi ? »
> Un leader doit découvrir les motivations que les personnes n’ont pas encore identifiées elles-mêmes et créer des opportunités de croissance.
Conclusion : l’essence d’une ingénierie qui réussit, c’est la compréhension de l’humain
- Une organisation d’ingénierie performante repose sur une dynamique humaine (Human Dynamics) fluide
- Les grands produits ne naissent pas de brillants individus isolés, mais d’un collectif de personnes qui collaborent bien
- Le rôle du leader commence par donner du pouvoir aux personnes qui composent l’organisation
- « Une équipe d’ingénierie est une immense tapisserie (tapestry) faite d’êtres humains complexes et formidables »
- Chercher à comprendre la structure et les flux de cette tapisserie est la clé pour faire circuler efficacement la valeur du produit dans toute l’organisation
> « Quand vous avez la volonté de comprendre comment les gens interagissent entre eux, votre entreprise est prête à transmettre la valeur du produit à grande échelle. »
6 commentaires
Il existe un Slack pour les leaders techniques animé par Michael Lopp.
RLS - Rands Leadership Slack
Si cela vous intéresse, n’hésitez pas à y faire un tour. C’est actuellement un immense Slack qui rassemble plus de 36 000 membres.
Pour vous inscrire, il suffit de lire attentivement le contenu du lien ci-dessus puis d’envoyer un e-mail à Lopp.
Nom / profession / pourquoi vous souhaitez rejoindre / où vous avez entendu parler de RLS / votre compte LinkedIn ou Twitter, etc.
Donc, si on a recruté des ingénieurs coûteux, il ne faut pas, sous prétexte qu’on manie un stylo, les traiter comme des LLM ou leur donner des ordres à la Doraemon pour fabriquer des trucs à la va-vite en leur disant quoi faire dans les moindres détails ; il faut simplement partager sa vision, puis les laisser faire, puisque l’approche d’ingénierie pour la concrétiser relève précisément de leur domaine d’expertise.
En y réfléchissant tranquillement, pourquoi est-ce que cela me fait penser à ces scènes, chez nous, où des gens qui veulent construire une maison de campagne ou rénover un vieil appartement passent leur temps à se chamailler avec les entrepreneurs, les entreprises de travaux ou les architectes ?
Le second cas n’est-il pas dans un contexte un peu différent ?
La rénovation d’une maison individuelle ou d’un appartement ancien
relève d’abord davantage de la réalisation d’un rêve que du business,
et il arrive étrangement très souvent qu’on fasse confiance à une entreprise de construction/rénovation pour ensuite se faire avoir...
J’ai l’impression que ce serait la même situation si le propriétaire ne le faisait pas lui-même et le confiait à quelqu’un d’autre.
Même quand on explique très bien, il y a des malentendus, et même quand on vérifie tout minutieusement, il existe toujours des aspects auxquels on n’a pas pensé.
Si l’on doit tout construire en posant des questions sur chaque point que le propriétaire n’a pas précisé, cela prend beaucoup de temps et devient frustrant, donc les experts gèrent souvent une grande partie par eux-mêmes, et j’ai l’impression que c’est justement là que naissent la plupart des frictions.
Cela dit, je vous envie : on dirait que vous n’avez pas encore trop été trahi par des sociétés de SI.
Cela me fait aussi penser à Modern Software Engineering, que j’ai lu récemment. Il y est aussi question des équipes et des organisations, pas seulement du développement lui-même.
Il existe de nombreux avis et méthodes sur le leadership en ingénierie, mais il me semble que l’essentiel reste le même : tout repose sur la compréhension des membres de l’équipe. Comprendre les membres de l’équipe est facile à dire, mais j’ai l’impression que cela nécessite de bâtir la confiance sur la base de l’empathie entre le leader et les membres, grâce à des retours mutuels. Cela ne se construit sans doute pas d’un seul coup. Merci pour ce contenu pertinent qui donne matière à réflexion.